Please, always provide a motivation for the PR! An explanatory comment, to make it easier to review (understand) the changes.

I'll do this once again on your behalf, if you don't mind.

Done, above.

References:

• Description of issue solved with this PR
• Current build process for a Linux bundle
• Installation instructions (README)
• Original build process on Travis CI

I'm happy you continue on this road to get the implementation into a final state.

Note that this can (should!) only be an intermediate solution. It's because where people would look for downloads is always the repository's Releases section. We need to publish new version there, in the long run.

I was afraid I had pointed you into the current direction from the beginning. But looking at our past conversations I see that I suggested using the Create-Release GitHub Action (over the Upload-Artifact) from the beginning. – I believe, uploading artifacts really has a different use case than publishing releases. It's more for intermediate results you want to use in later stages of automation, or asynchronous pipeline processes.

I suggested using the Create-Release GitHub Action (over the Upload-Artifact) from the beginning.

Yes. I agree but I have taken a couple of shots at using Create-Release without success. Perhaps if you or someone else could create a PR to demonstrate how Create-Release would be applied to this project, then I could plug my efforts into that. Sorry for being so dense.

Have you tried the code sample in their README? It should be pretty much copy+paste. Not even configuring a secret seems to be needed:

on:
  push:
    tags:
    - "*"

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - name: Create Release
      id: create_release
      uses: actions/create-release@v1
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      with:
        tag_name: ${{ github.ref }}
        release_name: PythonTurtle-v${{ github.ref }}

(I omitted the body, draft and prerelease options, assuming they are empty or false by default.)

It's possible that the artifacts that you create with your implementation come in handy here. "Something" needs to be provided for the release to be created. That needs to be figured out.

P.S.: Interestingly, they don't seem to eat their own dog food... 😏 Would be good if we could find a similar project repository that uses that Action. For a working example.

It appears that creating the build artifacts and releasing are (meant to be) separate activities.

If that is true, the release workflow may look like this:

1. Every time a change is merged to master we run the builds that create the artifacts (binaries for all target platforms)
2. If a Git tag is pushed to master then the create release workflow uses the artifact of builds related to that very commit to craft a release.

Now, how do we access the artifacts of the ${{ github.ref }} and feed them into the Create-Release Action? There are some interesting examples in the issues of their repository, but I didn't yet understand how supplying the artifacts is done. 🤔

One workflow needs other workflows?

Good point! I hope that doesn't tightly couple the two workflows. (Imagine you have to directly create a release, but you wanted to - manually - try out the binaries first. That would be possible with independent workflows.)

For the assets, it seems like one must first create a release and then upload assets using the upload_url value of the response of the create release API endpoint. This is also hinted at from their README, I figured. Looks like we're getting closer! 🤞

Issue actions/create-release#79 seems to describe a setup that comes close to what we probably need.

Or similar here, actions/create-release#14 (comment).

Me walking into this thread like: