-
Notifications
You must be signed in to change notification settings - Fork 465
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CI improvements #4307
CI improvements #4307
Conversation
fd8e07a
to
172e00b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the push and PR checks can be the same workflow, and you can check the event type to pivot for the changed parts?
f33d276
to
fa8c451
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If Jordan's happy, I'm happy
Applying only to .travis.yml seems to be a relic from when that was the only YAML file in the repo. Extend it to all YAML files.
We do not use these anymore. Generated tests are included in PRs and not deployed separately. The deploy key encryption relies on TravisCI which we don't use anymore, anyway.
This runs faster and allows for future improvements. I'm following a general principle of keeping code that isn't portable between CI providers inside the config file for the CI provider. So in this case we remove the Circle-CI-specific stuff from the file in tools/scripts/, and into .github/workflows/. We use an external action (tj-actions/changed-files) to gather the list of files to lint.
After the previous commit, it doesn't do much, only passes the linting exceptions file on the command line. Instead, make the lint.exceptions file the default for that argument (if it exists), and remove the shell script.
This should help contributors notice and fix linter errors when they occur. Apparently it's as easy as printing a magic string to stdout, who knew! The lint tool doesn't give line numbers so we place the annotations at line 1 for the time being.
This runs faster and allows for future improvements. Similar to the linter workflow, we remove the Circle-CI-specific stuff from the file in tools/scripts/, and into .github/workflows/. We use another external action (tj-actions/verify-changed-files) to check that generating the tests didn't create any new changes. This is basically a companion action to the tj-actions/changed-files used in the linter job.
After the previous commit, it doesn't do much. Just write its contents directly in the workflow step.
fa8c451
to
74c4b2a
Compare
Most of the time, we are not committing changes to the tools. Move the unit tests for the lint and generation tools to a separate PR workflow, that is only run if anything in the tools/ folder is modified in the PR. This saves time in the normal case.
Since we are using it in the other jobs, we may as well use it here. As a bonus, it will make the job work even if the target of the pull request isn't the main branch.
This reduces duplication, with the tradeoff of having some steps in the linter job that are mutually exclusive depending on the job trigger.
74c4b2a
to
418ed39
Compare
Hopefully everyone's happy with the current state of this. @ljharb would you mind doing the honors with the settings? You'll have to set "ci/circleci: Test262: verify tools; build & lint tests" to non-required, merge the PR, then set "Checks / Lint tests" and "Checks / Build generated tests" to required. I think it's under "Code and automation → Branches" in the settings. (https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule) |
All done. Merge at wil. |
Merged! |
Migrate linter and test generation workflow to GitHub Actions, and add some improvements
To merge this, we'll have to go into the settings, set the "ci/circleci: Test262: verify tools; build & lint tests" workflow to non-required, merge it, and then go back to the settings and set whichever new workflows we'd like to require.