bundle: `createdAt` field is always updated when `make bundle` is run

[zalsader]

Bug Report

Running make bundle always updates the createdAt field even if no other updates in the bundle are present. I was hoping that createdAt would not change unless there are other changes in the bundle. I understand that this is an expected behaviour based on #6136, but it is annoying when taking git and github into account.

I plan to create a github workflow that checks if make bundle has been run, and always having one line change is not ideal. The other place where this could be an issue is when collaborating on a project. The changes in the bundle will have to be actively ignored before commiting and pushing. The git pull operation might complain that I have local changes and prevent me from pulling until they are discarded.

I understand that there are ways around it, it is just not ideal to have to deal that.

What did you do?

Run make bundle, commit all the changes.
Run make bundle again.

What did you expect to see?

I expected to see no changes in git

What did you see instead? Under which circumstances?

The line for metadata.annotations.createdAt in bundle/manifests/<name>.clusterserviceversion.yaml is changed even though there are no other changes in the bundle.

Environment

Operator type:

/language go

Kubernetes cluster type:

minikube

$ operator-sdk version

operator-sdk version: "v1.26.0", commit: "cbeec475e4612e19f1047ff7014342afe93f60d2", kubernetes version: "1.25.0", go version: "go1.19.3", GOOS: "linux", GOARCH: "amd64"

$ go version (if language is Go)

go version go1.19.4 linux/amd64

$ kubectl version

WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short.  Use --output=yaml|json to get the full version.
Client Version: version.Info{Major:"1", Minor:"26", GitVersion:"v1.26.0", GitCommit:"b46a3f887ca979b1a5d14fd39cb1af43e7e5d12d", GitTreeState:"clean", BuildDate:"2022-12-08T19:58:30Z", GoVersion:"go1.19.4", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v4.5.7
Server Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.3", GitCommit:"434bfd82814af038ad94d62ebe59b133fcb50506", GitTreeState:"clean", BuildDate:"2022-10-12T10:49:09Z", GoVersion:"go1.19.2", Compiler:"gc", Platform:"linux/amd64"}

Possible Solution

Surround this with an if statement that checks if anything else has changed.

Additional context

[scotRinga-MayaDog]

ꓝꓲꓠꓠꓲꓢꓧ

[zalsader]

Workaround:
Create this script and run it inside make bundle

#!/bin/bash
git diff --quiet -I'^    createdAt: ' bundle
if ((! $?)) ; then
    git checkout bundle
fi

[varshaprasad96]

@zalsader As you mentioned, this was an intended behaviour. From the production pipeline's perspective, we have a backend tool that looks at all the bundles and collects data on them which includes the created-At field. If the customer runs make bundle again and deploys on the cluster, even though there may not be particularly any changes in the bundle content, we track this to be an intentional behaviour considering that the customer has taken action.

I would be open if the many authors would prefer to not update this field if there is no change in bundle content. We could change the default behaviour, but I would still insist that an option remains retaining the current process of updating the field with every make bundle.

[Bhargav-InfraCloud]

+1 @zalsader, just adding my thoughts.
I haven't come across this issue, but I think createdAt should only be updated when "there is an update". I didn't get the background of #6136, on why the team at KubeCon wanted to update it every time. But I wish to understand.

[everettraven]

We discussed this issue during the community meeting yesterday (02/06/2023) and there was some agreement that the bundles should be considered and treated as release artifacts, meaning they should not be updated as part of a regular pull request but rather during the release process only (whether that is in CI or there is some manual process).

There was agreement that we need to update the documentation around this. There was also some discussion around ways to enable an author to not update that field if there are no changes in the bundle, but I don't recall there being a consensus.

I am curious, in what way are you using make bundle and running into this problem? Is it a step that must be run before a PR or is it run in CI as a check against a PR?

[varshaprasad96]

+1. Bundles are considered "release artifacts". The use of make bundle is to enable authors to package their relevant operator manifests into a format that is accepted by OLM and publish it. An iteration of make bundle indicates that I have one set of release artefacts created at that particular point in time, whether it had changes from the previous version or not is not relevant.

There was agreement that we need to update the documentation around this. There was also some discussion around ways to enable an author to not update that field if there are no changes in the bundle, but I don't recall there being a consensus.

If we would like to enable authors to update it, we shouldn't be just allowing them to do so with a flag at all times. The approach should be to check if the --overwrite flag has been set for CSV generation. If yes, then createdAt should be updated no matter what, if no then we could possibly give an option to the author to update it or not. As mentioned by Bryce, this is a separate feature, which needs to be discussed before implementing it instead of changing the current default behaviour as is.

[zalsader]

There was agreement that we need to update the documentation around this. There was also some discussion around ways to enable an author to not update that field if there are no changes in the bundle, but I don't recall there being a consensus.

I am curious, in what way are you using make bundle and running into this problem? Is it a step that must be run before a PR or is it run in CI as a check against a PR?

I was planning on running it as part of a CI check that would warn you if make bundle would have generated new changes (other than createdAt) to the bundle, asking you to run it and commit changes in case it was forgotten. An update to the documentation on when it should be rerun would be greatly appreciated.

[frzifus]

Thats what the Jaeger-Operator, tempo-operator and opentelemetry-operator does.

[zalsader]

Thats what the Jaeger-Operator, tempo-operator and opentelemetry-operator does.

I looked at the code there. These operators use an older version of the operator-sdk which did not include the updated createdAt. It was helpful to look at them, so thank you.