Split validation workflow

[joyeecheung]

As mentioned in #5 (comment)

...apparently the secrets are not passed into workflow runs triggered by PRs from forks. So I guess that means we should split the validation into two parts:

1. If it's triggered by a PR from a branch in this repo (which means it must be from someone who already has write access here), it can invoke additional validation to check the URLs are reachable and valid (which requires access to bluesky secrets).
2. Otherwise, only local validations are run on the JSON files.

This means:

1. Split everything below

   bluesky/actions/login-and-validate.js

   Line 21 in dbdab89

   const agent = await login(account);

   to a separate file
2. Splitting https://github.com/nodejs/bluesky/blob/main/.github/workflows/validate.yml into two workflows, one local and one remote. PRs started from a branch in this repo get both run for them, and PRs from forks just run the one that's without the login.

[Ishan-Jadhav]

Hi joyeecheung,
Can I work on this issue?

[joyeecheung]

Sure, go ahead please!

[joyeecheung]

Reopened because of #55 - I think for maximum safety, we should still split the validation workflows and only invoke validation that needs secrets for PRs opened from this repo.

[aduh95]

Another idea would be to use a Merge Queue; the downside is we can't know there's a failure until we attempt to land the PR – basically, the process would be if a PR looks good enough to a reviewer, they add it to the merge queue (the usual green merge button on GH UI), and either the validation succeeds and the PR is merged, either it fails and the PR stays open.

Ideally we would not handle just the validation from the queue but also the actual processing, I'm not sure if that would work, I guess I can try and see.

[joyeecheung]

I think the only difference in that case is that when it fails the PR stays open? We are already able to do these with our current workflows:

1. Full validation if it comes from a branch here
2. Validate and process it once it's merged (it's also validated in process.js, just not going to be done after it's merged, not before it's merged).

This issue only proposes to add one more workflow to perform local validation for branches from forks, I think the merge queue idea would be separate, because using that still doesn't help anything with "at least get some early warning before we push the merge button", which is what this issue tries to address.