Separate tests requiring secrets - require approval to run on PRs from forks [EAR-2132]

[ianhi]

Attempt at separating out tests requiring secrets so that PRs from forks require approval for anything with external srevices secrets.

Currently just manual approval for enabling these. But I think it's also possible with applying a label, however I coudn't get that without essentially duplicating the entire workflow. So for now just keeping it simple. Having a PR label approach can be a future step.

👀

[ianhi]

Ok, two actions for a reviewer:

1. Are we ok with the number of clicks to approve the workflow? The alternative is to use label-based allowing of these, but that has the downside of once you enable them, someone could push malicious or accidentally dangerous code

If we are happy with this approach then:
2. We need to add these secrets to the ci-with-secrets env, which unfortunately will require copying all of them in manually (you can't just transfer what env they live in). This is probably a task for @jhamman or @paraseba

Also note that there is a limit on the number of possible reviewers for this workflow (6 apparently)

[ianhi]

Seba and I talked about this and decided that this is the best way forward for now, with the option of adding labels to enable as well. WHich I would like to be a follow up PR if I'm going to do it.

The blocker here is the env secrets which I think will require action by @jhamman

For anyone curious to approve you can click th e"requested a deployment" here:

[dcherian]

Slick, i just clicked through and allowed it

[ianhi]

General stuff

Joe just added secrets to the ci-with-secrets envrinoment. He also moved the S3 test bucket to the earhtmover-sandbox.

We did not set up expiration rules yet, but anyone can do that.

We also moved the bucket and regions to variables instead of secrets.

We need to keep old secrets (not defined in teh environment) around so that they can be used by the cron jobs and internal PRs. We seemingly can't re-use the ci-with-secrets env for those without requiring approval. I think this might be possible with github protection rules, but I wasn't able to figure it out.

This PR

With these changes I just re-ran the tests and it looks like we went from many down to only one failure!

https://github.com/earth-mover/icechunk/actions/runs/18045693619/job/51355816407?pr=1226

Error: ICError { kind: StorageError(S3ListObjectError(ConstructionFailure(ConstructionFailure { source: InterceptorError { kind: ReadBeforeExecution, interceptor_name: Some("ListObjectsV2EndpointParamsInterceptor"), source: Some(BuildError { kind: MissingField { field: "bucket", details: "A required field was not set" } }) } }))), context: SpanTrace [] }


failures:
    test_concurrency_in_aws

I'm not sure why only one of them would fail. @paraseba can you look at that failure and help me figure out if thats a real failure, an issue with the new credentials, or something else?

[ianhi]

hmm. actually should this be runnign mroe tests? why are there so few now:

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 107 filtered out; finished in 0.00s

     Running unittests src/bin/icechunk/main.rs (target/debug/deps/icechunk-8e9a7a4c877f1b36)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests/test_concurrency.rs (target/debug/deps/test_concurrency-10fa0b4024df1d04)

running 1 test
test test_concurrency_in_aws ... FAILED