-
Notifications
You must be signed in to change notification settings - Fork 148
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
[TASK] Move the coverage generation to a separate CI workflow #427
Conversation
87a61db
to
54aaec8
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'm going to rebase this so that I can check it properly...
I'm looking for no overall change of behaviour for this commit, after which it will be clearer what is being changed in the CI jobs, when they are changed.
54aaec8
to
6d96d8e
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.
That was an educational review. I understand now how the matrix
works with include
, but haven't quite got to grips with the with
parameter. I don't understand what uses it and how. Maybe best keep those in for now.
I think you've added PHP 7.4 to the unit tests as well as code coverage, and would prefer to keep this PR to a refactoring only (with no overall change). I think a command line argument for code-coverage can now be dropped from the original unit tests section.
The number of CI tests should remain the same.
php-version: ${{ matrix.php-version }} | ||
ini-values: error_reporting=E_ALL | ||
tools: composer:v2 | ||
coverage: none |
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 uses this? Is it possible to lose the coverage: none
?
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.
Setting coverage: none
has the result of no code coverage tool (like Xdebug of PCOV) getting loaded, which should speed up the non-coverage tasks a bit.
345f50d
to
171ea94
Compare
I have now restructured things a bit, moved the coverage generation to a separate workflow, and undone the cleanup/refactoring to keep the changes more clear. |
171ea94
to
42501d3
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 like the separation with a new workflow file. Much cleaner and more maintainable - hopefully.
A couple of gremlins still need removing from the original ci.yml
.
d561a48
to
5b0705c
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.
Can we lose the coverage: none
from the original ci.yml
? I don't think it's needed any more.
Also, we are now not getting a 'Code coverage' on |
on: | ||
push: | ||
branches: | ||
- master |
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.
Is the indentation wrong here? Something seems to preventing a match.
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.
Extra spaces should not matter. It looks correct, so IDK why it's not working.
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've just rebased and repushed, an the coverage job seems to have run fine for me.
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.
Can't see a problem now, though the checks run this time have been the pull_request
checks rather than the push
checks. I'll approve and hopefully will see some checks run on 'push' from the merge.
Oh, I've just realized why the code coverage wasn't run - you're pushing to the task/coverage-separate
branch, not master
- it's only supposed to run on pushes to master
. D'oh, sorry.
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 CI should have run for the pull_request
trigger, though.
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 CI should have run for the
pull_request
trigger, though.
Strange. When I reviewed last night, it definitely showed 12 succussful checks on 'push', rather than 13 on 'pull_request'. I wouldn't have spotted this potential problem otherwise.
This makes the CI configuration easier to understand.
5b0705c
to
39390bb
Compare
This makes the CI configuration easier to understand.