Pass if >= 1 commit message passes commit lint?

[cmitzel-ncino]

Hey!

I found this action from my previous contribution to python-semantic-release, and thought it was a neat way to enforce semantic commits. While testing this action for our organization, we've found that the action only passes if every commit in the PR passes the linter. At this moment, we don't want to add that amount of friction to our hundreds of engineers workflows, but we'd love to enforce at least one relevant commit message in a given PR. It also fails if any of the messages don't pass, meaning that unless an engineer does some git-fu to rebase their commits they'd have a permanently failing check if any of their messages didn't adhere to the spec.

Is there a way to configure this action to pass or simply throw a warning at least 1 of the commits passes the linter? That would be acceptable for our purposes while our bothering our engineers the least we can.

Thanks!

[cmitzel-ncino]

I did get a custom config file, but it's not all encompassing - it simply makes things less restrictive down to the semantic structure rather than the conventional commit structure.

module.exports = {
	parserPreset: 'conventional-changelog-conventionalcommits',
	rules: {
		'body-leading-blank': [1, 'always'],
		'body-max-line-length': [2, 'always', 100],
		'footer-leading-blank': [1, 'always'],
		'footer-max-line-length': [2, 'always', 100],
		'header-max-length': [2, 'always', 100],
		'subject-case': [
			2,
			'never',
			['pascal-case', 'upper-case'],
		],
		'subject-empty': [2, 'never'],
		'subject-full-stop': [2, 'never', '.'],
		'type-case': [2, 'always', 'lower-case'],
		'type-empty': [2, 'never'],
		'type-enum': [
			2,
			'always',
			[
				'build',
				'chore',
				'ci',
				'docs',
				'feat',
				'fix',
				'perf',
				'refactor',
				'revert',
				'style',
				'test',
			],
		],
	},        
};

[wagoid]

Hi @cmitzel-ncino! This action supports programmatic access to results array in your workflow, and I believe you could use that together with workflow expressions for your use case. Let me know if that doesn't work for you 👊

[cmitzel-ncino]

Hey! I looked into this on-and-off and managed to get a workflow with different two different jobs in which the second could access the results array from the first commit_lint job, but I couldn't figure out how to get that first job to pass forcefully. We don't really want our engineers to be stuck with a permanent red x on their PRs - do you know if there's a way to force the action to report errors without failing out itself?

[cmitzel-ncino]

example of relatively simple workflow I slapped together.

[wagoid]

@cmitzel-ncino glad it works! Unfortunately there's no way to force that at this point, but I can add a parameter like failOnErrors: false (default to true).
I'm not sure when I'll be able to do that, but if you're interested in creating a PR I'd be happy to review it!

[cmitzel-ncino]

That's awesome! I can look into implementing that. Thank you so much for your help!

[cmitzel-ncino]

I opened a PR here to start chipping away at properly implementing this :D #711

[wagoid]

Implemented in #711 by @cmitzel-ncino, closing the issue 💪

[mavenjones]

@cmitzel-ncino We are looking to do the same thing...
Any chance you can post the code for the 2nd pass_or_fail job that programmatically checks if any of the commits are valid?