NETOBSERV-2054: Adding version label to upstream bundle #1415
Conversation
|
@OlivierCazade: This pull request references NETOBSERV-2054 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.19.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
bundle.Dockerfile
Outdated
| @@ -1,5 +1,7 @@ | |||
| FROM scratch | |||
|
|
|||
| ARG BUNDLEVERSION=1.9.0 | |||
There was a problem hiding this comment.
we'll need to update this every time we cut the branch, correct? could we please document somewhere?
There was a problem hiding this comment.
1.9.0 value here si just the default one if the arg is not specified.
In the Makefile we already have a variable with the current version that is updated every new version, we set the argument using this variable, so this should not add any work when cutting branch.
There was a problem hiding this comment.
maybe just remove the default value then ? So there's no ambiguity
There was a problem hiding this comment.
thanks @OlivierCazade , besides the bundle version, could we add some labels to bundle and individual component images to show which revision they're on for e.g.: short sh256 of latest git commit that main image is currently at?
@memodi EDIT: sorry, just saw you're talking about upstream and not downstream |
yes, these labels does exist on upstream images as well, but they don't seem to be accurate and values of them are just same across different component images, for e.g.: comparing FLP and Operator main images here: |
|
@memodi that sounds like labels inherited from the base image (ubi9) itself. Which would explain why we retrieve the same on all our components |
could we overwrite them with the values to denote the correct values? I that's essentially what we need as for this task. |
jotak
added
the
needs-changes
|
@OlivierCazade: This pull request references NETOBSERV-2054 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.20.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
OlivierCazade
force-pushed
the
upstream-bundle-version
branch
from
557cdd6 to
447b50c
Compare
|
Tests are failing because the operator-sdk generate bundle command overwrite the bundle Dockerfile. I don't remember having thie issue before, may be a new feature of the operator-sdk. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1415 +/- ##
==========================================
+ Coverage 70.73% 73.79% +3.06%
==========================================
Files 75 80 +5
Lines 10011 11357 +1346
==========================================
+ Hits 7081 8381 +1300
- Misses 2539 2559 +20
- Partials 391 417 +26
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
OlivierCazade
force-pushed
the
upstream-bundle-version
branch
2 times, most recently
from
b2da877 to
b51b9c5
Compare
OlivierCazade
force-pushed
the
upstream-bundle-version
branch
from
b51b9c5 to
3f4e67d
Compare
|
/ok-to-test |
openshift-ci
bot
added
the
ok-to-test
|
New images:
They will expire after two weeks. To deploy this build: # Direct deployment, from operator repo
IMAGE=quay.io/netobserv/network-observability-operator:af337bf make deploy
# Or using operator-sdk
operator-sdk run bundle quay.io/netobserv/network-observability-operator-bundle:v0.0.0-sha-af337bfOr as a Catalog Source: apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
name: netobserv-dev
namespace: openshift-marketplace
spec:
sourceType: grpc
image: quay.io/netobserv/network-observability-operator-catalog:v0.0.0-sha-af337bf
displayName: NetObserv development catalog
publisher: Me
updateStrategy:
registryPoll:
interval: 1m |
|
I can version field in the upstream now, however vcs-ref is still empty for the pre-merge bundle: I am guessing version will be overwritten with 0.0.0-sha-main post-merge, correct? However vcs-ref would be helpful determining which commit it was built on. |
|
Hi @memodi @OlivierCazade [edit] ... annnnnnd ... So there's still something wrong |
|
this commit f87de00 fixes it ... I'll send it to your PR if you're not already on it |
|
New changes are detected. LGTM label has been removed. |
github-actions
bot
removed
the
ok-to-test
jotak
added
ok-to-test
|
New images:
They will expire after two weeks. To deploy this build: # Direct deployment, from operator repo
IMAGE=quay.io/netobserv/network-observability-operator:e049d34 make deploy
# Or using operator-sdk
operator-sdk run bundle quay.io/netobserv/network-observability-operator-bundle:v0.0.0-sha-e049d34Or as a Catalog Source: apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
name: netobserv-dev
namespace: openshift-marketplace
spec:
sourceType: grpc
image: quay.io/netobserv/network-observability-operator-catalog:v0.0.0-sha-e049d34
displayName: NetObserv development catalog
publisher: Me
updateStrategy:
registryPoll:
interval: 1m |
|
this should work now; from the workflow-test branch: |
|
/ok-to-test |
|
thanks @jotak |
|
[APPROVALNOTIFIER] This PR is APPROVED Approval requirements bypassed by manually added approval. This pull-request has been approved by: The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-merge-bot
bot
merged commit 0392046
into
netobserv:main
|
confirming, this is working well on |
5 participants
Description
Adding version label to upstream bundle
Dependencies
n/a
Checklist
If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that.