Closed kmpoppe closed 1 year ago
Idea from #322, @Kashalls was it that what you had in mind?
Pretty much. I don't like the SUPPORTED-VERSION
name. You should change it so something less angry. Maybe supportedVersion.yml
or something easier on the eyes.
What, you don't like filenames shouting at you? ;-) I'll be waiting on Matt here solely for reasons of file-placement in the repo, he might have other ideas than just the root folder for the file, so we'll change name and path later on.
What, you don't like filenames shouting at you? ;-) I'll be waiting on Matt here solely for reasons of file-placement in the repo, he might have other ideas than just the root folder for the file, so we'll change name and path later on.
Honestly if someone just walked up to you and screamed SUPPORTED VERSION you'd be concerned too right?
neat.
but i agree with Kashalls, SUPPORTED-VERSION
looks kinda weird, but does not really brother me.
he might have other ideas than just the root folder for the file
like .assets
or .github/assets
, to store files that are needed for gh actions, since i will need to place some stuff too for creating an automatic release.
This looks great, thanks for taking the time to set this up.
For the access token, secrets.GITHUB_TOKEN, I believe this is actually generated automatically on GitHub's end made specifically for the Action upon running, and expires after completion of the action. So I don't believe any specific access token needs to be added to repository secrets. https://docs.github.com/en/actions/security-guides/automatic-token-authentication
According to the above documentation, it looks like we can also specify permissions, to limit the amount of the permissions on the temporary generated token for added security. Since the script appears to just read and write issues, I believe it would look like this:
jobs:
create_issue:
runs-on: ubuntu-latest
permissions:
issues: read
issues: write
steps: ....
Also on line 40 of checkversion.yml, not sure if secrets.GITHUB_TOKEN is suppose to be case sensitive, but we could probably replace secrets.github_token with secrets.GITHUB_TOKEN, unless there was a reason for the case difference.
I'm still a bit new to GitHub Actions, so if any of that sounds wrong to anybody let me know.
Above was in reference to "only thing needed is an access token from @Pugmatt as the maintainer of the repo.", but reading back you might have meant if we run the workflow outside of Actions and on a root server. If that was what you meant then yeah it would probably need a manual access token like you said.
Changed your guys' suggestions.
but reading back you might have meant if we run the workflow outside of Actions and on a root server. If that was what you meant then yeah it would probably need a manual access token like you said.
Yep, Settings -> Developer Settings -> Personal Access Tokens
I'm still a bit new to GitHub Actions, so if any of that sounds wrong to anybody let me know.
This is essentially the first ever working GH action I built from scratch, so I'm by no means knowledgable, I added the permissions to mean what I think is right (read of contents for files, write access to issues - thinking that that implies reading as well) and it seemed to work. Let's see if it does so in production 😅
not sure if secrets.GITHUB_TOKEN is suppose to be case sensitive
pretty sure it is. Even tho i wouldn’t be suprised if gh actions handles it more flexible.
pretty sure it is. Even tho i wouldn’t be suprised if gh actions handles it more flexible.
Both steps worked when the casing was different, so I wouldn't have been too fussed, but it just looks cleaner with both all caps.
pretty sure it is. Even tho i wouldn’t be suprised if gh actions handles it more flexible.
Both steps worked when the casing was different, so I wouldn't have been too fussed, but it just looks cleaner with both all caps.
i have written it allways that way. But if it work it work ;).
Deployed the cron, so it should be actually checking automatically now hourly.
This PR adds a GitHub action that
Even though the GitHub actions scheduler lets you create crons that are supposed to run every 5 minutes, they are unreliable and might simply not run for hours on end due to the high load of queued actions.
For that reason, the Workflow is triggerable manually AND via an HTTP-API-call. That way we can use any root server to hourly trigger the workflow, only thing needed is an access token from @Pugmatt as the maintainer of the repo.
For merging, use squash and merge because this took way too many commits to come out the right way ;-)
Idea from #322, @Kashalls was it that what you had in mind?