GitHub Action: Using A Different Python Version #685
Description
Activity
Hi 👋
The Python version is fixed to 3.10 but I'd definitely accept a PR to parameterise with 3.10 as a default
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.
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.
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 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 🙂
11 remaining items
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?
Looking towards v11 now as I have to update the composite action PR
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.
@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.
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.
Reacted by codejedi365@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
Reacted by Zackarie VinckierIt 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?
Still in backlog
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?
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!