You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
GitHub Action: Using A Different Python Version #685
Hi, we build our project in a strict environment where python version is set to 3.9.x. We're receiving version mismatch errors when cutting a release using the GitHub Action since it's image is based on python 3.10. Am I missing some configuration which allows me to select the intended python version? Or, I wonder if such restriction can be relaxed a bit, e.g. by parametrising the base image as a docker build arg. Thank you!
I would like to parametrize the job environment too. My idea would be to convert the docker action to a composite action. It then would be easier to configure the environment, or to execute the action in a containerized job.
If this is good enough, I can make a PR for the end of August.
I would agree that a GitHub composite action is more flexible than a docker action, leaving us more room for manoeuvre. On the other hand, however, I'm not sure if this also means the dependencies specified in an environment have to be resolved together with the ones required by python-semantic-release. I'd imagine we might break something if there is a conflicting requirement which is also defined by a user.
I'm pretty new to this project, so maybe I've been talking a bit nonsense.
I think the suggestion to use a composite action instead is a reasonable, but @chenkai036 has a very good point re: ensuring we don't break existing workflows. I'd thought perhaps there was a way to specify the build-arg for the Dockerfile, but that doesn't seem to be the case (at least I couldn't find anything to suggest it's possible).
It's worth remembering that Python Semantic Release is still a Python command-line application, so it's always possible to pip install with the Python version that you're currently using, if you're constrained on Python version.
That said, if you're keen to explore trying to make the action more flexible I'm all for it, but I think there could be a couple of issues:
If we were just to convert to using a composite action, it would require a user to run setup-python beforehand to choose the appropriate Python version. This would be a breaking change to anyone using the action currently instead of installing via pip (which I suspect is most GitHub Actions users). So I don't think we can do something like run entrypoint.sh directly.
GitHub Actions currently builds the container to run the step on each workflow anyway, so I think we wouldn't be costing extra CI/CD minutes to have a shell script as an entrypoint which runs docker build . -f Dockerfile --build-arg ... - but we would then run into the issue of needing to ensure docker is available in the action.
For me, a PR would need to make sure that:
Existing workflows continue to behave the same way (i.e. run on Python 3.10, no code change required by the end user)
We don't add on a significant amount of CI/CD minutes compared to the current action,
Any changes which might pollute the workflow environment (such as installing dependencies outside a docker container vs. inside) are documented.
If you've got some ideas for an implementation and want to discuss here then this is a good place, or otherwise if it's easier to code an idea up then we can discuss it on a PR 🙂
It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
It is a separate project that only contains the action, so that is different from my original PR that replaced the "action.sh" file in the PSR project.
This action will break some users CI if copied in the PSR project, those who run their CI in containers without python. Maybe CI running on Windows will break too.
In this separate project, I put everything in the "action.yml" file and I added switch-case block for compatibility between PSR version. It works like my original PR. If you want to update the composite action PR, you may copy the part that is suited for PSR 9.X.
@zckv, ok neat, I'll check it out thanks. That is some of the changes I was going to make anyway. But also need to update it for newer parameters provided
It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
It has been 90 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
Activity
bernardcooke53 commentedon Aug 16, 2023
Hi 👋
The Python version is fixed to 3.10 but I'd definitely accept a PR to parameterise with 3.10 as a default
zckv commentedon Aug 17, 2023
Hello 😃
I would like to parametrize the job environment too. My idea would be to convert the docker action to a composite action. It then would be easier to configure the environment, or to execute the action in a containerized job.
If this is good enough, I can make a PR for the end of August.
chenkai036 commentedon Aug 18, 2023
Thanks @bernardcooke53 and @zckv for the replies!
I would agree that a GitHub composite action is more flexible than a docker action, leaving us more room for manoeuvre. On the other hand, however, I'm not sure if this also means the dependencies specified in an environment have to be resolved together with the ones required by python-semantic-release. I'd imagine we might break something if there is a conflicting requirement which is also defined by a user.
I'm pretty new to this project, so maybe I've been talking a bit nonsense.
bernardcooke53 commentedon Aug 26, 2023
Hey both 👋
I think the suggestion to use a composite action instead is a reasonable, but @chenkai036 has a very good point re: ensuring we don't break existing workflows. I'd thought perhaps there was a way to specify the build-arg for the Dockerfile, but that doesn't seem to be the case (at least I couldn't find anything to suggest it's possible).
It's worth remembering that Python Semantic Release is still a Python command-line application, so it's always possible to
pip installwith the Python version that you're currently using, if you're constrained on Python version.That said, if you're keen to explore trying to make the action more flexible I'm all for it, but I think there could be a couple of issues:
setup-pythonbeforehand to choose the appropriate Python version. This would be a breaking change to anyone using the action currently instead of installing viapip(which I suspect is most GitHub Actions users). So I don't think we can do something like runentrypoint.shdirectly.docker build . -f Dockerfile --build-arg ...- but we would then run into the issue of needing to ensuredockeris available in the action.For me, a PR would need to make sure that:
If you've got some ideas for an implementation and want to discuss here then this is a good place, or otherwise if it's easier to code an idea up then we can discuss it on a PR 🙂
11 remaining items
github-actions commentedon Mar 2, 2025
It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
codejedi365 commentedon Mar 2, 2025
Looking towards v11 now as I have to update the composite action PR
zckv commentedon Mar 3, 2025
Hello, I have made a separate composite action in https://github.com/zckv/python-semantic-release-composite-action
It does works with PSR v9 and v8, but I haven't tested many uses-cases.
codejedi365 commentedon Mar 4, 2025
@zckv, is it any different than the original PR that you submitted?
That is what the current PR is, the revert of the revert after the original merge and release broke some users CI env and we had to roll back.
zckv commentedon Mar 4, 2025
It is a separate project that only contains the action, so that is different from my original PR that replaced the "action.sh" file in the PSR project.
This action will break some users CI if copied in the PSR project, those who run their CI in containers without python. Maybe CI running on Windows will break too.
In this separate project, I put everything in the "action.yml" file and I added switch-case block for compatibility between PSR version. It works like my original PR. If you want to update the composite action PR, you may copy the part that is suited for PSR 9.X.
codejedi365 commentedon Mar 4, 2025
@zckv, ok neat, I'll check it out thanks. That is some of the changes I was going to make anyway. But also need to update it for newer parameters provided
github-actions commentedon May 4, 2025
It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
codejedi365 commentedon May 5, 2025
Still in backlog
github-actions commentedon Aug 4, 2025
It has been 90 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?