chore: add lint-pr action

[ryanchristo]

Description

This pull request adds the configuration for a "Lint PR" action (see action-semantic-pull-request) that ensures each pull request title follows the Conventional Commits specification.

This update will require future pull request titles to be prefixed with one of the default types before the pull request can be merged. There is no requirement for scope at this time.

ref #9268

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (see CONTRIBUTING.md)
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Code follows the module structure standards. - n/a
• Wrote unit and integration tests - n/a
• Updated relevant documentation (docs/) or specification (x/<module>/spec/) - n/a
• Added relevant godoc comments. - n/a
• Added a relevant changelog entry to the Unreleased section in CHANGELOG.md - n/a
• Re-reviewed Files changed in the Github PR explorer
• Review Codecov Report in the comment section below once CI passes

[ryanchristo]

cc @aaronc @alexanderbez @marbar3778

Any initial thoughts? Is this something we should discuss on one of our community calls first? Also, I can remove the commented out configuration options but I left them here initially for visibility.

[tac0turtle]

I'm a bit lost on what types and scope actually mean here? Is there an example of how the PR would look with this?

[ryanchristo]

I'm a bit lost on what types and scope actually mean here? Is there an example of how the PR would look with this?

The type is what type of change is being made (i.e. feat, fix, refactor, chore, etc.). The scope is to further specify the topic of the change (e.g. what package the changes touch). Here is an example from Conventional Commits:

feat(parser): add ability to parse arrays

The general idea is to improve how we track changes and to further encourage atomic pull requests. Here is a snippet from the Conventional Commits specification:

It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages.

[tac0turtle]

oh okay, Thanks for the explanation. I think it makes sense to be this strict.

[alexanderbez]

I'm certainly in favor of something like this, but two initial questions:

1. What does it matter since all commits are squashed anyway and only the final commit matters?
2. How will this play with Go's convention re commit messages that specifics the prefix should be the package and not a type?

[ryanchristo]

What does it matter since all commits are squashed anyway and only the final commit matters?

From the action-semantic-pull-request description, "This is a Github Action that ensures that your PR title matches the Conventional Commits spec." This action is not concerned with individual commits, it only checks the PR title, which will become the commit when all the commits have been squashed and merged.

How will this play with Go's convention re commit messages that specifics the prefix should be the package and not a type?

The Go convention proposes to prefix the first line of the commit with the package name. Conventional Commits proposes to use the type of change and a scope (which could be the package name). Conventional Commits is more specific and extends beyond the Go community, but you are right, these two conventions are not aligned and we should decide on one or the other.

One of the advantages of using Conventional Commits is that it works with tools like semantic-release. At Regen Network, we have been discussing ways to improve upon the release process and this convention for commits was one suggestion. Also, another example of this convention in use is the dependabot pull requests.

[robert-zaremba]

The idea is good.

I have one concern: Will this work with our auto-squashing / automerge functionality?

[aaronc]

The idea is good.

I have one concern: Will this work with our auto-squashing / automerge functionality?

Yes as long as the check passes. We are already using it in regen-ledger

[aaronc]

I just want to clarify one goal I have related to this is the idea that we have QA checklists for PR reviewers that are related to the type of PR. So a docs PR would have a different QA checklist than a feature PR.

Now, conventional commits is not the only way to achieve this. But, it is a somewhat widely used standard and focuses the PR on one and only one type of change (docs, feature, fix, etc.) which is generally good. We could alternatively use Type: labels but it's harder to enforce one label per PR.

Regarding PR scope, which could be indicated with the golang convention (ex. math: ...) or conventional commits (ex. feat(parser): ...), I think it's harder to limit PR's to a single package/module than a single type of change. In particular, "refactor" PRs generally span many if not all modules. Also, we have C: (for component) labels to indicate PR scope pretty well and we have the automatic labeler action to tag PRs. To generally be able to limit PRs to a single package, we would probably need to split the SDK into many separate go modules which is not a bad idea IMHO but beyond the scope of what we're trying to do here.

So, basically I support these conventional commit prefix tags (feat:, fix:, etc.) as a good way to focus PRs on one type of change and have QA checklists accordingly. I prefer not including scope (ex. feat(parser):) for now and just using labels for that, but I'd be open to it later if we refactor the SDK enough to make it easy to limit PRs to one type of change + one component.

[ryanchristo]

I've update the configuration to use the default configuration. See configuration for additional configuration options.

[ryanchristo]

Also, updated pull request summary and added link to default types for reference.

[blushi]

LGTM
Just an internal note: it would be good to set this up too on regen-ledger

[Jsn2win]

pr lint