...
The official documentation is found here: https://folio-org.atlassian.net/wiki/spaces/FOLIJET/pages/1396559/How+to+work+with+Rancher+environments in the How to Work with Rancher Environments documentation.
The deployment process involves deploying back-end modules and front-end modules (UI modules).
The process for deploying for active development for back-end module involves Deploying via a Feature Branch.
...
Ensure the Rancher Pod is Running
Recent operational decisions have led to having the Rancher Pods being offline based on a schedule.
The Rancher Pod should be started before deploying.
The https://folio-dev-aggies-diku.ci.folio.org/ will show a 502 Bad Gateway when the Pod is down.
Use the Scale Up or Down a Pod via Manage Pods to bring the Pod up.
The How to Start/Activate Rancher Environment guide describes how to do this.
Deploying Feature Branches
A feature branch is simply a branch on Github that is to be deployed.
These branches are classified as a “feature branch” even if they are bug fixes or something else that is not a “feature”.
Deploying Back-end Module Feature Branch
Some of this the back-end module deplyoment feature branch process is still described in the (Deprecated) Deploy/Update back-end module from feature branch documentation.
...
The Aggies team deploys a back-end module using the Jenkins Feature Branch Deployment process as follows:
...
| Info |
|---|
To determine what has been run previously (and with what parameters) the job history should be used: |
Confirming a Back-end Module Feature Branch is Deployed
The build process should show success, but one should also visit the Aggies Scratch Environment to confirm that the back-end module is correctly deployed, registered, and enabled.
Each build in the pipeline ends up with a build hash appended to the end of the package version.
The hash is generally a short github hash, which as an example might be something like 70a44d3.
GIven a mod-workflow with a package version of say 1.2.0-SNAPSHOT, then the resulting pipeline built version would be mod-workflow-1.2.0-SNAPSHOT.70a44d3.
This can be confirmed or denied by visiting the Aggies Scratch Environment Software Versions page.
Under the OKAPI Services column, there should be two particular modules of concern, mod-workflow and mod-camunda.
The mod-workflow module might look like this:
| Code Block |
|---|
Workflow Module (mod-workflow-1.2.0-SNAPSHOT.70a44d3) |
The mod-camunda module might look like this:
| Code Block |
|---|
Camnuda BPM Module (mod-camunda-1.2.0-SNAPSHOT.d18c2f2) |
Deploying Front-end Module Feature Branch
The feature branch is deployed using the platform-complete-aggies branch from the ui-workflow project. That branch should be updated to contain the desired state of the code that is intended to be deployed. This branch may be force-pushed to.
| Info |
|---|
|
The feature branch is now deployed by modifying the package.json in the Platform Complete Aggies Rancher Branch.
The @folio/workflow must be set to the gitub repository and branch (such as my_custom_branch), like this:
| Code Block | ||
|---|---|---|
| ||
"@folio/workflow": "https://github.com/folio-org/ui-workflow.git#my_custom_branch", |
| Note |
|---|
The simpler approach of just using |
The Aggies team deploys a front-end module using the Deploy UI Bundle process as follows:
The CLUSER is set to
folio-dev.The NAMESPACE is set to
aggies.The FOLIO_REPOSITORY is set to
platform-complete.The FOLIO_BRANCH is set to
aggies-rancher.The CONFIG_TYPE is set to
development.The TENANT_ID is set to
diku.The UI_BUNDLE_BUILD is usually checked (uncheck to select an existing bundle).
The UI_BUNDLE_TAG is set left alone or blank except when UI_BUNDLE_BUILD is unchecked.
The CUSTOM_HASH is set left alone.
The CONSORTIA is left unchecked.
The AGENT is set to
jenkins-agent-java17.The REFRESH_PARAMETERS is left unchecked.
Pushing the Build button will build the image.
| Info |
|---|
|