Workflows update

[memodi]

This should help by creating subscription of NOO catalog image developed from main branch as an alternative to make deploy target

/cc @jotak @jpinsonneau

[memodi]

@jotak I've some confusion around this workflows, when I create a catalog using the NOO image bundle created by this workflow, the PackageManifests still uses 0.1.4 i.e. version published to OperatorHub:

any ideas why it uses 0.1.4 as version in PackageManifests? is it just some config issue and it actually would use the NOO image tagged as main ? Just want to make sure that when use catalog image bundle using that's pushed using this workflow actually using correct images.

[jotak]

As far as I can tell, that's because you call make bundle-build without prior call of make bundle, so the version that is used is still whatever is in bundle/manifests/netobserv-operator.clusterserviceversion.yaml.

When we release a new version, we first run make bundle, with all component versions env: VERSION="$version" PLG_VERSION="$plgv" FLP_VERSION="$flpv" BPF_VERSION="$bpfv" make bundle (this is described in RELEASE.md). Then we tag and the release script (github action) is triggered, that performs bundle-build and bundle-push.

But I'm not sure if make bundle would work as you would expect on main, it's intended to work as part of releasing with a proper version defined, maybe it would necessitate some adjustments in the Makefile to work as you'd like

[memodi]

As far as I can tell, that's because you call make bundle-build without prior call of make bundle, so the version that is used is still whatever is in bundle/manifests/netobserv-operator.clusterserviceversion.yaml.

Okay, does it only use the version name? does it actually deploy NOO image with that version, in this case 0.1.4?

[jotak]

Okay, does it only use the version name? does it actually deploy NOO image with that version, in this case 0.1.4?

Yes it will use 0.1.4 in the end. Running VERSION=main make bundle-build will only set the version of the bundle docker image but it doesn't affect the version of underlying components, so you will actually get the last release and not the current main build.

[jotak]

@memodi I sent you a patch suggestion on your branch

[memodi]

@memodi I sent you a patch suggestion on your branch

thanks @jotak. I tried to run the workflow in my forked repo, however it failed for make bundle-for-test step since operator-sdk is not installed. Any ideas how we can include through GH Actions? I tried to setup using this GH Action available at marketplace, but it seems buggy where it would not find newer operator-sdk versions.

[jotak]

thanks @jotak. I tried to run the workflow in my forked repo, however it failed for make bundle-for-test step since operator-sdk is not installed. Any ideas how we can include through GH Actions? I tried to setup using this GH Action available at marketplace, but it seems buggy where it would not find newer operator-sdk versions.

oh, correct, I didn't think about that.. we should probably add a make target that installs operator-sdk

[memodi]

oh, correct, I didn't think about that.. we should probably add a make target that installs operator-sdk

alright, I added operator-sdk install to Makefile and also tested out on my forked repo , PTAL. thanks!

[memodi]

/approved

[memodi]

thanks @jotak , I think it needs approved label for it to be able to merge?

[jotak]

/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jotak

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:

• OWNERS [jotak]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment