Repository navigation
Split validation workflow #10
Description
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:
- 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).
- Otherwise, only local validations are run on the JSON files.
This means:
- Split everything below to a separate file
bluesky/actions/login-and-validate.js
Line 21 in dbdab89
- 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.
Activity
Ishan-Jadhav commentedon Dec 3, 2024
Hi joyeecheung,
Can I work on this issue?
joyeecheung commentedon Dec 3, 2024
Sure, go ahead please!
joyeecheung commentedon Jan 9, 2025
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.
Use pull_request in validation workflow
Use pull_request in validation workflow (#56)
aduh95 commentedon Jan 9, 2025
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 commentedon Jan 13, 2025
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:
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.