release commits and distribution branches config issues

[boy51]

Hi,

thanks for this plugin, works well for me so far.

However, I cannot figure out a decent flow that doesn't come with awkward side effects. My issues are mainly due to the fact that this plugin creates commits for releases.

This is the (simplified) workflow my team used with semantic release:

• I have qa as the main (default) branch, and production. These are my distribution branches.
• Developers make changes on their own (feature) branch named along the lines of feat/xy
  • MR pipeline runs tests etc
• When done, merge into qa
  • QA pipeline starts in this order: test -> build -> version -> deploy
  • Note: with SR, I could create the tag in version job and it would be immediately available for next deploy job
• When ready, merge qa into production
  • production pipeline looks the same; the version job running SR sees that there already is a tag for the current changes and doesn't create a new version

This was working great before, but now the release commits are creating issues for me.

• For now I set [skip ci] on the commit message. As a result, anytime I merge and want to deploy it will create commits with skipped pipelines, which means the pipeline status for the project is always skipped.
• When I merge qa into production the last commits will skip ci. As a result, the MR pipeline is skipped.
• When deploying, the tag is created on the release commit. This means the tag won't be available for the same pipeline that is running the version job.

Can someone suggest a better flow for me? I can think of some solutions such as running the version job before merging. But I can't wrap my head around a fully working flow.

Will be forever grateful for any help!

[boy51]

Reading on GitLab flow a good idea would probably to have a main branch between my feature branches and staging (or qa in my case) environments, and run deploys only after changes are moved out of main. Still interested to hear some thoughts on this

[edbzn]

I'm sorry but I have no good recommendation regarding any Git workflow because it depends on the project and the team. There's no ultimate Git branching strategy. My own (limited) experience here is that I avoid too complex workflows like the Git Flow and I like more simple workflows as the GitHub Flow. GitLab Flow is between these two but I never used it.

However, I think your problem does not come from the Git branching model, but from the way you are skipping CI pipelines. Are you using GitLab or GitHub? With GitHub you don't need to put the [skip ci] in the commit message, pushing a commit within a CI job (using the semver --push option) should not trigger another job in cascade.

1. merge your feature branch into qa (which is your base branch I guess)
2. version with --push and no [skip ci] message
3. merge qa into production (here the latest version tag is available and the CI should be triggered)

Note that I always recommend versioning directly on the base branch.

Let me know if it helps.

[boy51]

Hi thanks for the reply, I agree with you on avoiding complex flows. I like gitlab flow though, its not really complex under the hood just more formal in some regards.

I am on gitlab and --push does trigger new pipelines. I ended up making a main branch to merge PRs into, on which version jobs are run. I did remove [skip ci], which means pipeline does re-run for version commits but since there are no new changes thats ok. I then merge from main into distribution branches.

This is working fine atm. If there was an option to go without commits I would prefer that. The reason I'm using this library is for automating tags and gitlab releases. I think semantic release's bundling solution (write version to package.json just before building) was really good. If you are thinking about implementing something like that I'd be open to contribute.

[nkalinov]

Do you have prerelease versions (maybe from qa branch?) and how do you manage those?