CI errors downloading test results from S3 when PRs are submitted from people who aren't me

[cormacrelf]

See #128 (comment), #133

(Note to self, this PR's checks ran without the AWS keys necessary to fetch the master test run results. Using the annoying cross-workflow artefact download thing instead of S3 would alleviate this.)

[stakats]

Can this be fixed by storing the keys as repo secrets?

…

On 2 Nov 2021, at 05:28, Cormac Relf ***@***.***> wrote:  See #128 (comment), #133 (Note to self, this PR's checks ran without the AWS keys necessary to fetch the master test run results. Using the annoying cross-workflow artefact download thing instead of S3 would alleviate this.) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[cormacrelf]

They already are, I don't think it would help to move to org level secrets either because I think the logic is "PRs from forks cannot use any secrets ever", hence you only ever need to look at one repository's access control settings to see who can touch the secrets.

The secrets give access to one S3 bucket on my own AWS account. I have been meaning to rectify that anyway. Not for cost (basically free), I just don't think anyone wants that long term. From least to most permanent fixes:

• have @tnajdek push to branches on zotero/citeproc-rs and PR those branches, instead of from a fork.
• implement it in Github Actions, removing the S3 bucket entirely. This would use a read-only GITHUB_TOKEN on pull requests from forks, so would work fine.
• just delete the regression testing! You can just run these tests normally. It's not as useful when they are all meant to pass, instead of just some of them.

I think I'll just do # 3, a solution that deletes code is a rare treat.