Web CI and CD Workflow Pipelines

[ronaldo-macapobre]

Pull Request for JIRA Ticket: JIRA-74

Issue ticket number and link

https://jag.gov.bc.ca/jira/browse/JASPER-74

Description

• Made some updates to /web to be able to build the docker image successfully.

• CI and CD workflow for the Web (Vue) project

• CI (build-and-test-web.yml) is triggered when a PR is created targeting master branch.

• CD (deploy-web.yml) is triggered when changes are pushed to the master branch (merged PR) which does the following:

  1. Triggers CI process
  2. builds, tags and push the web image to GCHR.
  3. deploys the image to the dev environment.
  4. The workflow is gated in such a way that it requires approval before continuing deploying to TEST or PROD.

Type of change

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

How Has This Been Tested?

Executing the workflow manually in Github Actions where the feature branch is set.

[amlanc1]

lgtm

[WadeBarnes]

My only real comments and concerns are around the image/code build.

There's some inconsistencies with the way the image/code is being built. It's built using a matrix to define the node version (currently v12) when the code is built and tested. Node 12 is also used by the manage script during the s2i build, but node 10 (hard coded) is being used by the ./web/Dockerfile.node and the workflows. I like the matrix approach, but the docker builds/files would need to be updated to support the nodes versions being passed in as arguments. Examples; https://github.com/hyperledger/aries-cloudagent-python/blob/main/.github/workflows/publish.yml, https://github.com/hyperledger/aries-cloudagent-python/blob/main/docker/Dockerfile

Any dockerfiles should be defined under the docker folder (i.e. not in web).

Builds should be consistent and use consistent tool versions. My comments above would address this.

Workflows should stick with building images using maintained GitHub Actions such as docker/build-push-action and redhat-actions/s2i-build where possible.

We might want to switch the web build over to using a composite build. https://github.com/hyperledger/aries-cloudagent-python/blob/main/docker/Dockerfile is an example of this.

Happy to have a meeting to discuss further if you like.

[WadeBarnes]

The issues don't need to be addressed all at once. We could address the main ones, the inconsistences and then deal with the others as separate enhancement tasks.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[ronaldo-macapobre]

My only real comments and concerns are around the image/code build.

There's some inconsistencies with the way the image/code is being built. It's built using a matrix to define the node version (currently v12) when the code is built and tested. Node 12 is also used by the manage script during the s2i build, but node 10 (hard coded) is being used by the ./web/Dockerfile.node and the workflows. I like the matrix approach, but the docker builds/files would need to be updated to support the nodes versions being passed in as arguments. Examples; https://github.com/hyperledger/aries-cloudagent-python/blob/main/.github/workflows/publish.yml, https://github.com/hyperledger/aries-cloudagent-python/blob/main/docker/Dockerfile

Any dockerfiles should be defined under the docker folder (i.e. not in web).

Builds should be consistent and use consistent tool versions. My comments above would address this.

Workflows should stick with building images using maintained GitHub Actions such as docker/build-push-action and redhat-actions/s2i-build where possible.

We might want to switch the web build over to using a composite build. https://github.com/hyperledger/aries-cloudagent-python/blob/main/docker/Dockerfile is an example of this.

Happy to have a meeting to discuss further if you like.

@WadeBarnes Appreciate the great comments. I actually got the idea from this PR from the main SCC branch but I was able to address the major comment and now passing the node version as an argument to the Dockerfile. I had to break the node-version to node-major-version and node-minor-version because only the major version is accepted by dockerhub.

I also created a new ticket (https://jag.gov.bc.ca/jira/browse/JASPER-101) so the enhancement effort is tracked.