Make Test Suite Self-Contained Without AWS Credentials or External Secrets

[jrhoads]

Purpose

Make the test suite self-contained and remove its dependency on AWS credentials and deployed-environment secrets.

Approach

Configure tests to use local filesystem storage, provide dedicated test JWT keys, stub AWS SDK responses, and clean up generated report files after the test suite completes.

Key Modifications

• Removed required secrets and AWS environment variables from the GitHub Actions test workflow.
• Changed Paperclip test storage from Amazon S3 to the local filesystem under tmp/report_files.
• Added a test-only RSA keypair for JWT specifications.
• Configured AWS SDK SQS calls to use stubbed responses.
• Removed VCR’s allowance for uncaptured external HTTP requests.
• Added cleanup of generated report files after the test suite.
• Set the test environment log level to warn.

Important Technical Details

• CI tests no longer require AWS, MDS, session, or JWT secrets.
• Test report files are written to tmp/report_files and removed after the suite completes.
• AWS-related environment variables are explicitly removed during test setup to prevent local .env values from affecting tests.
• The committed RSA keypair is for test use only and is not used in deployed environments.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Reviewer, please remember our guidelines:

• Be humble in the language and feedback you give, ask don't tell.
• Consider using positive language as opposed to neutral language when offering feedback. This is to avoid the negative bias that can occur with neutral language appearing negative.
• Offer suggestions on how to improve code, e.g. simplification or expanding clarity.
• Ensure you give reasons for the changes you are proposing.

[richardhallett]

I don't think we should ever embed in our public repositories private/public key pairs, even if this is only ever used for the tests, it exposes a key that while currently won't be used in production, things can change and we could accidentally expose details we don't expect to.

Using github secrets is a better alternative because it's never then exposed. An alternative to this might instead be to just generate a key pair dynamically in the code.

[jrhoads]

While I don't 100% agree when these keys are kept in specs and not reused elsewhere, I think it is also fine to generate the pair dynamically. I don't think they should have to be kept in the environment whether that is provided in the github secrets or elsewhere.

I'll work on generating them dynamically

[jrhoads]

Looks like we have gone through iterations on this idea before in other projects
datacite/lupo@c5c3c61

Lupo currently uses fixtures for keys.

[jrhoads]

Thanks for taking a look at this @richardhallett . I've updated the helper so that it generates the public private pair once per Rspec process.

[jrhoads]

There are a couple of lines printed when the specs run; JWT decode ERROR lines that are the expected empty/abc token cases