| Repository | Type | Squad | Status | Git Repo |
|---|---|---|---|---|
| Share | Java | Gaia | Repository |
[![Product Name Screen Shot][product-screenshot][files-cpbvt]] [![Product Name Screen Shot][product-screenshot][wikis-cpbvt]]
To get started with working with this project, create your own fork and clone the master branch to your local machine.
To build the Share project, make sure that environment is configured to build using UTLS. See Configuring an Environment to Build Using UTLS.docx.
After setting this up, run the bootUTLS script against the local repository.
Navigate to share/share/lwp and run
wsbld -l build.log
After the command has completed, check the build.log file for Errors. A successful build contains the following lines at the end of the log:
[15:41:32:625/share/development.fe/buildFE] Finished Building FE [ share ]
...
BUILD SUCCESSFUL
A log containing the word error or statements like below indicate the build failed and some changes are required
[12:01:37:246/share/gen.build.artifacts/genBFI] Build failure detected: Missing build.status file indicates component [ share.tests ] failed to build.
In order to build the wikis ear, up to two additional build commands have to be executed.
It is possible that the file build/wikis.web.war/lib/wikis.web.war is missing, in which case the wikis.web.war build has to be executed:
cd wikis.web.war
wsbld -l build.log
It is also possible that the file build/wikis.ear/lib/wikis.ear is missing, in which case the wikis.web.war build has to be executed:
cd wikis.ear
wsbld -l build.log
The mentioned wikis.ear is the EAR archive for distribution/testing. It can then be used to deploy directly to WebSphere through the WAS console.
Share caches build information inside the build folder, and won't rebuild files even if changes were made. To rebuild the project, run the following commands before rebuilding:
wsbld clean -l clean.log
rm -rf build/
Note: you should be able to run wsbld production which will also build both the wikis and files ear files.
If you make any changes, you should always run the GUI and the API BVTs from BVT On-Demand.
Also, depending on the change, you will need to ensure that there will be no Unit test failures in the pipeline. You can run the unit tests on a a pool server by doing the following.
There is a way to run your unit tests on the pool server, there is very little documentation, however, there is support provided on the pool servers to update the Files and Wikis ear files with a set of changes that will enable you to run the tests. When the pool servers are deployed, they install a production version of Files.ear and Wikis.ear which do not have all of the support for running the tests. Ideally we should be able to generate a new share build via a build target in the build.xml for the whole of Share, but it doesnʼt seem that we do at this time, so we will have to run the scripts that are provided and pushed to the to pool servers to provide the update.
On pool servers, there is a folder in the home directory of lcuser (/home/lcuser/lc-update) that provides most of the things that are needed to update the server to install the test artifacts for Share. While there may be support for updating the server for other components (e.g. FileNet), I will focus on Share only for now. The picture below shows the lc-update directory. You will notice that there is a directory called share. That directory is not there by default, it is added as the result of running one of the two scripts that you need to run.
There are two scripts that need to be run that to update the ear files.
This script can be found in /home/lcuser/lc-update/bin and it does just what it says it does, it pulls the binaries for the build that you need from dailybuilds (which is already mounted). You can look at the file directly to see what the options are to run it, but I think you want to get the binaries for the same build that is running on the pool server. (You can look to see what the latest build is by looking at currentBuildLabel.txt in the directory for the IC10.0_Share builds. You want to run the script from the lc-update directory so it lays down the binaries in the right place for the script that installs the updates to the Files and Wikis applications. The script command to run, for example would be “sh ./bin/get- build.sh -b IC10.0_Share_20190819-1505”. Running the script will pull the build and create the share directory under the lc-update directory. Once you have the binaries, you can run the next script to update the application ears.
This is the script that will perform the update of the application EARs. This script can be found in /home/lcuser/lc-update/xkit/ci.
This script will copy all of the test related JAR and WAR files into the installed applications directory, it updates the WIM files, adds the users under whose identities will be running the tests, and sets the J2EE roles for the newly added users. When those tasks are done correctly, you can run the unit tests in the browser (e.g. https://lcauto167.swg.usma.ibm.com/files/test), which will bring you to the test UI . While I havenʼt experimented with it yet, you will also be able to run the tests using curl commands as well, and I think that there are specific scripts that you can run as well. As I learn more, Iʼll update it. I wish I could say, is that you just have to run the script as is, but it isnʼt quite true. There are a couple of changes you will need to make, to get it to run properly. I found if I run it and there are errors that a couple of things occur that can be bad. The first is that the server (server1) will not start, and the second is that for some reason you can no longer access the admin console using the browser and the password for the pool server. (You can still ssh to the server however). I think that this happens because, getWasAdminPassword.py might muck with the server password. You can reset the server back to the base image from the icautomation dashboard and keep trying if necessary. At some point, I will make the changes to the source code that will help somewhat, but I need to understand whether or not, the changes will have any impact on the pipeline servers first. So for now you need to make these changes to share_update_ci.sh. You should be able to make the changes once and save away a copy of the file, because it wonʼt change that much.
Change the reference to the cell name to the name that the pool server uses. Change if necessary
export WAS_CELL=${WAS_CELL:-lc45linux1Node01Cell} to (typically) export WAS_CELL=${WAS_CELL:-bvtdb2Node01Cell}
Set the correct FE_SRC directory Change
export FE_SRC=${REMOTE_CI_HOME:-/home/lcuser/ci} to export FE_SRC=${REMOTE_CI_HOME:-/home/lcuser/lc-update/share}
Move the target directory for the fileRegistry up higher in the file. It was being used without having been defined
Move
TGT_FILEREGISTRY_XML_DIR=${WAS_HOME}/profiles/${WAS_PROFILE}/ config/cells/${WAS_CELL} from below “Step 2.Copy fileRegistry.xml” to below “SRC_FILEREGISTRY_XML=${CI_SRC}/fileRegistry.xml”
I found that I was getting an error deleting a back up file and I havenʼt debugged it enough yet to understand whether the error was consequential or not. So in /opt/ IBM/WebSphere/AppServer/profiles/AppSrv01/config/cells/ icbvtDB2Node01Cell (which is TGT_FILEREGISTRY_XML_DIR)
I copied fileRegistry.xml to fileRegistry_bk.xml ahead of time. By doing this I saw no errors when I ran the script. As mentioned above if the script runs cleanly, you will then be able to hit https:// <yourpoolserver>/files/test and you will see the test page.
Because the process of setting up the unit tests requires the "manual" splicing of the test wars into the ear files, the test wars cannot find an events EJB, so when the events generated by the operations in the tests try to publish those events exceptions are thrown. Generally, the EJB resolution is handled by an interim step in the build process that actually deploys the EJB. That step is missing in the manual application.
In general this is not a problem but it can be a problem when run in the pipeline depending on the server configuration for memory and disk space. We will have to fix this when we can.
When adding code changes, run both the Share build and tests to ensure there are no regressions in code quality. Preferably (depending on gravity of change), deploy your new build to a test server and make sure no errors come up either in the UI or the server SystemOut.log.
After confirming local changes lead to the required results, do the following to finish your task:
- Commit your changes
- Always add the Jira-Task ID to the commit message for traceability.
- Push your changes to your local fork and master
- Create a PR against the master repostiory
- Always add the Jira-Task to the PR title for traceability
- Ask for peer reviews within the Fusion-squad
- Ask the Git Merge Requests channel for merging the changes/PR
To ensure the changes are fine and promote correctly, make sure that...
- The Build pipeline passes in the run related to the commit
- The Unit test pipeline passes and all tests remain successful
- A new version of the Share application is bundled into the Connections build
- Check the Build Overview and the version time stamps to ensure a new version was picked up
- Check the changes on our CPBVT Environment to confirm they have been applied
Once the build and promoting has been successful, make sure to backport the changes to older versions of Connections that may require the fix. To do this,
- Check out the necessary branches (e.g. IC6.5CR1 and IC7.0)
- Cherry pick the required changes from master to the branch
- Go through the steps in Adding code changes and Confirming changes are promoted in the respective pipelines to ensure promotion is successful
- Confirming changes with support staff to ensure that fixes are contained in new CFix versions and will make it to the customers