Issue with location of CHANGELOG.md

[dornech]

Bug Report

Description

I use python-semantic-release with a generated config via pyproject.toml.
In a test package directory I execute
semantic-release -vv --noop version --print

Expected behavior

Output of a successful noop run.

Actual behavior

[15:57:31] DEBUG    [main.main] logging level set to: DEBUG                                                                                                                          main.py:124
🛡  You are running in no-operation mode, because the '--noop' flag was supplied
           DEBUG    [main.main] global cli options: GlobalCommandLineOptions(noop=True, verbosity=2, config_file='pyproject.toml', strict=False)                                     main.py:139
           INFO     [util.load_raw_config_file] Loading configuration from pyproject.toml                                                                                             util.py:79
           DEBUG    [util.load_raw_config_file] Trying to parse configuration pyproject.toml in TOML format                                                                           util.py:82
           INFO     [config.select_branch_options] Using group 'main' options, as '(main|master)' matches 'main'                                                                   config.py:545
           DEBUG    [config.from_raw_config] hvcs token is not set                                                                                                                 config.py:697
           WARNING  [config.from_raw_config] Token value is missing!                                                                                                               config.py:700
Changelog file destination must be inside of the repository directory.

As you can see, there is a problem with the location of the changelog file I am not able to fix.

Environment

• Operating System (w/ version): Windows 10
• Python version: WinPython 3.11.4
• Semantic-release version: 9.15.1
• Build tool (w/ version): hatch

Configuration

assets = []
build_command = "pip install hatch && hatch build"
build_command_env = []
commit_message = "{version}\n\nAutomatically generated by python-semantic-release"
commit_parser = "angular"
logging_use_named_masks = false
major_on_zero = true
allow_zero_version = true
no_git_verify = false
tag_format = "v{version}"
version_variable = []
version_toml = []
version_pattern = []

[tool.semantic_release.branches.main]
match = "(main|master)"
prerelease = false
prerelease_token = "rc"

[tool.semantic_release.changelog]
exclude_commit_patterns = []
mode = "init"
insertion_flag = "<!-- version list -->"
template_dir = "."

[tool.semantic_release.changelog.default_templates]
changelog_file = "CHANGELOG.md"
output_format = "md"
mask_initial_release = true

[tool.semantic_release.changelog.environment]
block_start_string = "{%"
block_end_string = "%}"
variable_start_string = "{{"
variable_end_string = "}}"
comment_start_string = "{#"
comment_end_string = "#}"
trim_blocks = false
lstrip_blocks = false
newline_sequence = "\n"
keep_trailing_newline = false
extensions = []
autoescape = false

[tool.semantic_release.commit_author]
env = "GIT_COMMIT_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 = 0

[tool.semantic_release.remote]
name = "origin"
type = "github"
token = { env = "GH_TOKEN" }
ignore_token_for_push = false
insecure = false

[tool.semantic_release.publish]
dist_glob_patterns = ["dist/*"]
upload_to_vcs_release = true

[codejedi365]

@dornech, thank you for the write up. I don't test this commonly enough especially with Windows. There is always something weird that happens with these path resolutions on Windows (#994) and clearly I missed something here. Hopefully I can resolve quickly.

[codejedi365]

Migrated @dornech's comment from other issue:

So, I had some trouble debugging the issue but I think I found the root cause. Basically it has to do with an issue that occurs occasionally: shared file handling in Windows. to explain: I use a virtual machine for my programs but have data including Python repositories on shared drives. This leads to different file representations for the same file/directories.

The problem is in config.py line 724:

        # Prevent path traversal attacks
        if raw.repo_dir not in changelog_file.parents:
            raise InvalidConfiguration(
                "Changelog file destination must be inside of the repository directory."
            )

My anonymized values are:
raw.repo_dir: WindowsPath(':/WinPython/WPy_Projekte/pytestdornech')
changelog_file.parents
.drv = "\\\_FullAccess",
._parts[0]."\\\_FullAccess",
._parts[1]="WinPython",
._parts[2] ...

This means while repo_dir uses the drive letter, the evaluation of the changelog_file parents use the share descriptor.
While being equivalent, it is not recognized as being the same

[codejedi365]

@dornech, if you make the following change, does it work?

diff a/src/semantic_release/cli/config.py b/src/semantic_release/cli/config.py
370

              logging.warning(
                  "Found .git/ in higher parent directory rather than provided in configuration."
              )
-         return found_path
+         return found_path.resolve()

      @field_validator("commit_parser", mode="after")
      @classmethod

[dornech]

Thanks for shifting the comment and sorry for the mess ...
And thanks for the hint to #994 - did not find it.

I think the hint with .resolve() is the solution.
It works when I do debugging with CliRunner but not from the command line but I think it is the solution anyway.

[codejedi365]

@dornech, thanks for the reply. Hopefully it is. I will add a better test and see if it works or fails in the CI windows job.

Is there anything unusual about your Windows machine setup? Like is it a roaming profile with a network mounted home folder?

[dornech]

Well, I do not think my Windows setup is toooo unusual but probably a little bit different. Years ago I had the idea to easen backup issues of my system f. e. for change of hardware by using virtualbox on a more or less plain host but an "operative" Windows installation in a VirtualBox VM. However, data files reside on the host as "normal" drives and are mapped into the VM. I learned this has some draw-backs and these drives behave a little bit different especially when it comes to access files via Windwos drive letters or via UNC-paths.

[codejedi365]

@dornech, makes sense from that perspective. I didn't expect why a C:\ path didn't work and I was also wondering if I would be able to replicate in the CI. Sounds like I won't be able to in the CI but if you have luck with the fix above, then that is what I will change. Its not that unusual, I just didn't know how to word it.