Skip to content
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

Open
wants to merge 10 commits into
base: main
Choose a base branch
from
Open

CI improvements #4307

wants to merge 10 commits into from

Conversation

ptomato
Copy link
Contributor

@ptomato ptomato commented Nov 5, 2024

Migrate linter and test generation workflow to GitHub Actions, and add some improvements

  • Faster, with parallelized jobs
  • Don't run unit tests of tools if the tools didn't change
  • Now adds annotations to the PR for linter errors, so that contributors will more easily notice, locate, and fix them

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.

@ptomato ptomato requested a review from a team as a code owner November 5, 2024 00:25
@ptomato ptomato force-pushed the ci-improvements branch 9 times, most recently from fd8e07a to 172e00b Compare November 5, 2024 02:06
@ptomato ptomato changed the title Draft: CI improvements CI improvements Nov 5, 2024
@ptomato
Copy link
Contributor Author

ptomato commented Nov 5, 2024

Screenshot of what the linter annotations look like:
Screenshot from 2024-11-04 17-28-14

Copy link
Member

@ljharb ljharb left a 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?

.github/workflows/checks-main.yml Outdated Show resolved Hide resolved
if: failure()
run: |
awk -F': ' <errors.out \
"{ sub(\"$(pwd)/\", \"\"); printf \"::error file=%s,line=1::%s\n\", \$1, \$2 }"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please file a followup issue to see if we can easily output line numbers

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#4319

@ptomato ptomato force-pushed the ci-improvements branch 2 times, most recently from 2bc86f9 to f33d276 Compare November 7, 2024 19:26
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.
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 never get executed in one or the other situation.
Comment on lines +4 to +6
- push:
branches:
main
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any reason not to run this on any branch push?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems to me that only the pull_request checks are prominently visible in the UI and are likely to be noticed. I'd still like to have them run on pushes to main so that we can monitor if anything incorrect is merged, so that's why I added the push trigger. But otherwise in the usual case where you push a branch and open a PR almost immediately, we'd just be running a job that no-one will see.

That said, I'm not opposed to this; just think it's unnecessary.

name: Test tools

on:
pull_request:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
pull_request:
push:
pull_request:

Copy link
Contributor

@Ms2ger Ms2ger left a 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants