-
Notifications
You must be signed in to change notification settings - Fork 0
Adding conditional github actions job execution #1417
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
base: develop
Are you sure you want to change the base?
Conversation
❌ 1 Tests Failed:
View the top 1 failed test(s) by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
9e13c15
to
9856db7
Compare
9856db7
to
f33fbc4
Compare
4fa1d02
to
7d86fce
Compare
58dd33b
to
220739b
Compare
220739b
to
7ea05ed
Compare
…t branch creation, instead of base branch now
0bf931a
to
6b023ad
Compare
a7311af
to
ecd1227
Compare
LICENSE
Outdated
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 there are some unintended changes here, in the README and in some of the tests below.
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.
Thanks for pointing it out; I've undone the extra changes in random files (they were for testing the job execution), and I've put 3 commits for the different setup configurations.
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.
Currently testing option 3, just noticed that a change to a unit test file itself doesn't currently get picked up as a change.
Also tested merging in a conflicting change - the merge commit didn't seem to trigger (I think that was my fault though) so I triggered it manually and the tests did run on the merge changes as expected.
As discussed I think the biggest issue with option 3 is the fact that if I change a file, break the tests then in another commit make a change elsewhere e.g. the readme, the CI will pass on the whole PR even though there is still a broken test somewhere. Like you said one way around it would be to use artifacts to carry over the requests but I wonder if that might make it too complicated. Overall I currently think option 2 would be the best one for now.
Agreed, Option 3 has some extra caveats required as well to make it work; for instance, you need to run it one more time before merging, including all files changed in the PR, (not just the last commit), to pick up any relevant changes from develop, which adds more complexity/hassle. Option 2, albeit a small improvement, doesn't have any drawback really, other than maintenance of the extra LOC. |
4f444fa
to
79ed40a
Compare
The status checks above are stuck: Manually triggering seems to work e.g. https://github.com/ral-facilities/inventory-management-system/actions/runs/16494115304/job/46635643993. After investigating it seems its because of the new detect_changes step, the branch protections need to be modified to include it but its not on develop so doing so will cause the same issue for all other PRs. |
Description
This is an experimental PR to configure the github actions jobs to not all execute on every commit.
Summary:
Advice is to not implement any of the options; Options 1 and 2 provide a small efficiency improvement (1-2%), and Option 3 is not viable (explained in below sections). This PR, which is investigating using test selection in the jobs themselves is much more promising. 1 possible area of further investigation is configuring the dependancy bot PRs, since they make up a sizeable chunk of jobs ran.
Configuration Options:
Option 1. Do not run any build jobs if only certain files are changed (mainly documentation i.e, README, License, etc)
Option 2. Do not run individual test jobs if only unrelated test files are changed in this PR (i.e unit tests are skipped if only cypress files are changed in the whole PR history (since branching from develop)) (Done for unit tests)
Option 3. Do not run individual test jobs if only unrelated test files are changed in this commit (i.e unit tests are skipped if only cypress files are changed in the current commit, any component file changed triggers all tests).
N.B Option 3 does not seem plausible anymore. If implemented like this, it would ignore changes made to files in develop when running tests. For instance if in a commit, no unit test files are changed then unit tests would not be ran, even if they were changed in develop after branching off of it. This poses a problem for merging PRs; 1 solution would be to force a manual workflow everytime before merging, but that seems cumbersome, and would offset some efficiency gains.
Analysis:
A random sample of 50 human commits was taken from this repository from the last 6 months, and each was evaluated to see if the above proposed configurations would have any effect. Results are as follows:
N.B. Test Job refers to a job in the context of Github actions workflows, i.e every workflow has 3 test jobs (unit, e2e w/ api, e2e mock)
Testing instructions
Branch off of this branch, open a new pull request, and from there you can checkout commits for the different option configurations and push file changes to see which jobs get run.
Agile board tracking
Closes #1458