pin results image until watcher mem leak fix is deemed ok

[gabemontero]

An idea I had @enarha to bypass the results bump I'm getting performance QE to help me test with #3616

Rather than pick up the results image bumps like you see in https://github.com/redhat-appstudio/infra-deployments/pull/3616/files#diff-e961bdc3a405dfda1b39ed17ee82576bb68e2a35e9288e7de208e695e4ee5944R1497

We could force dev/stage/prod to specific sha's of the results image from here in infra deployments, and effectively pin the version here.

That way, if your operator bump is ready to merge before the testing completes with #3616 we could include something like this in the PR that does your operator bump without having to revert the results bump in openshift-pipelines/pipeline-service.

What do you think?

rh-pre-commit.version: 2.2.0
rh-pre-commit.check-secrets: ENABLED

[openshift-ci]

@gabemontero: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/appstudio-e2e-tests-ocp-4-14	2d6a81e	link	false	/test appstudio-e2e-tests-ocp-4-14

Full PR test history. Your PR dashboard.

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 kubernetes-sigs/prow repository. I understand the commands that are listed here.

[enarha]

An idea I had @enarha to bypass the results bump I'm getting performance QE to help me test with #3616

Rather than pick up the results image bumps like you see in https://github.com/redhat-appstudio/infra-deployments/pull/3616/files#diff-e961bdc3a405dfda1b39ed17ee82576bb68e2a35e9288e7de208e695e4ee5944R1497

We could force dev/stage/prod to specific sha's of the results image from here in infra deployments, and effectively pin the version here.

That way, if your operator bump is ready to merge before the testing completes with #3616 we could include something like this in the PR that does your operator bump without having to revert the results bump in openshift-pipelines/pipeline-service.

What do you think?

We can do that. But I would like to pin the prod versions as well (to whatever version), so we do not accidentally update prod when we promote the operator bump to prod.

[gabemontero]

An idea I had @enarha to bypass the results bump I'm getting performance QE to help me test with #3616
Rather than pick up the results image bumps like you see in https://github.com/redhat-appstudio/infra-deployments/pull/3616/files#diff-e961bdc3a405dfda1b39ed17ee82576bb68e2a35e9288e7de208e695e4ee5944R1497
We could force dev/stage/prod to specific sha's of the results image from here in infra deployments, and effectively pin the version here.
That way, if your operator bump is ready to merge before the testing completes with #3616 we could include something like this in the PR that does your operator bump without having to revert the results bump in openshift-pipelines/pipeline-service.
What do you think?

We can do that. But I would like to pin the prod versions as well (to whatever version), so we do not accidentally update prod when we promote the operator bump to prod.

Totally agree wrt prod @enarha . This was just a quick demonstration. Bottom line, let's apply this technique across dev/stage/prod when we are ready to bump the nightlies, in the nightly bump PR, if the results testing I've commissioned performance QE to help with has not completed.

Closing this out.

Thanks.

[gabemontero]

OK @enarha I'm making this official given the performance test results from staging over the weekend with that latest form of the mem leak / cancel context fix

Per my recent email, I'm back to reworking that

This will allow us to iterate in the pipeline service repo without reverting results bumps there. We'll simply undo dev, stage, then prod here as we vet the next version of the fix.

[enarha]

/lgtm
Just to confirm, you tried to regenerate the deploy.yaml files, but it did not yield any diff, right?

[gabemontero]

/lgtm Just to confirm, you tried to regenerate the deploy.yaml files, but it did not yield any diff, right?

correct @enarha

[enarha]

/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

Approval requirements bypassed by manually added approval.

This pull-request has been approved by: enarha, gabemontero

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:

• components/pipeline-service/OWNERS

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