Automatic gentoo ebuild release

[JohnTheCoolingFan]

This uses a containerized gentoo action which I've been working on that will use pycargoebuild to update the ebuild (CRATES and LICENSE) and then update and push to the overlay on release.

Some setup will be needed:

1. GENTOO_PR_TOKEN secret - personal access token that will be used to make a PR to the overlay repo
2. GENTOO_DEPLOY_KEY secret - deploy key with write access to the overlay repo

"Template" ebuild based on 1.7.1 ebuild. Make dependency or other changes before release, CRATES and LICENSE will be automatically updated and then submitted via PR to https://github.com/an-anime-team/gentoo-ebuilds

[github-actions[bot]]

Your PR was set to target main, PRs should be target next.

The base branch of this PR has been automatically changed to next. Please verify that there are no merge conflicts.

[Mar0xy]

While it seems nice I want to point out a security concern considering it is generally advised against using personal access tokens in workflows as well as having an action from an repo affect another one.

I would recommend putting the action in the actual gentoo repo which would allow the use of secrets.GITHUB_TOKEN and then setting it to automatically run every x days to check for new releases on each repo doing the following

- name: Get latest release
        id: get_release
        run: |
          RELEASE_TAG=$(curl -s https://api.github.com/repos/an-anime-team/the-honkers-railway-launcher/releases/latest | jq -r '.tag_name')
          echo "release_tag=$RELEASE_TAG" >> $GITHUB_OUTPUT
          echo "latest release: $RELEASE_TAG"

and then comparing it to the previous version by using ${{ steps.get_release.outputs.RELEASE_TAG }} obviously getting the previous version would be hard with the fact that it's only mentioned in the filename.

But this gives the benefit of it not being in all the other repos which makes it tedious to maintain the action if something goes haywire and also the fact that you dont have to rely on PAT which github is desperately trying to make more secure which also causes them to be more of a hassle for actions.

[JohnTheCoolingFan]

While I do like the idea of moving the action to the overlay repo itself, there are problems... "Run every x days" is too unresponsive to updates. When a launcher is updated, people want the update to be available in a couple of hours, same day max. This could be implemented by using workflow dispatches instead, which would still have a job in launcher repos that just triggers a workflow in the overlay repo. Also, the action will have to be remade to change the workflow of it, which won't be a huge problem for me at this point. I agree with the reasoning, closing the PR.