DEV: Release using the REL commit instead of git tag

[MartinThoma]

The git tag is automatically added

Pro:

• This allows two contributors with write-permissions to trigger a PyPI + GitHub release

Con:

• My Github Access Token needs to be stored in the repository as a secret. The maximum lifespan of a fine-grained access token seems to be about two years, meaning I may not forget to update it regularly.

[MartinThoma]

TODO:

• Add the token to the repository
• Remove the first line of the commit from the git tag ("REL: ...")

[MartinThoma]

@stefan6419846 @pubpub-zz This would be my suggestion. The only alternative I see is making one / both of you admins.

I am thinking about passing the maintainer role to one of you, but independently of that I think it would be nice if we had a way in which multiple people in the community (with GitHub write permissions) could trigger a release.

[stefan6419846]

Do we really need the personal access token (PAT) here? https://github.com/ncipollo/release-action and https://github.com/rickstaa/action-create-tag/blob/main/entrypoint.sh seem to work with the default GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} environment variable as far as I am aware - at least for personal repositories.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.67%. Comparing base (8dbfeba) to head (13f7327).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2500   +/-   ##
=======================================
  Coverage   94.67%   94.67%           
=======================================
  Files          50       50           
  Lines        8230     8230           
  Branches     1646     1646           
=======================================
  Hits         7792     7792           
  Misses        268      268           
  Partials      170      170           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[pubpub-zz]

@stefan6419846 @pubpub-zz This would be my suggestion. The only alternative I see is making one / both of you admins.

I am thinking about passing the maintainer role to one of you, but independently of that I think it would be nice if we had a way in which multiple people in the community (with GitHub write permissions) could trigger a release.

I currently have not studied the way to make release. I think you should consider @stefan6419846 as admin. I prefer to stay with current rights to be sure to make no damage 😳

[stefan6419846]

I currently have not studied the way to make release.

This is documented in our docs and will receive some updates as soon as we have solved the tagging issue: #2499. Besides this, I am sure that neither Martin nor any other person (including me) will force you into anything against your will ;)

[pubpub-zz]

This is documented in our docs and will receive some updates as soon as we have solved the tagging issue: #2499. Besides this, I am sure that neither Martin nor any other person (including me) will force you into anything against your will ;)

Damned! My lazyness has been spotted

[stefan6419846]

I debugged this a bit and read the docs to find a way to not rely on the PAT: We have to grant write permissions for the repository content as detailed at https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions While my approach fixes the use of the deprecated set-output directive as well, it seems like we still run too often, id est for all commits.

Test repository: https://github.com/stefan6419846/gha_release_tests/blob/main/.github/workflows/release.yml

[stefan6419846]

I have been able to fix the condition as well in my test repository, thus it seems like we should be able to test/replace the PAT approach with the auto-generated GitHub token one.

[stefan6419846]

I have added some proposals to get rid of PATs which have to be maintained manually. The only thing left would be to remove the first line of the tag message if I am not mistaken?

[stefan6419846]

Removing the first line from the tag message is a bit trickier when doing everything with default Linux tools and getting used to setting multi-line variables in GitHub. We probably want to use something like the following step for retrieving the correct message:

      - name: Extract tag message from commit message
        id: extract_message
        run: |
          VERSION="${{ steps.extract_version.outputs.version }}"
          delimiter="$(openssl rand -hex 8)"
          MESSAGE=$(echo "${{ github.event.head_commit.message }}" | sed "0,/REL: $VERSION/s///" )
          echo "message<<${delimiter}" >> $GITHUB_OUTPUT
          echo "$MESSAGE" >> $GITHUB_OUTPUT
          echo "${delimiter}" >> $GITHUB_OUTPUT

[stefan6419846]

I have proposed a solution for the message now as well.

Feel free to verify and check it. Although I tried to test most of this in a dedicated repository manually, I might have missed something or some stuff could be simplified.

[MartinThoma]

@stefan6419846 Thank you for your help 🙏

[MartinThoma]

@stefan6419846 @pubpub-zz I think both of you should now be able to release 🎉

If you notice other people doing substantial contributions and would like them to be contributors as well, let me know :-)