Closed Drarig29 closed 1 year ago
Works as expected:
This is already an improvment I made yesterday to put the check before the test-and-build. Your solution is even cleaner but I wonder if it's gonna fix my real problem which is: CI will not run automatically for new contributor. I have to manually accept to run the ci for everyone of them which is super painful. Do you think this specific job could be launch for anyone or there is no other way to overcome that in a public repository (I understand the reason they do that...)
Hi! It's not exactly what you did: you made the PR title check first to run.
But once you (@bdebon) approve to run the workflows for a contributor, if the PR title check was failing and the contributor just changes the title to make the CI pass, the job won't re-run.
What my change does is that it will re-run when the approved contributor changes the PR title. It's just a nice to have, I agree.
Apparently, there is no way to override the behavior of approving to run workflows for forks for a single CI job. This is a repository-level setting.
However, if you are not paying for the CI you could just change this setting and trust contributors, if this is so painful (and I understand). Did you find the option in your repo's settings, Code Automation > Actions > General? (see screenshot below)
You could at least not require approval for contributors who are not new to GitHub.
Amazing is not enough to describe your contribution! I completely see the difference between what you did and mine. The auto relunch is key here! And thank you so much for the screenshot I did not know I could change this. I'm not paying for the ci yes so I will trust the contributors, at least I'll try!!
:tada: This PR is included in version 1.9.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:
What this PR is about?
This PR moves the "Check PR Title" job to a separate file, to have a different trigger configuration.
See events-that-trigger-workflows#pull-request for a list of possible trigger event types. And webhook-events-and-payloads#pull-request for their documentation.
According to this note, the default config (if
types
is omitted) is:[opened, synchronize, reopened]
.I think we don't need the
synchronize
andreopened
events to trigger a PR title check here, sincesynchronize
is triggered when the PR's base branch is updated andreopened
is when a PR is... reopened.