-
Notifications
You must be signed in to change notification settings - Fork 59
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
feature request: predict squash-merge commit on target branch and lint it as well #744
Comments
Hi @SvenStaehs! That's a nice suggestion, as you said we don't have actions that actually use commitlint on the PR title yet, so they won't work in 100% of the cases. |
Thanks! I also remembered our GHES server has an option to install serverside hooks, maybe that's an option. They're difficult to configure and should be used sparingly only for things that cannot be caught by PR checks, but I think this qualifies for that, so I'll look into that as well. |
Looking for the same thing @wagoid any update on that? |
Looking for the same thing too, do you accept PRs ? |
I finally opted on using the commitlint command directly, it works by getting the title param and piping it into the command. I suppose that's what should be tone to implement it here too. |
Hey @wagoid, I've forked created a PR #806 The PR: with bad squashed commit: with good squashed commit: |
This action checks the commits included in a PR before the merge, and it checks the push to target branch after the merge, but it does not warn the user if their PR would cause commitlint violations when merged to the target.
This happened recently in my project: we allow only squash-merge of PRs, with "default to pull request title and commit details" as commit message, so the commit on target branch has nothing to do with the commits we check during PR validation.
Of course there is nothing preventing the user from changing this default and entering whatever they wish, but commitlint-github-action could predict the default commit message on the target branch and run it through commitlint.
There are multiple ways the merge message on target branch can be generated:
So I guess I mainly want to start a discussion here if these things should be handled by this action at all or not.
I know about amann's action to check the title, but it does not actually perform a commitlint, especially it does not check the length at all (hence our recent issue that we ended up with a merge commit on main branch that commitlint complained about... At least it was still parsable by semantic-release, so it didn't break anything but the commitlint step.)
Alternatively, it would be nice if we could just provide arbitrary text to be linted. I tried generating an empty commit with the predicted message header, but during PR-triggered workflows the action reads the list of commits in the PR with octokit, so I have no way of adding my mock commit to that list.
If I could provide a "text-to-lint", that would solve my issue. Or a "commit-hashes" list that is used instead of reading it from PR, maybe this is useful for other circumstances as well?
Other workarounds include:
but I would far prefer using the same action that will double-check the push to target branch so I know the configuration is identical (e.g. for the length check with bash I won't be trying to read the commitlint.rc and will just hardcode the value ;)).
The text was updated successfully, but these errors were encountered: