@simoneb

This should avoid the unintentional commit of the dist.

@simoneb
I added now an integrity check for the dist file.

As you can see the workflows for the commit 1a0ff43 failed because the dist file was not what we would expect. In e9fcfec the integrity check passes.

Apologies but I don't see the value in this solution. I like the simplicity of building the action automatically when committing, so that dist is always aligned with the source code.

The only downside to this approach is that sometimes dist is changed in PRs that are not changing the source code, and the most likely reason is that some packages got updated in the PR author's branch. I don't find this a major issue since the dist will nonetheless be recreated when we release the action by the very same process.

@simoneb

I understand. I use this type of logic in the actions at my employer. See e.g.
https://github.com/metro-digital/setup-tools-for-waas

So it results in two things:

1. If a contributor pushes changes, and also changes the dist files, we can trust the modified dist. When @groozin was pushing we asked him to revert that file. But with the integrity check, we could have accepted it without worrying.

2. When we get some PR by dependabot, which does change the dist file, it gets detected and automerge is prevented. We can run build.yml workflow on that dependabot branch and a correct dist is generated. We must then only squash merge manually. Benefit of this is, that we can actually see, if there was relevant changed and make a release. So e.g. if dependabot updates eslint, it will be merged silently. But if it changes @actions/core we see that a PR got not merged automatically and we can see that it effected the dist file. So we should consider a new release.

3. Also we could rebuild the dist by running build.yml targetting main.