I agree with a lot of the post.

Shameless plug, I suggest a workflow very similar with my own github action, https://github.com/rubenfiszel/autochangelog-action. The suggested workflow is to:

  - trigger the action through CURL
  - the action generates a changelog diff and some 
    manifest file diff with the version change (such as package.json). 
    The next version is inferred using semantic versioning and 
    conventionnal commits, respecting fix, feat and breaks. 
    With that new content, you generate a PR. 
    That PR is labeled with "autorelease"
  - When that PR is merged, another action is triggered wich do the 
    Github Release and fill the body with the changelog diff

Shameless plug on top of your plug.

I'm one of the people building:

https://www.actionspanel.app/

A GitHub App that lets you trigger your Actions without needing to run cURL

Small world. I found your appp and really wanted to try it. Unfortunately, when I sign in, I get redirected to the sign-in page (https://www.actionspanel.app/auth/sign-in?next=/app) in an endless cycle.

Do you know what could be the issue?

Great post. Very clear explanation of things.

The semantic release tooling is so good, I've started using it on non-js projects. I'm using it to manage Terraform modules, base docker images, etc. Once you're doing that, might as well mix in Husky and commit-lint to manage your git hooks and commit messages too.

There are comparable things elsewhere, but node is so ubiquitous in my tool chain already that this is the path of least resistance for me. And it works great!

I wanted to also introduce PR title validation, so there is no mistake possible on merging and we follow convetional commits 100% but unfortunately GitHub Actions do not support fork-based workflow properly and those PR checks would be useless :(

Oh, that is unfortunate. Hopefully they fix that. For now, it might be worth writing a little bot that will flag PRs with noncompliant commit messages and titles.

> GitHub Actions do not support fork-based workflow properly

Could you elaborate on this?

Take a look on my blog post about it https://dev.to/derberg/github-actions-when-fascination-turns.... I already reported this to GitHub Actions team and seems they are working on that. For reference https://github.community/t5/GitHub-Actions/GitHub-Action-wor...

Ah yes, fork. My mind read that as branch as we barely ever use forks (enterprise environment and all)

Issue comment-triggered Actions have a write-access GITHUB_TOKEN, unless I’m mistaken. You could implement the /ok-to-test flow with that.

(I’m working on converting some of VSCode’s triage automation to Actions, for reference)

Guy from GitHub suggested the same, but how would you really see such workflow in action? all I have in mind seems so complicated that easier would be to write and host dedicated bot really. Supporting PR on Issue level sounds strange

I was wondering how do you use semantic-release tooling in non-js. Do you use ".releaserc" file for config and then on CI execute with npx, to have pure repo with no JS thingy? Or are you just using package.json normally? maybe hidden in ".github" ?

I just use a package.json in the repo root as it doesn't really bother me. It very rarely changes so I pretty much forget its there.

This is awesome! It's a pity that Github Actions don't work well with PRs coming from forks. We could do many more things.