feat(ci): automatically generate release notes and build dist only on release

[okineadev]

It is better to build dist and format files only before release in order not to spam with commits and unnecessary changes

I also added automatic generation of release notes with changelogen, when the Release Workflow starts it will automatically write the release notes, commit all the changes, run them and create a new release with a new version according to the changes made thanks to Conventional Commits

[xhyrom]

By building dist only before release, it's not possible to use commit hash to pin the setup-bun version. Did you consider that?

[okineadev]

By building dist only before release, it's not possible to use commit hash to pin the setup-bun version. Did you consider that?

How so?

changelogen makes the commit chore: release 1.2.3, this is the commit that can be attached

[okineadev]

By building dist only before release, it's not possible to use commit hash to pin the setup-bun version. Did you consider that?

It will be possible to attach only the release version and not the version of any commit

[okineadev]

I very much doubt that there are people who attach the hash of a particular commit and not the commit of the new version

But if necessary, I can undo this change

[okineadev]

@xhyrom So should I make dist generated after each commit?

[xhyrom]

I very much doubt that there are people who attach the hash of a particular commit and not the commit of the new version

They exist; in fact, even github recommends it - https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#:~:text=Pin%20actions%20to%20a%20full%20length%20commit%20SHA

@xhyrom So should I make dist generated after each commit?

That's already done by autofix.ci

[okineadev]

They exist; in fact, even github recommends it - docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#:~:text=Pin actions to a full length commit SHA

I know, but I'm talking about completely different

That's already done by autofix.ci

I will then rewrite it so that it commits on behalf of the bot, and I will remove the formatting and build step from the release workflow

[xhyrom]

They exist; in fact, even github recommends it - docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#:~:text=Pin actions to a full length commit SHA

I know, but I'm talking about completely different

Can you tell me what are you talking about? I thought we had discussion about using commit sha as action version.

[okineadev]

They exist; in fact, even github recommends it - docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#:~:text=Pin actions to a full length commit SHA

I know, but I'm talking about completely different

Can you tell me what are you talking about? I thought we had discussion about using commit sha as action version.

I and everyone else pin the hash of the commit to GitHub Actions (or rather Renovate does this)

For example some-cool/action@67rf323rn79an67r208703 # 1.2.3

As you can see, the comment on the right shows the version of action that is used here, and therefore the hash of the commit, this is the commit on which the release was created

If I need to attach to some other commit, I will change its hash

But I have not yet seen such cases where it is necessary to attach to a specific commit other than the release commit

[okineadev]

@xhyrom I already updated the autofix.ci workflow and now it will commit on behalf of the bot