-
Notifications
You must be signed in to change notification settings - Fork 30k
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
build: add daily/on-demand internet test workflow #40086
Conversation
Do we know if the internet test pass on GitHub actions runners? |
Once I get the GitHub Action passing without changes to the internet tests, I will add a commit that changes an internet test to check. (Right now, it fails when you don't change the internet tests because |
.github/workflows/test-linux.yml
Outdated
@@ -31,3 +31,6 @@ jobs: | |||
run: make build-ci -j2 V=1 CONFIG_FLAGS="--error-on-warn" | |||
- name: Test | |||
run: make run-ci -j2 V=1 TEST_CI_ARGS="-p actions" | |||
- name: Test Internet | |||
# Only run if files in test/internet have changed. | |||
run: if [[ $(git diff --name-only origin HEAD -- test/internet) ]]; then make test-internet -j2 V=1; fi |
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.
run: if [[ $(git diff --name-only origin HEAD -- test/internet) ]]; then make test-internet -j2 V=1; fi | |
run: | | |
if [[ $(git diff --name-only origin HEAD -- test/internet) ]]; then | |
make test-internet -j2 V=1; | |
fi |
The only problem is that it will be green if there are no changes in test/internet, so it might not be practical to know if it really ran or not IMO. A solution would be (with fetch-depth: 0
):
- name: Get changed test/internet files
id: check-internet
run: echo "::set-output name=changed::$(git diff --name-only origin/${{ github.base_ref || 'master' }} HEAD -- test/internet)"
- name: Test Internet
# Only run if files in test/internet have changed.
if: steps.check-internet.outputs.changed
run: make test-internet -j2 V=1
But at this point, an action like https://github.com/tj-actions/changed-files could even be used.
Refs (-j2
-> -j
): #40080 (comment)
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.
The only problem is that it will be green if there are no changes in test/internet, so it might not be practical to know if it really ran or not IMO.
I'm OK with that, especially if it keeps the workflow simple and light on dependencies.
Refs (-j2 -> -j): #40080 (comment)
I left a comment there but I'm pretty sure we don't want to do that.
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.
The multi-line suggestion is a good one. Right now, this isn't working though because of the way the workflow fetches from origin
. So that if
stuff might be going away. If not, I'll do it your way for sure. Thanks! Pondering the right solution...
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.
What made you add --exit-code
?
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.
What made you add --exit-code?
git diff
always exits with code 0, even if diff is empty.
With --exit-code it exits with code 1 if changes, otherwise 0.
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 don't think we need that. The if [[ $( COMMAND ) ]]
means "true if there is any output from COMMAND, otherwise false".
For |
Yes, but I'm not sure how much overhead (and therefore additional time waiting for the job to complete) it would add. Do you have any idea?
That will only check the last commit. I want to check all commits in a PR. |
Approximately 1 minute vs 30 seconds for checkout. |
Argh, although I'm now realizing that comparing against |
We can simply compare between the SHA of the previous ("before"/"base") commit and the HEAD. This works for pull requests and pushes (and it's provided in |
- name: Get changed test/internet files
id: check-internet
run: |
changes=$(git diff --name-only ${{ github.event.pull_request.base.sha }} HEAD -- test/internet)
[ $? -ne 0 ] && exit $?
echo "::set-output name=changes::$changes"
- name: Test Internet
# Only run if files in test/internet have changed.
if: steps.check-internet.outputs.changes
run: make test-internet -j2 V=1 This should normally work. |
This started off as such a simple addition, but it's starting to seem like it will need a fair amount of stuff to make it work robustly and I wonder if this isn't the way to do it but to instead put it in its own workflow file. |
I also think this is the best solution. |
Added it as a daily/on-demand workflow for now. We can later improve it to run on pull requests and pushes when appropriate only (or not). |
Here's the workflow running on my fork: https://github.com/Trott/io.js/actions/runs/1226807643 |
on: | ||
workflow_dispatch: | ||
schedule: | ||
- cron: "5 0 * * *" |
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.
Added it as a daily/on-demand workflow for now. We can later improve it to run on pull requests and pushes when appropriate only (or not).
I want to say that it's almost useless if you do it that way. It would just be impossible to run this workflow on a PR that changes the internet tests, and that's a shame, it loses all its usefulness IMO.
on: | |
workflow_dispatch: | |
schedule: | |
- cron: "5 0 * * *" | |
on: | |
workflow_dispatch: | |
schedule: | |
- cron: '5 0 * * *' | |
pull_request: | |
types: [opened, synchronize, reopened, ready_for_review] | |
paths: | |
- test/internet/** | |
- deps/cares/** | |
- lib/dns.js | |
- lib/internal/dns/** | |
- src/cares* | |
- lib/dgram.js | |
- lib/internal/dgram.js | |
- src/*udp* | |
- lib/*http* | |
- lib/internal/http.js | |
- lib/internal/http2/** | |
- src/*http* | |
- src/tcp* | |
- deps/ng*/** | |
push: | |
paths: | |
- test/internet/** | |
- deps/cares/** | |
- lib/dns.js | |
- lib/internal/dns/** | |
- src/cares* | |
- lib/dgram.js | |
- lib/internal/dgram.js | |
- src/*udp* | |
- lib/*http* | |
- lib/internal/http.js | |
- lib/internal/http2/** | |
- src/*http* | |
- src/tcp* | |
- deps/ng*/** | |
branches: | |
- master | |
- main | |
- canary | |
- v[0-9]+.x-staging | |
- v[0-9]+.x |
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.
The additions you're proposing here may be worth doing, but we should probably keep it on a schedule too. Other changes may break internet tests (such as changes to cares or dns.js) and we might not notice for a long time. If it's a month later, it will be very useful to have daily results to go back to so we can immediately narrow the issue down to a single day's worth of commits.
My idea was that someone can manually launch the job on PRs if the PR branch is in the repo. (Or they can launch it on their own branch if it's in their repo.)
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.
By the way, the "run once a day and run it manually" mirrors what we do on Jenkins now, so they idea is that this would allow us to get rid of the Jenkins job.
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.
(Although it does seem like the Jenkins job runs much faster. Maybe I'm doing something wrong in the workflow and there's a way to have a persistent compile cache to speed things up or something.)
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 have updated the suggestion.
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 it's OK with you, I think my preference is to land this as-is and then incrementally add these files/paths over time. We've gone years and years without having these jobs run automatically, and there's always been certain concerns around running them routinely in CI. These concerns (don't want to hit a DNS, web, or other external service too much from our CI, for example) may not be well-founded, but just in case, I think an incremental approach is still the way to go.
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.
It's OK with me.
Landed in e016cc7...ed556c0 |
PR-URL: #40086 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Michaël Zasso <[email protected]>
PR-URL: #40086 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Michaël Zasso <[email protected]>
PR-URL: #40086 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Michaël Zasso <[email protected]>
Allows on-demand and nightly runs of the internet tests.