-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bundle: createdAt
field is always updated when make bundle
is run
#6285
Comments
ꓝꓲꓠꓠꓲꓢꓧ |
createdAt
field is always updated when make build
is runcreatedAt
field is always updated when make bundle
is run
Workaround: #!/bin/bash
git diff --quiet -I'^ createdAt: ' bundle
if ((! $?)) ; then
git checkout bundle
fi |
@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 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 |
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 |
+1. Bundles are considered "release artifacts". The use of
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 |
I was planning on running it as part of a CI check that would warn you if |
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 |
Right, the |
This makes sense, but I would personally recommend that instead of checking the bundle for changes in every PR you instead only check for uncommitted changes in the I definitely agree that we need to update the documentation in this regard, which we are keeping this issue open to track. |
@everettraven so you recommend to remove the bundle folder from the version control? |
This commit adds a workaround for avoiding the ci failure for updated createdAt value in the CSV. This is a known issue disscussed here: operator-framework/operator-sdk#6285 Signed-off-by: liornoy <lnoy@redhat.com>
This commit adds a workaround for avoiding the ci failure for updated createdAt value in the CSV. This is a known issue disscussed here: operator-framework/operator-sdk#6285 Signed-off-by: liornoy <lnoy@redhat.com>
This commit adds a workaround for avoiding the ci failure for updated createdAt value in the CSV. This is a known issue disscussed here: operator-framework/operator-sdk#6285 Signed-off-by: liornoy <lnoy@redhat.com>
This commit adds a workaround for avoiding the ci failure for updated createdAt value in the CSV. This is a known issue disscussed here: operator-framework/operator-sdk#6285 Signed-off-by: liornoy <lnoy@redhat.com>
This commit adds a workaround for avoiding the ci failure for updated createdAt value in the CSV. This is a known issue disscussed here: operator-framework/operator-sdk#6285 Signed-off-by: liornoy <lnoy@redhat.com>
The bundle is supposed to be generated from scratch for publication; it mustn't be modified manually, so there's no point in keeping it in version control. See operator-framework/operator-sdk#6285 for context. Signed-off-by: Stephen Kitt <skitt@redhat.com>
The bundle is supposed to be generated from scratch for publication; it mustn't be modified manually, so there's no point in keeping it in version control. See operator-framework/operator-sdk#6285 for context. Signed-off-by: Stephen Kitt <skitt@redhat.com>
This commit adds a workaround for avoiding the ci failure for updated createdAt value in the CSV. This is a known issue disscussed here: operator-framework/operator-sdk#6285 Signed-off-by: liornoy <lnoy@redhat.com>
This commit adds a workaround for avoiding the ci failure for updated createdAt value in the CSV. This is a known issue disscussed here: operator-framework/operator-sdk#6285 Signed-off-by: liornoy <lnoy@redhat.com>
This commit adds a workaround for avoiding the ci failure for updated createdAt value in the CSV. This is a known issue disscussed here: operator-framework/operator-sdk#6285 Signed-off-by: liornoy <lnoy@redhat.com>
The bundle is supposed to be generated from scratch for publication; it mustn't be modified manually, so there's no point in keeping it in version control. See operator-framework/operator-sdk#6285 for context. Signed-off-by: Stephen Kitt <skitt@redhat.com>
This commit adds a workaround for avoiding the ci failure for updated createdAt value in the CSV. This is a known issue disscussed here: operator-framework/operator-sdk#6285 Signed-off-by: liornoy <lnoy@redhat.com>
This commit adds a workaround for avoiding the ci failure for updated createdAt value in the CSV. This is a known issue disscussed here: operator-framework/operator-sdk#6285 Signed-off-by: liornoy <lnoy@redhat.com>
This commit adds a workaround for avoiding the ci failure for updated createdAt value in the CSV. This is a known issue disscussed here: operator-framework/operator-sdk#6285 Signed-off-by: liornoy <lnoy@redhat.com>
This commit adds a workaround for avoiding the ci failure for updated createdAt value in the CSV. This is a known issue disscussed here: operator-framework/operator-sdk#6285 Signed-off-by: liornoy <lnoy@redhat.com>
Making an update here This repo prior to my PR edits Thus createdAt here would break CI if one were to be implemented without @zalsader 's workaround |
Another makefile target to workaround. .PHONY: bundle-ignore-createdAt
bundle-ignore-createdAt:
git diff --quiet -I'^ createdAt: ' bundle && git checkout bundle || true |
from PR The only other explanation that would make sense for not honoring this issue is if the suggestion is to add |
A couple of things/comments:
So, agree that there should be documentation updates. Also, I think it makes sense to have a |
Adding |
Which is why this is a flag for CI only. It is so the CI do not fail. You can still intentionally commit |
This is solved by using a consistent operator-sdk version for all contributors OPERATOR_SDK = $(shell pwd)/bin/operator-sdk
operator-sdk:
# Download operator-sdk locally if does not exist
if [ ! -f $(OPERATOR_SDK) ]; then \
mkdir -p bin ;\
curl -Lo $(OPERATOR_SDK) https://github.com/operator-framework/operator-sdk/releases/download/v1.23.0/operator-sdk_$(shell go env GOOS)_$(shell go env GOARCH) ; \
chmod +x $(OPERATOR_SDK); \
fi
.PHONY: bundle
bundle: manifests kustomize operator-sdk ## Generate bundle manifests and metadata, then validate generated files.
$(OPERATOR_SDK) generate kustomize manifests -q
cd config/manager && $(KUSTOMIZE) edit set image controller=$(IMG)
$(KUSTOMIZE) build config/manifests | $(OPERATOR_SDK) generate bundle -q --extra-service-accounts "velero" --overwrite --version $(VERSION) $(BUNDLE_METADATA_OPTS)
@make nullables
# Copy updated bundle.Dockerfile to CI's Dockerfile.bundle
# TODO: update CI to use generated one
cp bundle.Dockerfile build/Dockerfile.bundle
$(OPERATOR_SDK) bundle validate ./bundle |
Only for releases. For development branches it is important to not update createdAt just for fun. Hence why there is CI that can check for this. |
My PR solves this where it will prevent It will not fail CI if createdAt was the only change made if its from the user PR and not CI. |
I can't see how allowing this would be a desirable way to contribute to a repo. |
There have been other issues that will be hard to debug if you allow multiple operator-sdk versions to be used. Such as relatedImages issue here #5763 The whole repo should be using the same version together. |
I disagree with the notion that bundle is only for release artifacts when in practice, people have been making changes to bundle without making a release. |
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
/lifecycle frozen |
Bug Report
Running
make bundle
always updates thecreatedAt
field even if no other updates in the bundle are present. I was hoping thatcreatedAt
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. Thegit 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
inbundle/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
$ go version
(if language is Go)$ kubectl version
Possible Solution
Surround this with an if statement that checks if anything else has changed.
Additional context
The text was updated successfully, but these errors were encountered: