ci: use arm runners for arm64 workflows

[YOU54F]

arm64 runners now available, so lets use them to speed up our CI runs

https://github.blog/changelog/2025-01-16-linux-arm64-hosted-runners-now-available-for-free-in-public-repositories-public-preview/

the test-arm64 workflow only tested alpine, so the glibc case was not covered.

the test-alpine workflow, using containers as a first class concept in gh actions, unfortunately do not support arm64 yet

JavaScript Actions in Alpine containers are only supported on x64 Linux runners. Detected Linux Arm64

so this PR

1. removes qemu on test-arm64 workflows
2. replaces ubuntu-latest (x64) runner with ubuntu-24.04-latest (arm64) runner
3. tests glibc case by running the npm ci && npm test workflow on the native ubuntu-24.04-latest (arm64) runner
4. tests musl case by running the existing test step against the alpine image, using the native ubuntu-24.04-latest (arm64) runner

[YOU54F]

nice work on the prior workflow rejig @JP-Ellis

[codecov-commenter]

Welcome to Codecov 🎉

Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.

Thanks for integrating Codecov - We've got you covered ☂️

[YOU54F]

hmm we can't pass status checks as this has come from a fork, and we require secrets to publish to the pactflow hosted broker

[YOU54F]

we probably want to either skip these tests on forks, or hard code the secret if jobs come from outside forks.

[YOU54F]

I've noted that blocker in #1344

[YOU54F]

superseded by #1345 which comes from origin, rather than my fork

[JP-Ellis]

I think some settings in our repo can adjust this, but let me check.

[JP-Ellis]

Actually, instead of hard-coding them or putting them as secrets, you can probably just make them available as non-secret variables.

[JP-Ellis]

@mefellows and @YOU54F Any objections to exposing PACT_BROKER_BASE_URL and PACT_BROKER_TOKEN as variables instead of secrets?

[mefellows]

@mefellows and @YOU54F Any objections to exposing PACT_BROKER_BASE_URL and PACT_BROKER_TOKEN as variables instead of secrets?

No real objections from me. The risk is somebody uses the info to pollute the test account (arguably it's already quite polluted :P). If we see problems of abuse we can address it then.

[YOU54F]

no objections from me, that particular token is already exposed elsewhere.

I would be inclined to pop a comment in the code to state that this isn't best practise and is instead being used to support contributors forked workflows for our OS project. That way if we are leading by example, users know to store in a secret instead in their own projects

[JP-Ellis]

Great! I've added them as org variables. I'll go through the repos today and make sure everyone is using that over the secret, and then delete the secret.

[YOU54F]

fab, especially adding as an org variable as we can switch if we need to and maintainers and contributors test workflows if not hardcoded will be able to continue

[JP-Ellis]

And here I was, thinking that "because variables aren't secret, they'll be shared to PRs from forks" 🤦 That is not how GitHub has this unfortunately.

See for example this discussion.

Looks like the only option is using the pull_request_target trigger which has its own issues, and is ideally implemented using some sort of review process. I might give this a bit of a test in Pact Python and see if I can get something that can be shared to other repositories.

[JP-Ellis]

Ok, after doing a lot of reading, I'm now of the opinion that what we want is not easily feasible without either:

• Exposing all secrets, even if not explicitly used by the workflow
• Requiring the all maintainers review every workflow

I think the best course of action is:

1. Jobs triggered by a pull request should never require any secrets. When it comes to publishing Pacts, this means we must use local publishing using local files.
2. Once jobs have landed into main, then additional jobs can run that make use of the secrets.

This would be done by having some jobs by gated as follows:

jobs:
  no-secrets-required:
    # as usual

  secrets-required:
    if: github.event_name == 'push'
    # rest as usual