feat(action): use composite action for semantic release

[zckv]

For issue #685

Make a venv environment in ~/semantic-release folder, install python-semantic-release with pip.

Dependencies are used in github env keyword.

Changed default git user mail from "github-actions@github.com" to "actions@github.com" to reflect the docs.

Removed --global git option to avoid breaking user environment.

This will probably break tool.semantic-release.build_command. This should not break standard usage.

I tested this on a personal project, it worked fine.

[zckv]

• 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 ?

[bernardcooke53]

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 expect tool.semantic_release.build_command to break? Existing users need to specify build-system.requires for their build and/or a full script (including install) in the build_command currently.
Thanks for the effort in the PR, think this will be really cool

[zckv]

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

I expect tool.semantic_release.build_command to break if the user was not relying on build-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 on build-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 and version are not set correctly.

Look at the env in Add 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.

[zckv]

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

Now this seems to work fine.

[bernardcooke53]

Hey @zckv

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

I'll sort the conflict in the Dockerfile out

[venachescu]

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 found
Error: 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 the setup-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.

[zckv]

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?

[bernardcooke53]

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

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

[zckv]

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 on many 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.

[zckv]

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

[bernardcooke53]

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-hosted with 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 🤞

[venachescu]

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 using apt 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 of echo "$HOME/.pyenv/bin" >> $GITHUB_PATH.

Either way, having the actions/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!