### Release notes You could use the GitLab agent for Kubernetes for pull-based deployments since its launch in 2020. Until now, the agent was restricted to manifests stored on your main branch. This model was limiting some use cases, like storing the manifests of the next release on a release branch and still wanting to test them in an ephemeral environment. GitLab now allows you to specify a git ref together with the manifest project configuration. Besides the default branch, You can now have your manifest files synced from another branch, a git tag or a specific commit. ### Problem to solve As an Application Operator, in order to test the changes to applications thoroughly before they reach production servers, I want to deploy to development, testing and production environments in sequence. - How can we deploy the same manifest repo to multiple environments? (Think of `dev`, `staging`, `production`) - How are manifests files organized? - What special deployment options might exist? ## Proposal - Change `internal/gitaly/poller.go:Poll()` to accept full refs rather than ambiguous refs. - Add ability to specify tag/branch/commit to deploy/track in the GitOps section for both manifests (`ManifestProjectCF`) and Charts (`ChartProjectSourceCF`) ([`agentcfg.proto`](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/pkg/agentcfg/agentcfg.proto)). Add `oneof ref { string tag = 1; etc }` to those proto messages. Convert the string into a proper full [git ref](https://git-scm.com/book/en/v2/Git-Internals-Git-References) i.e. `refs/heads/<branch>` / `refs/tags/<tag>` / `<commit>`. `oneof` would ensure at most one can be specified. - For tags and branches, pass the full ref as ref name to polling code in `internal/module/gitops/server/server.go:poll()`. Use default branch name from project info (converted to full ref spec) if no tag/branch/commit were specified. - For commit, change `GetObjectsToSynchronize()` to fetch and return contents only once and then do nothing (no polling). On a subsequent `GetObjectsToSynchronize()` request with the same commit id just do nothing. i.e. agent has synchronized that commit already, no need to send the same stuff again or even poll Gitaly. ## References - [This article from SAP](https://blogs.sap.com/2021/05/06/decentralized-gitops-over-environments/) shows how they use tag, branch and commit locked deployments to use the main branch as the SSOT