AMI Patch Cycle - Clears a file from Bitbucket

Products

VMware Tanzu Application Platform

Issue/Introduction

Customer has custom feature that they have been using for almost a year now that allows developers to use different resource allocation across environment. For some reason, when customer patches production-tap-build cluster which handles all the builds, this feature that is implemented through a file named k8s-settings.yaml is getting deleted from bitbucket in one of the commits during patching.

The customer noted that their process used to work. Before TAP 1.11.1, if the supply chain's output did not include a file, that file would persist (i.e. if the supply-chain process didn't write a file called k8s-settings.yaml, then the gitops step wouldn't delete a k8s-settings.yaml file that had been created by someone else. This was a bug, as a developers workload v1.0 might write 3 services that it relies on and then they refactor and simplify and v1.1 just relies on 2 services. It's important that the supply chain delete the reference to the third service that's no longer used.

That said, the customer points to a valid concern where they are interested in storing a particular file in the gitops repo and would like to protect that file from the gitops operation.

Resolution

To enable them, protecting a file from the config-writer is as below.

In the config-writer task there is a git-clone-and-push step. It does just what it sounds like:
clones the gitops repo locally
writes in the changes from the most recent run of the supply-chain to the workload's directory
commits those changes
pushes

Within that step, there is a line
git add .
This stages all the changes made locally for a git commit. To protect our file, we simply need to follow this command with git restore --staged <file>
This will prevent the git operation from committing any change, update, delete to the specified file.
So the step will read
...
rm files.json
git add .
git restore --staged k8s-settings.yaml
...

There are a handful of templates that this change should be made to:
config-writer-template.yaml
config-writer-and-pull-requester-template.yaml
package-config-writer-template.yaml
package-config-writer-and-pull-requester-template.yaml

Each of them will have a git-clone-and-push step with similar code.

Note: The template names might be slightly different for each customer, as they have written their own config-writer templates that are based on the out-of-the-box ones that we supply. But it means that we don't have full visibility into what might have drifted between the two sets of templates. In their environment, you would run a search for git add . in your templates folder just to make sure they all get updated.

And that's it, k8s-settings.yaml will persist even as the application developers update their source code and the supply chain builds new versions of their apps.

It is possible to make the protected filename configurable in tap-values (i.e., if the team later decided that they wanted to protect special-configuration-folder instead of k8s-settings.yaml you could update that with a tap-value). Similarly, there's more upfront work that could be done to anticipate a future change where the team wanted to protect two different filenames. But that would be more upfront work. Even were one of those scenarios to arise in the future, the simplest change at that point will simply be to drop a second git restore command in the templates:
...
rm files.json
git add .
git restore --staged k8s-settings.yaml
git restore --staged my-other-untouchable.yaml
...