release based on semantic-release reasonably

[msclock]

Recentlly I consider some small steps(such as #608) as parts of a big impact to codebase should make as beta/alpha releases or just skip it without making a release. So there are two ways:

• open beta/alpha release channel with semantic-release.
• make semantic-release run manually only.

Any ideas? @huxuan

[huxuan]

I created issue #609 for almost the same concern. I suppose to use release scope as a whitelist, just like no-release as a blacklist. In this way, semantic-release will ONLY consider releasing a new version when a release scope is specified.

[msclock]

use release scope as a whitelist, just like no-release as a blacklist

This will result in the commit message with the release scope presents in the release log and it makes a release commit message more strict.🤔

[huxuan]

This will result in the commit message with the release scope presents in the release log and making a release commit message more strict.🤔

release scope is just another alternative choice than manual trigger. We can also leverage something like github labels as pipx use.

[msclock]

leverage something like github labels

It definitely is an alternative but requires a pr labeled for release purpose. Accounting for this, I consider manual release is more feasible.

[huxuan]

Yep, these are all kinds of trade-off. There must be some marker or trigger (including manually). I am OK to have a manually triggerred workflow.

BTW, one thing I may not mention explicitly. I did not prefer pre-releaes channel of semantic-release because I have not find a solution the make the auto generated version to be compatibile with PEP440.

[msclock]

Agree. It(semantic-release/semantic-release#1611) had stucked.

How about combining those two ways. Allow to trigger manual and labeled automatic release workflows.

[huxuan]

Allow to trigger manual and labeled automatic release workflows.

Actually, the label is kind of GitHub specific, AFAIK, there is no similar approach for GitLab. Maybe just have a manually triggered workflow as the first step?

I suppose to move the semantic-release job to release workflow as make the whole workflow manually triggered.

[msclock]

the label is kind of GitHub specific

GitLab has relavant CI variable CI_MERGE_REQUEST_LABELS. I haven't use it before but it should work as expected.

[huxuan]

GitLab has relavant CI variable CI_MERGE_REQUEST_LABELS. I haven't use it before but it should work as expected.

Seems the variable is only available in merge request pipeline (example) while for our cases, it should be a branch pipeline (example).

I will try a test on the merge results pipelines. It is a premium feature :-(

[msclock]

After digging, I have verified the variable presents in mr pipelines see https://gitlab.com/msclock/gitlab-ci-templates/-/jobs/6167716755#L2326.
For merge request pipeline, CI_MERGE_REQUEST_LABELS is available in a free tier and suitable to configure the automatic release jobs.
For branch pipeline, it seems manual release is the only option.

[huxuan]

For merge request pipeline, CI_MERGE_REQUEST_LABELS is available in a free tier and suitable to configure the automatic release jobs.

IIUC, merge request pipeline is triggered by a merge request before merged. I do not think it is suitable for release. Let me know if I missed anything.

[msclock]

🤣Got it. Then there is only the manual option left.

[huxuan]

🤣Got it. Then there is only the manual option left.

It is simple and enough. :-)

[huxuan]

Just a note, with the manual trigger configuration, maybe we should remove the "no-release" blacklist, since it may forbidden a new release forever. Anyway, I did not test it, just a note here.

[huxuan]

Moreover, since we have the no-release scope as blacklist, maybe it is OK to keep everything as it is now? When we do not want to make a new version, add a no-release scope should be fine. If possible I would like to avoid manual trigger, since it tends to mean no release.

[msclock]

since we have the no-release scope as blacklist, maybe it is OK to keep everything as it is now?

I'Ok with it, and it will work as we expected to skip a release action. @huxuan

[msclock]

If we keep the no-release scope solution, then I would close this. But actually what I expect is to seperate the experimental/WIP and stable changes on codebase.

[huxuan]

We should both agree on no release with experimental changes, so I suspect the difference is whether the changes should be pushed to main branch?

[msclock]

whether the changes should be pushed to main branch

Yes, that's the reason I recommend the different release channels based on semantic-release. But keep it simple is also a good choice. Now, no-release scope is good enough to ensure the current codebase is mantainable.

[huxuan]

that's the reason I recommend the different release channels based on semantic-release.

This seems to be a long-standing debate in Git Workflow. The main branch can mean a "stable" or "unstable" branch. In the Python community, it seems that most projects adopt the "unstable" pattern, but take the version release more serious. That is why I want to introduce a whitelist scope rather than blacklist scope. A manuel approach is also acceptable, it is more like a trade-off actually.

It seems to be a different pattern between the Node community and the Python community. Frequent release needs extra release channels. When we take the release more seiously it should be OK to have the main branch unstable, especially when we are still in the alpha stage.