Update to latest commit of argo-rollouts-manager '1824164aac67c5eb8e331238ec9f602809537ab4' and argocd-operator '0433a07294f89d858bc88192f9b96155985cec46'

[jgwest]

Update to most recent 'argo-rollouts-manager' commit: argoproj-labs/argo-rollouts-manager@1824164 and 'argocd-operator' 0433a07294f89d858bc88192f9b96155985cec46

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign jopit for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

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

[jgwest]

�[36mINFO�[0m[2026-02-25T11:26:34Z] Acquiring leases for test kuttl-sequential: [gitops-aws-quota-slice] 
�[31mERRO�[0m[2026-02-25T13:26:34Z] error: Failed to acquire resource, current capacity: 0 free, 10 leased 
�[36mINFO�[0m[2026-02-25T13:26:34Z] Ran for 2h4m27s                              
�[31mERRO�[0m[2026-02-25T13:26:34Z] Some steps failed:                           
�[31mERRO�[0m[2026-02-25T13:26:34Z] 
  * could not run steps: step kuttl-sequential failed: failed to acquire lease for "gitops-aws-quota-slice": resources not found 
�[36mINFO�[0m[2026-02-25T13:26:34Z] Reporting job state 'failed' with reason 'executing_graph:step_failed:utilizing_lease:acquiring_lease' 

/retest

[jgwest]

/retest

[ranakan19]

I was able to verify sha256 value of metric-plugin-linux-amd64. I do see a difference from argoproj-labs/argo-rollouts-manager@1824164 as rollouts-manager is still using v0.0.3.
So my only question is around the different sha format. My guess is we were previously using a sha1 format even when the field was called sha256 are now getting to correct it. However if thats not the case, I'm curious to know more.

[ranakan19]

different sha length here stands out to me, is this intentional?
also the sha is different from argoproj-labs/argo-rollouts-manager@1824164

[jgwest]

The old value was invalid (it's not even the right length for sha256 😅 ), but because the argo rollouts manager code wasn't properly applying the SHA to the ConfigMap, it wasn't caught by the test.

The current value is the new, correct value; you can verify manually by downloading the binary and running sha256sum "(downloaded binary from url)" (IIRC sha256sum only works on Linux, but mac os has an equivalent)

[ranakan19]

same question here

[jgwest]

Yup, same as above, the new value is the actual correct value (no idea what the provenance of the old value was)

[ranakan19]

I found my answers here and here - hopefully it helps someone else reviewing it later, so leaving them here. LGTM otherwise

side note:
I was looking for rollouts-manager release note for v0.0.8 to see if migration of cm key is mentioned, but did not see the release, am i missing something?

[jgwest]

I was looking for rollouts-manager release note for v0.0.8 to see if migration of cm key is mentioned, but did not see the release, am i missing something?

My strategy for rollouts-manager is we first ship a particular commit downstream (in this case, 1824164aac67c5eb8e331238ec9f602809537ab4), and once that release has shipped, THEN I create the GitHub release and tag. So you will see the proper GitHub release of argo-rollouts-manager shortly after downstream product is out.

This avoids the issue where this happens, for example:

1. You want to consume a library v1.0 via a downstream product, so you create a v1.0 release for the library
2. You find a bug in v1.0 after some testing the library with downstream product during QE testing.
3. You fix the bug and create a v1.0.1.
4. You find another bug during QE testing via the downstream product.
5. You fix the bug and create a v1.0.2.
   etc.

It would have been less churn if one had just waited for downstream testing to complete before creating the GitHub release.

An example of exactly this recently was argocd-agent made it to v0.5.3 (starting at v0.5.0) as we kept needing fixes in upstream library (argocd-agent) due to finding issues via QE testing downstream.

I'm not sure if this is exactly the orthodox approach, but it makes sense to me 😁

[chetan-rns]

LGTM!

/lgtm

[openshift-ci]

@jgwest: The following tests 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/v4.14-kuttl-parallel	8cc13c9	link	false	/test v4.14-kuttl-parallel
ci/prow/v4.14-e2e	8cc13c9	link	true	/test v4.14-e2e
ci/prow/v4.14-kuttl-sequential	8cc13c9	link	false	/test v4.14-kuttl-sequential

Full PR test history. Your PR dashboard.

Details

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.

[jgwest]

Merging as v4.14 tests are still failing due to external rate limiting.