semantic-release

[genofire]

I believe it is more useful to create another plugin for semantic-release: https://semantic-release.gitbook.io/semantic-release/

like gitlab: https://github.com/semantic-release/gitlab

[anbraten]

@genofire I use semantic-release for other projects and somehow like it. Its nice in general and works great for a specific setup, but it requires quite some things like conventional-commits, doesn't support monorepo tools to well, merging is more or less directly triggering a release, ...

I really like the idea of shipjs for projects like woodpecker-ci itself. This way it would create and update a release PR for each push to master / main and a maintainer could release a new version just by merging the "release PR" which is a pretty similar workflow to how we do it manually at the moment for woodpecker.

I tested the current pretty simple code with a test repo already: https://github.com/anbraten/test-ready-release-go/pull/5 & https://ci.woodpecker-ci.org/anbraten/test-ready-release-go which seems to work pretty well in general.

[anbraten]

@6543 FYI

[6543]

I like the idea to automate it ...

could you describe the new forkflow?

old =

1. exec changelog tool and alter changelog.md
2. tag with changelog (only added section) as message
3. let bot create release and artifacts
4. alter release to look nice

[genofire]

push in default branch, based on conventinal commits , automatical create an Tag (and update changelog.md) and created on gitlab/github an release with changelog. (It depends on config of semantic-releases)

all commit messages of the push / merge are analyzied. So the version would just increment once based of the highes impact (if there any commit with breakchange/! would create an new major release, together with all new feature and fixes).

prereleases are also possible of an release candidate branch.

---

so just commit with the correct message (and push/merge will do the Rest).

[anbraten]

could you describe the new forkflow?

Each time someone pushes to main / master a pipeline containing the ready-release-go plugin is executed. The plugin loads a config from the repo. This config script tells it how to determine the next version could be conventional commit, just tag / release based etc, after that it executes another script doing the release update (in my example it downloads and executed our changelog tool) and in the end it commits all changes to a branch and creates a pull-request. This pull-request contains all changed files like the Changelog.md etc. If we want to release a new version we just merge that PR and after merge the plugin detects the "release" pull-request and creates the corresponding tag and release for it. Its basically doing the same thing we currently do manually, but what I really like is that we always have a prepared changelog etc ready to merge.