• It runs on used github runner (ubuntu 22.04 with python 3.10)
• Less CI/CD minutes thanks to the removal of docker container building time
• Use~/semantic-release folder

Maybe problem arise when used in docker container or on windows runner. Was this supported before ?

Looks good just from reading through, couple of questions but I'll review in more depth when I can run this on a project too.
The Docker container was marked for GitHub Actions only, but I don't know if we need to delete it immediately. Maybe it can be reworked into a published image at some point.
Why do you expecttool.semantic_release.build_command to break? Existing users need to specifybuild-system.requires for their build and/or a full script (including install) in thebuild_command currently.
Thanks for the effort in the PR, think this will be really cool

I don't understand howtool.semantic_release.build_command is supposed to work, I will go read the source code.

I expecttool.semantic_release.build_command to break if the user was not relying onbuild-system.requires for specifying dependencies. For example, on a project I was using poetry + nuitka, and relying on the debian backend for C-level deps (glibc version especially, not backward compatible). I can only grasp a fraction of the esoteric shenanigans done to build packages. At least, I suspect some may break from the transition debian -> ubuntu.

Build relying onbuild-system.requires to make wheels should work fine.

More important than that, I identified a bug in my version for GITHUB_OUTPUT variable.tag,released andversion are not set correctly.

Look at the env inAdd file to check if it is added

Master:https://github.com/zckv/semantic-versioning-example/actions/runs/6233057268/job/16917466927

Branch:https://github.com/zckv/semantic-versioning-example/actions/runs/6222835609/job/16887537001

I will work on correcting that.

I forgot to add thevalue keyword of the action outputs...

Now this seems to work fine.

Hey@zckv

Finally got around to testing this over at anotherrepo & I agree, it seems to work fine. Actions run a lot faster too now!

I'll sort the conflict in the Dockerfile out

I appreciate the updates hoping to make this action more efficient and not break backwards compatibility, but unfortunately this update still broke our workflows.

For anyone else potentially running into an error that looks like this:

Run python -m venv ~/semantic-release/.venv  python -m venv ~/semantic-release/.venv  source ~/semantic-release/.venv/bin/activate  pip install python-semantic-release  semantic-release --help  shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}  env:    REPOSITORY: jasmine-bot    BRANCH: main    IMAGE_TAG: main    AWS_ACCOUNT_ID: ***/var/cache/github-actions-runner/_temp/8bef674b-1c76-4b00-a4ea-65c478c03cf9.sh: line 1: python: command not foundError: Process completed with exit code 1[27](https://github.com/Jasmine-Energy/jasmine-bot/actions/runs/6618216903/job/17976953641#step:3:29).

You need to add thesetup-python step to your workflow before semantic release, i.e.:

...  release:    name: Release    runs-on: [self-hosted, factory]    steps:      - name: Github checkout        uses: actions/checkout@v3      - name: Set up Python        uses: actions/setup-python@v4        with:          python-version: '3.10.0'          cache: 'pip'      - name: Python Semantic Release        uses: relekang/python-semantic-release@master...

This is on a self-hosted actions runner, on Ubuntu 20.04, with python 3.10 installed.

Hello@venachescu 👋

I'm sorry that it broke your workflows, I didn't consider the self-hosted runners option.

Python is a dependency of this action. Before, the problem didn't happen because python was installed within the Dockerfile. As GitHub Hosted runners have python3.10 per default, I thought python3 interpreter would be available at all time.

Should I make a new branch to enhance the behavior of this error?

Hey@venachescu - I should add my apologies too, I'd also glossed straight over the question "what if there's no Pythonentirely?"

If you don't manage to get to it today@zckv I'll modify theaction.sh to check for Python and give a better error if it's missing, and put it out as a breaking change

I don't think there is a better way of handling this than to display a better error. And adding documentation.

Another method is to install a python3 (>=3.7) interpreter on the machine, but that is too risky from my point of view.

According to GitHub documentation, self-hosted runners can run onmany different platforms. I'm not sure if the new version can run on RHEL7, as the default interpreter is python3.6. I would document that this action does not officially support self-hosted runners.

Or maybe reverting the changes and do a separate action, like python-semantic-release/upload-to-gh-release ?

I reverted the changes for now - let's make a new PR.

Good point about self-hosted runners. There's a lot of different OSs. I'd be more inclined to take the stance that we support self-hostedwith some prerequisites, that's fairly normal when taking on the overhead of self-hosting, but it needs to be documented & released as breaking.

We shouldn't be installing an interpreter as part of the action, and Windows is going to be problematic (I just tested). Should be doable though 🤞

Hi@zckv and@bernardcooke53 - no worries about the broken workflows, and thanks for jumping on this so quickly!

We have a slightly unusual setup where python (version 3.10) is installed on the self-hosted runners, but it's managed by pyenv and not installed using the usingapt install python3 or similar. I didn't have time to dig into it yesterday, but now I realize that the only way to get the actions runner to find that installation of python is doing something along the lines ofecho "$HOME/.pyenv/bin" >> $GITHUB_PATH.

Either way, having theactions/setup-python@v4 as step in the workflow is totally acceptable for us here, but it sounds like you guys are hoping to find a solution that avoids this!