ci: Add GitHub Workflow

[seanpoulter]

Proposed Changes

This PR helps migrate to use GitHub Actions. Here's a summary from #1496:

• Add a GitHub Workflow
• Figure out how the website is updated (It is part of azure-pipelines.yml)
• Test Node.js versions (Release Schedule)
  • 12 (current)
  • 18 (maintenance)
  • v20 (LTS)
• Change the minimum supported version of Node.js from 12 to 16
• Modernize the build process

This PR:

• Adds a GitHub Workflow for CI/CD using Node 16
• Adds .nvmrc to track the minimum version of Node.js
• Removes the code to tweet on release
• Disables the steps to release and update the website from the Azure DevOps pipeline
• Configures the build/test to work with Webpack v4 and Node.js >= 17

TODO

• We must set up the secrets
  • BROWSER_STACK_ACCESS_KEY
  • BROWSER_STACK_USERNAME
  • BUNDLEWATCH_GITHUB_TOKEN
  • GITHUB_TOKEN (automatic)
  • NPM_TOKEN
  • SAUCE_ACCESS_KEY
  • SAUCE_USERNAME
  • TWITTER_ACCESS_TOKEN_SECRET (deleted)
  • TWITTER_CONSUMER_SECRET (deleted)

[seanpoulter]

More changes to come:

• Follow these docs to allow the build to continue-on-error for Node.js v18.
• Fix the build for Node.js v18. This is expected with Webpack v4 and won't be fixed.
  nodejs 17: digital envelope routines::unsupported webpack/webpack#14532 (comment)
• Update the build name

[seanpoulter]

If we keep the pipeline configured to run for the maintenance and current LTS versions, we probably don't need to retry the Jest tests 3 times in CI.

[jcubic]

I'm not sure if we will be able to get all required tokens without the help from original author. Last time I tried to contact him, he didn't reply. I think will try again on LinkedIn since I get the best output from contacting him there.

[jcubic]

Just added NPM token.

I think that GITHUB_TOKEN is added automatically by GitHub to be used in GH actions.

[jcubic]

Also added Sauce Labs access token and my username, I'm in isomorphic-git team, let's hope it will work.

[seanpoulter]

I'm not sure if we will be able to get all required tokens without the help from original author.

We could also try to exfiltrate them from the pipeline. Let me know if/when you want me to try.

[jcubic]

I don't think you can, they are saved in Azure as secrets, and they are written with asterisks.

[seanpoulter]

We can't access the secrets from the UI but you can use them in the pipeline and run whatever code we want. Here's an article for inspiration which prints them out with base64 encoding.

We could use the GitHub API to create secrets in the repo/org if we had a GitHub token with the right scope and permissions.

• Use the GitHub API to read the org/repo public key required to encrypt the secret
• Encrypt the secret
• Use the GitHub API to create the org/repo secret by name/encrypted value

I'd be surprised if we have the right permissions with the GitHub token used in ADO but we can try. Are we creating the secrets in GitHub for the repo or the organization? It changes the API and token scope we need. 😁

[jcubic]

If that worked, it would be great. But let's wait few days (especially during week days) until we will see if original author will respond on LinkedIn.

Are we creating the secrets in GitHub for the repo or the organization?

I've created secrets in repo, I have no idea what permission the token have.

[jcubic]

Got reply from Billie Hilton on LinkedIN, he said that he will provide the required credentials.

[seanpoulter]

Got reply from Billie Hilton on LinkedIN, he said that he will provide the required credentials.

That's great! Thanks Billie! I hope you're well! 👋

[jcubic]

I've merged the PR with disabled test. It seems there is a conflict with that file you modified there.

[seanpoulter]

I've merged the PR with disabled test. It seems there is a conflict with that file you modified there.

I fixed the conflict and rebased. If we get the secrets in I'd expect the Workflows to pass.

[jcubic]

Generated my own token and save it to BUNDLEWATCH_GITHUB_TOKEN.
I have access to Twitter account, but I think that you can't use their API for free anymore.

Got invitation to BrowserStack account, but there is some kind of conflict with my own Open Source subscription.

[seanpoulter]

I have access to Twitter account, but I think that you can't use their API for free anymore.

We should remove that integration then eh?

[jcubic]

Yes, I think so, but first I will check if there are no other way to post to Twitter.

[jcubic]

So I got invitation to BrowserStack account, but they don't have something like teams or orgs like in GitHub and got a warning that I need to delete my old account (I already have Open Source account for my other project). I talk with BrowserStack support just now, and it seems that I don't need to delete my account I can use my current one since only TOKEN is needed on BrowserStack part, and it will just work.

I will generate a token soon, will try today when I find some free time.

[jcubic]

Add BrowserStack, the Twitter can be removed.

[jcubic]

What else is needed?

[jcubic]

Note that you can't create a secret that start with GITHUB_

[seanpoulter]

Note that you can't create a secret that start with GITHUB_

Ah, sorry, the GITHUB_TOKEN is automatic. I should have checked that off.
Here's the docs - https://docs.github.com/en/actions/security-guides/automatic-token-authentication#about-the-github_token-secret

[seanpoulter]

What else is needed?

It's been a while so I've rebased and run the tests. It looks like I've got trouble accessing the Secrets from the Workflow:

• Based on line 146 it looks like the Workflow doesn't have access to the BUNDLEWATCH_GITHUB_TOKEN secret.
• Based on line 297 it looks like the Workflow doesn't have access to the SAUCE_USERNAME secret.
• Based on line 339-341 it looks like the Workflow doesn't have access to the BROWSERSTACK_USERNAME or BROWSERSTACK_ACCESS_KEY secrets

Once we resolve those issues, the tests might pass, and we can review the code.

[seanpoulter]

Based on these errors from Node v18 and v20, we also have to configure NODE_OPTIONS
https://github.com/isomorphic-git/isomorphic-git/actions/runs/8578378966/job/23512154927?pr=1879#step:5:298

[jcubic]

I think you can set some kind of permissions inside the workflow file. Maybe this is a problem. We can ask on GitHub Community forum about this issue. The secrets are there.

[seanpoulter]

OK. Great! Thanks for confirming they're Repository Secrets.

It turns out it is expected behaviour. Sorry. I'm not used to setting up Workflows in a fork. 🤦 From Using secrets in a Workflow:

With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository.

I'll do a bit more research to confirm how to set this up to run from a fork. I wonder if you reran what it'd do.

[seanpoulter]

This is a pretty good reference - https://dvc.ai/blog/testing-external-contributions-using-github-actions-secrets.

[jcubic]

I can create experimental branch workflow and you create PR to that branch.

[jcubic]

Sorry for the late reply, I totally forget that I need to do something. Created a workflow branch and I will merge your PR. You can create next PR against that branch.

[jcubic]

Created a PR #1901 with your changes. If you have any updates just create a PR to workflow branch and I will merge.