Repository navigation
feat: support providing regexps for types - #292
Conversation
The primary use case for this action is to match PR titles against the Conventional Commits spec. I think I'd prefer to stick to their defaults to avoid surprises.
I think API-wise this might be a bit tough to get in. We already have a config option to use entirely different types, so this would likely mean another config option, which can essentially be used for the same thing. Sorry, I think also here I'd prefer to keep the action a bit more minimalistic! Sorry for pushing back a bit here, I hope this makes sense! |
|
🎉 This PR is included in version 6.1.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Since v6.1.0 each line of the `types` input is treated as a regex pattern auto-wrapped in `^ $` (amannn/action-semantic-pull-request#292), so the trailing "# comment" became part of the pattern: the line "bugfix # bug fixes" means regex ^bugfix # bug fixes$, which can never match the type token in a PR title. Every PR has failed the "Lint PR" check since the bump in db281a3. Under @v4 the input was split on whitespace into plain strings, so "bugfix # bug fixes" accidentally yielded the bare token "bugfix", which matched. That accidental tolerance is gone in v6. Fix: list each type as one bare line on the strip block scalar (`|-`), as the v6 docs describe and as other repos pinning the same v6.1.1 SHA do: https://github.com/projen/projen/blob/main/.github/workflows/pull-request-lint.yml#L23-L30
Since v6.1.0 each line of the `types` input is treated as a regex pattern auto-wrapped in `^ $` (amannn/action-semantic-pull-request#292), so the trailing "# comment" became part of the pattern: the line "bugfix # bug fixes" means regex ^bugfix # bug fixes$, which can never match the type token in a PR title. Every PR has failed the "Lint PR" check since the bump in ff17f2b. Under @v4 the input was split on whitespace into plain strings, so "bugfix # bug fixes" accidentally yielded the bare token "bugfix", which matched. That accidental tolerance is gone in v6. Fix: list each type as one bare line on the strip block scalar (`|-`), as the v6 docs describe and as other repos pinning the same v6.1.1 SHA do: https://github.com/projen/projen/blob/main/.github/workflows/pull-request-lint.yml#L23-L30
Since v6.1.0 each line of the `types` input is treated as a regex pattern auto-wrapped in `^ $` (amannn/action-semantic-pull-request#292), so the trailing "# comment" became part of the pattern: the line "bugfix # bug fixes" means regex ^bugfix # bug fixes$, which can never match the type token in a PR title. Every PR has failed the "Lint PR" check since the bump in db281a3. Under @v4 the input was split on whitespace into plain strings, so "bugfix # bug fixes" accidentally yielded the bare token "bugfix", which matched. That accidental tolerance is gone in v6. Fix: list each type as one bare line on the strip block scalar (`|-`), as the v6 docs describe and as other repos pinning the same v6.1.1 SHA do: https://github.com/projen/projen/blob/main/.github/workflows/pull-request-lint.yml#L23-L30
Since v6.1.0 each line of the `types` input is treated as a regex pattern auto-wrapped in `^ $` (amannn/action-semantic-pull-request#292), so the trailing "# comment" became part of the pattern: the line "bugfix # bug fixes" means regex ^bugfix # bug fixes$, which can never match the type token in a PR title. Every PR has failed the "Lint PR" check since the bump in ff17f2b. Under @v4 the input was split on whitespace into plain strings, so "bugfix # bug fixes" accidentally yielded the bare token "bugfix", which matched. That accidental tolerance is gone in v6. Fix: list each type as one bare line on the strip block scalar (`|-`), as the v6 docs describe and as other repos pinning the same v6.1.1 SHA do: https://github.com/projen/projen/blob/main/.github/workflows/pull-request-lint.yml#L23-L30
Similar to #226, this adds support for providing regexs for types which makes it possible to e.g. have Jira keys as a type.
This was about as straightforward as I expected though it turns out the conventional commit header pattern does not allow
-characters meaning that also needs to be changed for Jira keys - it would be great if that was handled by the action either by just changing the default pattern entirely or by changing it when a custom type (or maybe even a "probably a regexp" type?) is detected, but either way that's out of scope for this particular change (let me know if you'd be open to it though).Also something else this would be useful with is the ability to add additional types, rather than having the default list overridden - I'm happy to create a follow up issue and PR if that sounds useful.
Resolves #220
E2E tests: