Build: add GitHub Actions workflow to update Filestash

[timmywil]

Summary

Replaces the jenkins workflow to update git versions of jQuery on the Filestash server. The filestash environment is already set up in the jQuery repo settings and includes the necessary SSH private key and filestash server URL.

Here's a sample of the workflow running as a dry run:
https://github.com/timmywil/jquery/actions/runs/8205613186/job/22442850764

We should disable the jenkins workflow before merging.

Checklist

• New tests have been added to show the fix or feature works
• If needed, a docs issue/PR was created at https://github.com/jquery/api.jquery.com

[Krinkle]

The following look great:

• Expose private key as "secret" rather than as "environment var", that way we control when it becomes visible, thus not making it visible during earlier steps.
• Install ssh key not until after install/build steps.
• Further limit secrets to a declared group (confusingly called "enviornment"), and the job to a given branch.

The following could tighten it further:

• Configure the secret in the repo setting by branch (i.e. protected-only, or list "main" there). This because as-is the restriction is in the file itself, which feels insufficient. I.e. if it is modified to allow branch X and pushed to X, or if another job is modified to enable the same "filestash" group secrets, that would bypass it. Putting the restriction also/instead in the repo settings would harden this.
• Consider removing use of actions/setup-node when the purpose of a build isn't to test specific or multiple Node.js versions. This action is pretty convoluted and heavy. The ubuntu image already comes with an LTS version of nodejs pre-installed. For Ubuntu 22 (ubuntu-22, ubuntu-latest) that is currently Node.js 18. https://github.com/actions/runner-images/blob/ubuntu22/20240218.1/images/ubuntu/Ubuntu2204-Readme.md. I imagine Ubuntu 24 will come soon with Node.js 20 (assuming it follows https://packages.debian.org/experimental/nodejs).

Neither a big deals. LGTM as-is.

[timmywil]

The first suggestion sounds good to me, but I prefer to have control and consistency over the Node version everywhere we build. I've learned not to trust whatever Node version comes preinstalled in the runner image. We've been bitten by that before, and I don't want to be at the mercy of the image's update schedule. FWIW, that step usually takes less than a second and is the same for all workflows that build.

[timmywil]

I've applied "protected branches only" to the environment, which includes main and *-stable

[mgol]

LGTM. Let me know when you're ready to merge so that I disable the Jenkins job.

One thing - with the Jenkins job being disabled before merging this, we no longer need to build on Node.js 10. You can remove it here if you want. That said, dropping Node 10 allows us to introduce a few improvements like upgrade Rollup (which I need for the exports improvements PR), switch to node:-prefixed Node.js core modules, using node:fs/promises instead of fs.promises from node:fs, dropping the jenkins npm script and maybe something else. If you'd like, you can group it all in a followup PR. I'd just prefer not to wait too long with dropping the build on Node 10.

[timmywil]

Thanks for making a list. I'll make those changes in a followup PR.

[timmywil]

Checked all files and they all updated as expected.