How do the build pipelines work?

1. In the Service-Repositories the build-docker workflow is started by any of the following triggers (see file build-docker.yml in the respective repo):

   1. A commit is being pushed on main branch.
   2. A git tag is being pushed starting with a v, indication a version tag.
   3. A pull request with target to the main branch is created.

   In every Service-Repo, the build-docker workflow builds a deployable image (using the service's own technologies).

   After a successful build of the image, it is pushed to the GitHub Content Repository (ghcr.io). The image name is made up from the repo owner plus the repo name. e.g. ghcr.io/mycompany/epc-aggregator-api. The image tag is generated from the git version tag (e.g. 1.0.0-beta-3), if given, or the current date + the commit sha (e.g. 20230621-7bc7317).

   Then, the update-trigger workflow is started in the main GitOps repo (called epc-deployment-configurations by default). This is done by means of a GitHub "dispatch" using a helper GitHub action eCubeGmbH/trigger-image-notification-action@main. Parameters sent to the destination repo are image name and tag and the affected service name.

   The called GitHub action trigger-image-notification-action decides which Environment (e..g. Staging or Dev) will be deployed. The environment name is alle passed to the workflow in the Gitops repo.

2. When the update-trigger workflow in the GitOps repo is triggered, it changes the image name and tag of the service's kustomization.yaml in the appropriate subdirectoy overlays/<environment>. This change is then commited to the repository.

3. ArgoCD "sees" the changes in the GitOps repo. It then triggers an appropriate redeploy of the affected service (i.e. the corresponding Kubernetes Pod) within the ArgoCD "application" called shop-stack-<environment> containing application definitions of the environment that shall be deployed.