Skip to content

bug: default_level_bump no longer working as expected #1293

@jeffcpullen

Description

@jeffcpullen

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 = false
tag_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 = false
major_on_zero = true
no_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 = 2
parse_squash_commits = true
ignore_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/release
ignore_token_for_push = false
insecure = 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 setup
Executing "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 status
On branch main
nothing to commit, working tree clean
$ echo "NEXT_VERSION = $(semantic-release version --print-tag)" >> next_version.env
No release will be made, 1.7.0 has already been released!
$ cat next_version.env
NEXT_VERSION = v1.7.0
Uploading artifacts for successful job 00:01
Uploading 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:00
Job succeeded

I have not included the git log because the intent is to always bump, regardless of what the git log shows.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working properlyconfirmedPrevent from becoming stale

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions