bdebon / choiceof.dev

Developers have to cope with pretty hard choices every day. This is a collection of the most complex and funny choices. What will be yours?
https://choiceof.dev
GNU General Public License v3.0
473 stars 93 forks source link

feat(pr): only check pr title on title changed #135

Closed Drarig29 closed 1 year ago

Drarig29 commented 1 year ago

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.

image

According to this note, the default config (if types is omitted) is: [opened, synchronize, reopened].

I think we don't need the synchronize and reopened events to trigger a PR title check here, since synchronize is triggered when the PR's base branch is updated and reopened is when a PR is... reopened.

Drarig29 commented 1 year ago

Works as expected:

image

bdebon commented 1 year ago

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...)

Drarig29 commented 1 year ago

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.

screenshot

bdebon commented 1 year ago

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!!

bdebon commented 1 year ago

:tada: This PR is included in version 1.9.0 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket: