-
Notifications
You must be signed in to change notification settings - Fork 434
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
Feature/upgrade operator-sdk 1.27.0 #1498
Feature/upgrade operator-sdk 1.27.0 #1498
Conversation
Signed-off-by: Yuri Sa <yurimsa@gmail.com>
Signed-off-by: Yuri Sa <yurimsa@gmail.com>
Crossreference #1501. Could you also update the title of the PR? |
Update the version in the scorecar tests |
Signed-off-by: Yuri Sa <yurimsa@gmail.com>
Signed-off-by: Yuri Sa <yurimsa@gmail.com>
It shouldn't be updated. |
@yuriolisa any reason why it should not be updated? It was always bumped as part of the SDK version bump. Also see the example operator https://github.com/operator-framework/operator-sdk/blob/master/testdata/go/v3/memcached-operator/bundle/tests/scorecard/config.yaml |
Signed-off-by: Yuri Sa <yurimsa@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After the update the project structure and dependency stack should be aligned with https://github.com/operator-framework/operator-sdk/blob/master/testdata/go/v3/memcached-operator
Therefore:
CONTROLLER_TOOLS_VERSION
should be bumped to 0.10.0
Thank you for the heads-up. I've mislooked at the scorecard-test version. |
@yuriolisa unit tests failed |
Signed-off-by: Yuri Sa <yurimsa@gmail.com>
Signed-off-by: Yuri Sa <yurimsa@gmail.com>
Signed-off-by: Yuri Sa <yurimsa@gmail.com>
Signed-off-by: Yuri Sa <yurimsa@gmail.com>
Signed-off-by: Yuri Sa <yurimsa@gmail.com>
Signed-off-by: Yuri Sa <yurimsa@gmail.com>
@@ -31,9 +31,9 @@ metadata: | |||
categories: Logging & Tracing | |||
certified: "false" | |||
containerImage: ghcr.io/open-telemetry/opentelemetry-operator/opentelemetry-operator | |||
createdAt: "2020-12-16T13:37:00+00:00" | |||
createdAt: "2023-03-02T10:14:11Z" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm.. is this information displayed somewhere? Ignoring it makes sense, otherwise our diff test would fail. But at the same time, this field will be 2023-03-02T10:14:11Z
for ever.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK, since the operator-sdk
version 1.26
, the createdAt
field is being changed. Due to that, @iblancasa pointed to creating a workaround for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems it was not updated until now. So... it seems it is not really important.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@yuriolisa yes, that thing helps to ignore the timestamp. But is it right to ignore this one?
- If
createdAt
describes when the operator was first created, we should not update the timestamp. - If the field describes when the shipped version was created, we should update the field with each release.
(My understanding is that a field like createdAt
should never change and instead a field like updatedAt
should be changed with each release.)
On Operatorhub i found this:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since @frzifus reacted with 👎🏻
, I'll try to clarify my comment.
It seems it was not updated until now. So... it seems it is not really important.
By this I meant: if it was expected to be updated, nobody paid attention to it. Sorry if I was not clear enough.
I think we should not update it but since it seems it is not clear what it means... I don't have a strong opinion. It can be:
- When the bundle was created
- When the operator was created
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A rough (to the day) timestamp of when the operator image was created
Sounds like we should update this field with every release.
@pavolloffay , could you please have a look? |
* Adding new PRs Signed-off-by: Yuri Sa <yurimsa@gmail.com> * Upgrading Operator-sdk Signed-off-by: Yuri Sa <yurimsa@gmail.com> * Adding createdAt fix Signed-off-by: Yuri Sa <yurimsa@gmail.com> * Adding createdAt fix Signed-off-by: Yuri Sa <yurimsa@gmail.com> * Adding scorecard-test update Signed-off-by: Yuri Sa <yurimsa@gmail.com> * Fixing tools version Signed-off-by: Yuri Sa <yurimsa@gmail.com> * Fixing version Signed-off-by: Yuri Sa <yurimsa@gmail.com> * Fixing controller-gen version Signed-off-by: Yuri Sa <yurimsa@gmail.com> * Fixing kubebuilder-assets Signed-off-by: Yuri Sa <yurimsa@gmail.com> * Fixing kubebuilder-assets Signed-off-by: Yuri Sa <yurimsa@gmail.com> --------- Signed-off-by: Yuri Sa <yurimsa@gmail.com>
Resolves #1501