GitHub Actions would be better than this GitHub App

[zeke]

This thing is currently a GitHub App, but it might better serve the community if it was rewritten as a GitHub Action. This would allow more flexibility:

• The configuration would live right inside the workflow file
• I wouldn't have to host the app any more.
• The on trigger in the workflow file could be configured to only run the action when certain files are changed (useful for monorepos, see https://github.com/zeke/semantic-pull-requests/issues/89)
• People could fork the action and customize it to suit their needs. This is not easy with GitHub Apps.

[zeke]

I did a little research on this today and discovered that a very similar action already exists!

https://github.com/amannn/action-semantic-pull-request

@amannn and @hanno-jonlay I see you've contributed to that project. Would you be okay with me updating the REAMDE of this project to mention your Action as an alternative?

[zeke]

Side note: I see this in the README

Note that since PR titles only have a single line, you have to use the ! syntax for breaking changes.

Does semantic-release already support that as an alternative to BREAKING CHANGE: in the commit body? If so, that's very exciting news.

[hanno-jonlay]

Not sure I can say much here, since my contribution was amusingly tiny: https://github.com/amannn/action-semantic-pull-request/commit/08fc3f6958d1eb25364744327885b8b8b6cc3e34

Fun to hear you mention this, however, as I spent a bit of time considering your app before we eventually settled on @amannn's action instead. So I think that for other newbies, a comment in the README would have been useful.

[amannn]

Would you be okay with me updating the REAMDE of this project to mention your Action as an alternative?

Of course! 🙂

Does semantic-release already support that as an alternative to BREAKING CHANGE: in the commit body? If so, that's very exciting news.

Yep, it does! While I was working on the action I've found that commit-analyzer didn't support this back then, but that was quickly resolved then! I never had any issues so far.

[Vlaaaaaaad]

I was unhappy with the pre-existing GitHub Actions( weird emoji support) and I looked a bit into this. I ended up just using an if on the PR title. It's not pretty, but it works.

As it'll be a while until I open-source the project using these actions, here's the relevant code:

name: Conformance

on:
  pull_request:
    types: [opened, synchronize, edited]

...

steps:
  - name: PR title is valid
    if: >
      startsWith(github.event.pull_request.title, '📦 ') ||
      startsWith(github.event.pull_request.title, '🐛 ') ||
      startsWith(github.event.pull_request.title, '👌 ') ||
      startsWith(github.event.pull_request.title, '🚀 ') ||
      startsWith(github.event.pull_request.title, '‼️ ') ||
      startsWith(github.event.pull_request.title, '⬆️ ')
    run: |
      echo 'Title checks passed'

  - name: PR title is invalid
    if: >
      !startsWith(github.event.pull_request.title, '📦 ') &&
      !startsWith(github.event.pull_request.title, '🐛 ') &&
      !startsWith(github.event.pull_request.title, '👌 ') &&
      !startsWith(github.event.pull_request.title, '🚀 ') &&
      !startsWith(github.event.pull_request.title, '‼️ ') &&
      !startsWith(github.event.pull_request.title, '⬆️ ')
    run: |
      echo 'Pull request title is not valid. See .github/PULL_REQUEST_TEMPLATE/pull_request_template.md for details'
      exit 1

At one point I was even commenting back on the PR for more visibility, but I thought that was a bit much:

- name: Comment for PR title conformance
  if: failure()
  uses: peter-evans/create-or-update-comment@v1
  with:
    issue-number: ${{tojson(github.event.number)}}
    body: |
      Please ensure your PR title starts with an icon:
        📦 New things / new features / new docs
        🐛 Fix existing thing / bug fixes
        👌 Improve something / refactor
        🚀 Release / ship / deploy
        ‼️ Breaking changes / user involvement requires / manual delivery steps
        ⬆️ Dependency updates / tooling bumps

      PR titles should be, in order of importance:
        - imperative( _add_ instead of _added_)
        - explicit
        - short

      Examples of PR titles:
        📦 Add yaml support
        📦 Add Firefox browser tests
        📦 Tutorial for API Interface
        📦 ADR: Use Terraform for IaC
        📦 Add automated CHANGELOG
        🐛 Fix conversion failure for Italian
        🐛 Stop panic on baldy formatted input
        👌 Improve handling of JPEG files
        👌 Link to PRs in CHANGELOG
        👌 Refactor event routing
        ‼️ Change API response codes
        ⬆️ Bump json from v5 to v6

[mrchief]

FWIW, an app works out much better for multiple projects. It's faster than GH actions, doesn't eat up actions runtime quota, easier to configure and so on. There's more you can do with GH actions but doing so again and again across projects becomes tedious after a while.