| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
There was a problem hiding this comment.
This PR refactors pr-checks/sync.ts to make workflow generation more modular, and introduces first-class support for generating additional “validation jobs” that run after the primary PR-check job.
Changes:
Copilot reviewed 21 out of 21 changed files in this pull request and generated 4 comments.
Show a summary per file| File | Description |
|---|---|
| pr-checks/sync.ts | Adds validation-job generation and refactors setup-step/matrix/job generation into reusable helpers. |
| .github/workflows/__with-checkout-path.yml | Regenerated output reflecting reordered setup steps/inputs. |
| .github/workflows/__upload-sarif.yml | Regenerated output reflecting reordered setup steps/inputs. |
| .github/workflows/__upload-ref-sha-input.yml | Regenerated output reflecting reordered setup steps/inputs. |
| .github/workflows/__unset-environment.yml | Regenerated output reflecting reordered setup steps/inputs. |
| .github/workflows/__swift-custom-build.yml | Regenerated output reflecting reordered setup steps/inputs. |
| .github/workflows/__split-workflow.yml | Regenerated output reflecting reordered setup steps/inputs. |
| .github/workflows/__remote-config.yml | Regenerated output reflecting reordered setup steps/inputs. |
| .github/workflows/__packaging-inputs-js.yml | Regenerated output reflecting reordered setup steps/inputs. |
| .github/workflows/__packaging-config-js.yml | Regenerated output reflecting reordered setup steps/inputs. |
| .github/workflows/__packaging-config-inputs-js.yml | Regenerated output reflecting reordered setup steps/inputs. |
| .github/workflows/__packaging-codescanning-config-inputs-js.yml | Regenerated output reflecting reordered setup steps/inputs. |
| .github/workflows/__multi-language-autodetect.yml | Regenerated output reflecting reordered setup steps/inputs. |
| .github/workflows/__local-bundle.yml | Regenerated output reflecting reordered setup steps/inputs. |
| .github/workflows/__go.yml | Regenerated output reflecting reordered setup steps/inputs. |
| .github/workflows/__go-custom-queries.yml | Regenerated output reflecting reordered setup steps/inputs. |
| .github/workflows/__export-file-baseline-information.yml | Regenerated output reflecting reordered setup steps/inputs. |
| .github/workflows/__config-input.yml | Regenerated output reflecting reordered setup steps/inputs. |
| .github/workflows/__build-mode-manual.yml | Regenerated output reflecting reordered setup steps/inputs. |
| .github/workflows/__analyze-ref-input.yml | Regenerated output reflecting reordered setup steps/inputs. |
| .github/workflows/__all-platform-bundle.yml | Regenerated output reflecting reordered setup steps/inputs. |
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM.
Meta: We are getting closer to designing a full workflow generation framework, but I think this is an effective sweet spot.
My comments are mostly on maintainability, the generalizations themselves are fine.
Sorry, something went wrong.
|
|
||
| if ( | ||
| setupSpec === undefined || | ||
| checkSpecification[setupSpec.specProperty] !== true |
There was a problem hiding this comment.
How about:
| checkSpecification[setupSpec.specProperty] !== true | |
| !checkSpecification[setupSpec.specProperty] |
Sorry, something went wrong.
There was a problem hiding this comment.
Personal preference, but I generally prefer the explicit check due to JS weirdness about truthiness.
Sorry, something went wrong.
- Add explicit `setup-python` step with condition to the workflow that was still using it - This allows simplifying the logic in `sync.ts`
The behaviour of `installPython` now mirrors other `install*` options
…he same specifications
|
For be7fe2b, I bumped the lib version in the tsconfig.json for pr-checks (since apparently the union method requires the latest ES version). That should be OK since the scripts in pr-checks are only used in development or CI environments. This required me to make a subsequent change to the pr-checks.yml workflow as well, since the pr-checks script checks were run as part of the (matrixed) unit-tests job there, which runs with both Node 20 and Node 24. That makes sense for the unit tests etc. for the main codebase, but less so for the pr-checks scripts where it now caused a failure. I am guessing that this was just an oversight when we added the node-versions matrix to run the tests with the node versions we use for both v3 and v4. |
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM. Thanks for the follow-ups.
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
The primary goal of this PR is to add support for additional, validation jobs to sync.ts. My motivation for this is #3519 (review). To add a PR check which does that, the most sensible way of testing it would be to run a second job after the main one which verifies that the artifact was successfully uploaded.
This PR doesn't yet add or modify a PR check which makes use of this new functionality. I will add that as part of #3519 once this PR is merged.
I have refactored a few things in the first commits to break up the horrible long main function that we had initially ported from the earlier sync.py script as-is in #3526.
The refactoring has introduced some minor changes to the generated workflow files because the order of the various setup-* steps is now alphabetical, rather than effectively random. This should not have any impact on the behaviour of the workflows.
Notes for reviewers
Best reviewed commit-by-commit. Since these changes do not affect the CodeQL Action itself, a relatively lightweight review which focuses on the following is acceptable:
I have locally verified that the changes here broadly work for what I have in mind for the new workflow for #3526. Any small adjustments that may be required to support the full workflow could be added in that PR.
Risk assessment
For internal use only. Please select the risk level of this change:
Which use cases does this change impact?
Environments:
How did/will you validate this change?
If something goes wrong after this change is released, what are the mitigation and rollback strategies?
How will you know if something goes wrong after this change is released?
N/A
Are there any special considerations for merging or releasing this change?
Merge / deployment checklist