./.github/workflows
directory) that perform the following:
main
branch, the application is containerized and pushed to the dev Org’s private image registry. The GVC and Review Workload
is created/updated by applying the YAML contents of the files ./cpln/cpln-gvc.yaml
and ./cpln/cpln-workload.yaml
. The name of the Review Workload
will be prefixed by the name of the branch that created the pull request.main
branch, a dev
workload is updated (or created if it doesn’t exists) in the dev Org by applying the same files as step 1, except that the workload name is prefixed with dev
. This allows the application to be reviewed and tested before being pushed to the production Org.stage
and prod
environment is accomplished by manually executing the Deploy-To-Stage-or-Prod
workflow and selecting the target environment. The target GVC and Workload in the production Org is updated (or created if it doesn’t exists) by applying the YAML contents of the files ./cpln/cpln-gvc-prod.yaml
and ./cpln/cpln-workload.yaml
. The main difference between the two GVC files is that the prod
version contains the Pull Secret
that is needed to pull the image from the dev Org and the stage
and prod
workloads refers to the image that was pushed to the development Org.main
branch is opened. The application will only be promoted to the dev
workload if the pull request is closed and merged.