Skip to content

Add @ to allowed separators of version_variables #1156

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.

Sign up for GitHub

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

Jump to bottom
Closed
benedikt-hess-km opened this issue Jan 27, 2025 · 11 comments · Fixed by #1185
Closed

Add @ to allowed separators of version_variables #1156

benedikt-hess-km opened this issue Jan 27, 2025 · 11 comments · Fixed by #1185
Labels
confirmed Prevent from becoming stale feature A new feature or a feature request

Comments

@benedikt-hess-km
Copy link
Contributor

benedikt-hess-km commented Jan 27, 2025 •
edited
Loading

Feature Request

Description

Currently, when defining version variables with the version_variables configuration parameter, the versions in the specified files, have to be preceded by :, = or :=.

See

python-semantic-release/src/semantic_release/cli/config.py

Line 719 in 2f18a6d

r"\s*(:=|[:=])\s*",

I would like to add the @ to the allowed separators, as it is used in gitHub actions ymls.

Use cases

I have a github repo (e.g. my-org/my-actions) containing multiple actions:

my-actions/.github/workflows/
        action1.yml
        action2.yml
        combined.yml

action1.yml and action2.yml are both called by combinded.yml

on:
  workflow_call:
jobs:
  action1:
    uses: my-org/my-actions/.github/workflows/action1.yml@v1.2.3
  action2:
    uses: my-org/my-actions/.github/workflows/action2.yml@v1.2.3

Currently there is no way for PSR to update the two versions in the combined.yml file.

Possible implementation

change line to r"\s*(:=@|[:=])\s*",

python-semantic-release/src/semantic_release/cli/config.py

Line 719 in 2f18a6d

r"\s*(:=|[:=])\s*",

@benedikt-hess-km benedikt-hess-km added feature A new feature or a feature request triage waiting for initial maintainer review labels Jan 27, 2025
@codejedi365
Copy link
Contributor

codejedi365 commented Jan 27, 2025 •
edited
Loading

Seems reasonable, just note that we also have issue #846 open as tag formats (default tag version is usually prefixed with a v) are not supported yet either.

@codejedi365 codejedi365 added confirmed Prevent from becoming stale and removed triage waiting for initial maintainer review labels Jan 27, 2025
@benedikt-hess-km
Copy link
Contributor Author

@codejedi365 Thank you for your response! Seems like the issue number you referred to did not make it into the comment. Could you add it?

@codejedi365
Copy link
Contributor

@codejedi365 Thank you for your response! Seems like the issue number you referred to did not make it into the comment. Could you add it?

Updated. Must of got distracted before completion, thanks.

@benedikt-hess-km
Copy link
Contributor Author

Thank you! I'll try to implement the features within this week and get back to you once I published the PR. I will improve some of the documentation regarding the version_variables configuration as well, as it took me some time to figure out how exactly it works.

@benedikt-hess-km benedikt-hess-km mentioned this issue Feb 12, 2025
Merged
6 tasks
@benedikt-hess-km
Copy link
Contributor Author

@codejedi365 sry it took me so long, i just published a pull request!

@codejedi365
Copy link
Contributor

@codejedi365 sry it took me so long, i just published a pull request!

No problem, thanks for the support, I'll take a look tonight

codejedi365 pushed a commit to codejedi365/python-semantic-release that referenced this issue Feb 17, 2025
@benedikt-hess-km @codejedi365
feat(cmd-version): extend version_variables to stamp versions with …
a654913 
…`@` symbol separator

Resolves: python-semantic-release#1156
codejedi365 pushed a commit to codejedi365/python-semantic-release that referenced this issue Feb 17, 2025
@benedikt-hess-km @codejedi365
feat(cmd-version): extend version_variables to stamp versions with …
820947c 
…`@` symbol separator

Resolves: python-semantic-release#1156
codejedi365 pushed a commit to codejedi365/python-semantic-release that referenced this issue Feb 17, 2025
@benedikt-hess-km @codejedi365
feat(cmd-version): extend version_variables to stamp versions with …
a04c408 
…`@` symbol separator

Resolves: python-semantic-release#1156
codejedi365 pushed a commit to codejedi365/python-semantic-release that referenced this issue Feb 17, 2025
@benedikt-hess-km @codejedi365
feat(cmd-version): extend version_variables to stamp versions with …
7bb51d2 
…`@` symbol separator

Resolves: python-semantic-release#1156
codejedi365 pushed a commit to codejedi365/python-semantic-release that referenced this issue Feb 17, 2025
@benedikt-hess-km @codejedi365
feat(cmd-version): extend version_variables to stamp versions with …
bb4b5e3 
…`@` symbol separator

Resolves: python-semantic-release#1156
@codejedi365 codejedi365 linked a pull request Feb 17, 2025 that will close this issue
config, version_variables: allow @ as separator and v to precede the version #1185
Merged
6 tasks
@codejedi365
Copy link
Contributor

🎉 This issue has been resolved in Version 9.20.0 🎉

You can find more information about this release on the GitHub Releases page.

@benedikt-hess-km
Copy link
Contributor Author

@codejedi365 i just checked if everything worked. unfortunately it does not, as psr does not allow the "v" in front of the version. was this intentional? My pr did include this feature.

@codejedi365
Copy link
Contributor

codejedi365 commented Feb 17, 2025 •
edited
Loading

@benedikt-hess-km, did you review the new configuration docs?

If you want to stamp the tag format, you need to specify :tf as the third part of the version_variables definition.

The problem with an optional v, is that PSR allows for a custom tag format so the v-prefix is not guaranteed. Unfortunately this means it's not flexible to be compatible between tag-formatted versions and numeric versions so make sure the one you are trying to replace is a tag format.

If I did mess something up then please identify what the mistake was in the E2E test because that one was supposed to mirror your exact situation.

@benedikt-hess-km
Copy link
Contributor Author

oh wow sry I did not! Works like a charm!

@codejedi365
Copy link
Contributor

Glad to hear, you had me worried for a minute.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
confirmed Prevent from becoming stale feature A new feature or a feature request
Projects
None yet
Milestone
No milestone
2 participants
@codejedi365 @benedikt-hess-km