ci: Execute stryker:dry-run on branches #302
Conversation
|
@brodybits I'm thinking about actually splitting the github actions files further, since I think it's actually not required to run |
karfau
force-pushed
the
ci-stryker-dryrun
branch
from
c28c1c8
to
9f15b3f
Compare
|
As a nit, I would favor splitting up test vs lint in a separate PR ... and moving lint into its own YAML file. LGTM otherwise. I would also favor merging this before we merge any other updates. |
|
Please let me know what you think is the benefit of having the linting in a separate file? |
karfau
force-pushed
the
ci-stryker-dryrun
branch
from
d129ff1
to
2e04dd7
Compare
|
Created #304 as draft to further discuss that aspect. But this one is ready now |
|
@brodybits It's slightly more redundant in the github action, but maybe that's worth it, check 1185c1d and judge yourself. Feel free to land it if you are fine with it. Update: I just realized that it now displays the master run as skipped on branches, not sure that's helping: |
brodybits
dismissed
their stale review
I think this still needs some further discussion now
Correct, but I think better than showing exactly the same thing for Stryker whether or not it is a dry run. I would like to try |
brodybits
changed the title
|
@karfau I have pushed some updates to separate the changes into a separate YAML file, to get rid of the useless "Skipped" job info, and make a few other, minor improvements. Using separate YAML files makes the CI testing more modular, at the unfortunate cost of copy-pasted config lines. I would love it if we could figure out how to reduce the amount of boilerplate config that has to be copied in GitHub actions, someday. Please feel free to update as needed or even discard my changes as you feel appropriate. Please let me know if you want me to merge this, or just merge it yourself if you like. Thanks again for looking into this one. |
|
@brodybits I must say that the amount of time we invest into this detail/"nit" is a bit to much for my taste... My perspective would be that we wanted a solution that has a chance to inform us when "our stryker setup would not work on master", but now we have "two stryker setups" and have to keep that in mind whenever we change something. We could of course try to reduce the config to maintain by adding something like https://github.blog/changelog/2021-08-25-github-actions-reduce-duplication-with-action-composition into the mix, but imo this should be a separate PR. My personal preference (regarding yaml file composition, not about Not sure how to proceed here. |
Yeah that sounds reasonable to me. I would love to find a way to improve this further someday, but yeah let's get rid of the multiple Stryker setups. I would also favor keeping the "-" I stuck into the dry-run but am not super attached to it. I think it does read better with the "-" but it does seem to add a little to the clutter. |
|
Will take care of it |
Dryrun works by passing a glob that matches no file. Additionally we reduce the reporters since there is nothing to report anyways. I decided to go for a CLI approach instead of a separate config file, since there is no way to extend config files, and I would like to avoid that we need to keep the two files in sync. stryker-mutator/stryker-js#3088 revert updates to .github/workflows/stryker.yml
karfau
force-pushed
the
ci-stryker-dryrun
branch
from
7f6f947
to
a9a53c9
Compare
|
I'm very happy about the current state. |
|
I cleaned up the commit message a little, hope I didn't butcher it too badly. |
Dry-run works by passing a glob that matches no file.
Additionally we reduce the reporters since there is nothing to report anyways.
I decided to go for a CLI approach instead of a separate config file,
since there is no way to extend config files, and I would like to avoid that we need to keep the two files in sync.
stryker-mutator/stryker-js#3088