[ShahzebMahmood]

The ECR tests in the Tests step used static AWS keys. This moves them to an OIDC role in a separate account that's only used for wave's CI tests.

• configure-aws-credentials assumes the role on push events. fork PRs don't get an OIDC token, so they skip the ECR tests like before.
• The role ARN is passed as the registry username, so AwsEcrService assumes it with wave-ci as the external ID.
• the test registry, build repo and cache in application-test.yml and the tests now point at the new account

tested on this branch's push run, the ECR tests ran against the new account and passed: https://github.com/seqeralabs/wave/actions/runs/40527055503

[claude]

APPROVE: a CI and test-config change that moves the ECR tests to a dedicated test account using OIDC. I found no correctness or security issues.

What I checked:

• Credentials. The long-lived TOWER_CI_AWS_ACCESS/TOWER_CI_AWS_SECRET keys are gone. aws-actions/configure-aws-credentials replaces them and is pinned to a commit SHA. The job already has id-token: write (build.yml:43).
• How the tests authenticate. WAVE_TEST_ECR_USERNAME is the role ARN and WAVE_TEST_ECR_PASSWORD is the external ID (wave-ci). Because the username matches AWS_ROLE_ARN, AwsEcrService.getLoginToken takes its role-based path (AwsEcrService.groovy:446). No jump role is set in test config, so Wave assumes the role directly with the default credentials that the OIDC step exports.
• Account-wide AWS checks still run. Tests gated on AWS_ACCESS_KEY_ID (proxy, build-live, auth) still run on push, because the configure step exports those variables into the job env.
• No coverage lost on PRs. The job's if: only runs on push and on fork PRs, and fork PRs never had the secrets. The github.event_name == 'push' guards on the configure step and on the new env vars keep the earlier behaviour: ECR tests skip on forks.

Notes (non-blocking):

• The token test only passes if WAVE_CI_ECR_ROLE_ARN trusts itself as a principal with sts:ExternalId = wave-ci, since the OIDC session assumes the same role again. That lives in IAM, not in this PR, and I couldn't verify it. CI on master will show it.
• The ECR-public tests (RegistryAuthServiceTest 'test valid aws ecr public', ProxyClientTest 'ecr public') now get a role ARN plus external ID as credentials for public.ecr.aws. This works if the role-based path covers ecrPublic=true, which it seems to. The role also needs ecr-public:GetAuthorizationToken and sts:GetServiceBearerToken.
• Other references to 195996028523 remain in build.gradle, run.sh, config.yml, application-local.yml and the release/deploy steps of build.yml. These are deploy and local-dev targets, so leaving them looks intentional.
• The test images (wave/app:1.0.0 and the wave/build/dev and wave/build/cache repos) must exist in account 935786761764 for the ECR tests to pass.

I did not run the tests locally because they need the AWS role.

[pditommaso]

Can all env names remain the same ?

[ShahzebMahmood]

No, I don't think we can

configure-aws-credentials exports the OIDC session creds as AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY / AWS_SESSION_TOKEN, and AwsEcrService builds its STS client with the default credentials provider to assume the role:

wave/src/main/groovy/io/seqera/wave/service/aws/AwsEcrService.groovy

Lines 197 to 201 in d63f3e7

	protected static StsClient stsClient(String region) {
	return StsClient.builder()
	.region(Region.of(region))
	.credentialsProvider(DefaultCredentialsProvider.builder().build())
	.build()

if the test step kept setting AWS_ACCESS_KEY_ID to the role arn it would override those, and the sts call would get the arn as an access key and fail. so the registry username/password needed their own names.

push run on the current head with both sets side by side, ecr tests assuming the role and passing: https://github.com/seqeralabs/wave/actions/runs/40548086915