HETS (Hired Equipment Tracking System) makes use of Github Actions and pipline-cli to manage OpenShift deployments. These tools enable a Github Pull Request (PR) based CI/CD pipeline. Github Actions will monitor Github repository for pull requests and start a new build based on that.
This document will not go into the details of how to use Github Actions and pipeline-cli. For documentation on those, you can refer to the following links
HETS is using the official BCDevOps Backup Container for backing up DB. Below is README file from BCDevOps backup-container
- Admin access to OpenShift namespaces, preferably using the standard BC Gov setup of
tools
,dev
,test
andprod
namespaces
This section will describe the necessary steps required to configure the pipeline to run in your OpenShift environment.
There are a few secret objects that must be created manually in the dev
, test
, and prod
namespaces. These are required for the pods to function properly.
You can use the following templates to create the secret objects. Make sure to replace the parameter variables with actual values encoded to base64.
The .pipeline
directory contain the scripts to use pipeline-cli against your OpenShift namespaces. The scripts in the .pipeline
directory in this repository are configured to run against the official SBI OpenShift namespaces (e0cee6-
).
You will need to configure the scripts in the .pipeline
directory to work with your OpenShift namespaces:
The pipeline scripts to configure are as follows
- .pipeline/lib/build.js
- .pipeline/lib/clean.js
- .pipeline/lib/config.js
- .pipeline/lib/deploy.js
- .pipeline/lib/utils.js
Once Github Actions workflow (/.github/workflows/hets-build-deploy.yml) is properly configured, it is ready to monitor pull requests.
Every pull request made to master will trigger a new build and create a standalone deployment in the dev
namespace. This allows you to test new features independantly of other features.
The Github Actions workflow (/.github/workflows/clean.yml) will also automatically clean up the environments when a pull request is closed.
Use the following steps to manually build and deploy. This assumes you have already logged in.
# Change directory to .pipeline
cd .pipeline
# Installed the required NPM packages
npm install
# Create build for a particular PR on Github
npm run build -- --pr=<pr#>
# Deploy to dev, test, or prod
npm run deploy -- --pr=<pr#> --env=<env>
You can also build from your local source code using the --dev-mode=true
flag. This will upload your local source repository instead of cloning the repository from Github. You may need to delete the client/node_modules
directory before using dev-mode
. The node_modules
directory contains too many files and will often cause the build to fail.
dev-mode
is useful for testing the pipeline without pushing any changes to the remote repository.
npm run build --pr=0 --dev-mode=true
You can clean up builds and deployments using
npm run clean -- --pr=<pr#> ---env=<env>
# Alternative you can use --env=all if you have the transient option configured properly
npm run clean -- --pr=<pr#> --env=all