- Notifications
You must be signed in to change notification settings - Fork261
Description
Question
I have a pipeline that builds container images where the code doesn't change often. The images built are tagged with the version derived from python-semantic-release. I would like to ensure that the third digit is always incremented whenever python-semantic-release is called (which it is during the build pipeline).
There is a lack of documentation around what I believe is the relevant configuration option, 'default_bump_level'. It takes an integer but there isn't a description on what the values correlate to. I was testing with default_bump_level = 3 and saw it increment the second digit. Setting it to 2 seemed to increment the patch version. Thinking I had the problem solved I merged it into my pipeline, ran a manual pipeline and it didn't bump the version at all.
I'm guessing maybe the next issue is that I need to wildcard my allowed_tags, but that is just a guess. Would love any help or examples if someone else has any ideas.
Configuration
Semantic Release Configuration
[tool.semantic_release]allow_zero_version =falsetag_format ="v{version}"assets = []build_command_env = []commit_message ="Semantic Release - Tag {version}\n\nAutomatically generated by python-semantic-release"commit_parser ="conventional"logging_use_named_masks =falsemajor_on_zero =trueno_git_verify =false[tool.semantic_release.branches.main]match ="(main|master)"prerelease =false[tool.semantic_release.branches."*"]match ="*"prerelease_token ="rc"prerelease =true[tool.semantic_release.changelog]exclude_commit_patterns = []mode ="init"insertion_flag ="<!-- version list -->"template_dir ="templates"[tool.semantic_release.changelog.default_templates]changelog_file ="CHANGELOG.md"output_format ="md"mask_initial_release =false[tool.semantic_release.commit_author]env ="SEMANTIC_RELEASE_AUTHOR"default ="semantic-release <semantic-release>"[tool.semantic_release.commit_parser_options]minor_tags = ["feat"]patch_tags = ["fix","perf"]other_allowed_tags = ["build","chore","ci","docs","style","refactor","test"]allowed_tags = ["feat","fix","perf","build","chore","ci","docs","style","refactor","test"]default_bump_level =2parse_squash_commits =trueignore_merge_commits =false[tool.semantic_release.remote]name ="origin"type ="gitlab"# Will look for env GITLAB_TOKEN when type = gitlab# A Project Access Token should exist with permission to push/tag/releaseignore_token_for_push =falseinsecure =false[tool.semantic_release.publish]dist_glob_patterns = ["dist/*"]upload_to_vcs_release =false
Additional context
My pipeline runs a prepare job that runs semantic-release version to store it as an environmental variable for the later stages to use. This is the output for a manual pipeline run that I expected it to bump from 1.7.0 to 1.7.1.
Created fresh repository.Checking out 28181a35 as detached HEAD (ref is main)...Skipping Git submodules setupExecuting"step_script" stage of the job script 00:01$ git config --global --add safe.directory"$CI_PROJECT_DIR"$ git checkout -b"$CI_COMMIT_REF_NAME"Switched to a new branch'main'$ git statusOn branch mainnothing to commit, working tree clean$echo"NEXT_VERSION =$(semantic-release version --print-tag)">> next_version.envNo release will be made, 1.7.0 has already been released!$ cat next_version.envNEXT_VERSION = v1.7.0Uploading artifactsfor successful job 00:01Uploading artifacts...next_version.env: found 1 matching artifact files and directories Uploading artifacts as"dotenv" to coordinator... 201 Created Cleaning up project directory and file based variables 00:00Job succeeded
I have not included the git log because the intent is to always bump, regardless of what the git log shows.