Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with location of CHANGELOG.md #1123

Closed
dornech opened this issue Dec 14, 2024 · 8 comments · Fixed by #1124
Closed

Issue with location of CHANGELOG.md #1123

dornech opened this issue Dec 14, 2024 · 8 comments · Fixed by #1124
Labels
bug Something isn't working properly

Comments

@dornech
Copy link

dornech commented Dec 14, 2024

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
@dornech dornech added bug Something isn't working properly triage waiting for initial maintainer review labels Dec 14, 2024
@dornech dornech changed the title Issue with location of CHANGELOD.md Issue with location of CHANGELOG.md Dec 14, 2024
@codejedi365 codejedi365 removed the triage waiting for initial maintainer review label Dec 14, 2024
@codejedi365
Copy link
Contributor

codejedi365 commented Dec 14, 2024

@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
Copy link
Contributor

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
Copy link
Contributor

@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
Copy link
Author

dornech commented Dec 15, 2024

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
Copy link
Contributor

@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
Copy link
Author

dornech commented Dec 15, 2024

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
Copy link
Contributor

@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.

@codejedi365
Copy link
Contributor

🎉 This issue has been resolved in version 9.15.2 🎉

The release is available on:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working properly
Projects
None yet
2 participants