Integration with prql
Closed this issue · 10 comments
The solution is divided in two main files:
-
release.yml: This file should remain in the prql/prql main repo. It's the one responsible of sending a workflow dispatch with the tag and the url needed. Another important consideration: the dispatcher uses a secret as the docs denote. So a new secret will be required in prql/prql with the permission required.
-
update.yml: This file does the automated versioning work with the inputs obtained by the previous file. There's no consideration concerning Integration as It works on the prql/homebrew-prql repo.
Great! Do you want to PR the release.yml into the main repo?
If we can't get the dispatch working, I guess we could cron to check if there are any updates in the releases, and that wouldn't require any auth.
It would also be fine to have a manual workflow for the moment (though the automated workflow is very cool indeed, beyond just PRQL)
Yeah we could PR it and give it a try! the bitter part of all of this is the tedious testing-method commented on discord the other day, I don't want to "stain" the main repo with some testing 😅
And with the manual workflow thing, I assume you refer to create a manual workflow similar to release.yml to trigger when a release is done, so the workflow is more controlled.
Anyway, despite of triggering 4 times the workflow, as It's a commit, the first one works just fine, the other ones don't dectect any changes so they push nothing as is up to date!
Yeah we could PR it and give it a try! the bitter part of all of this is the tedious testing-method commented on discord the other day, I don't want to "stain" the main repo with some testing 😅
Don't worry too much about this. But one thing I've done before is test by having the workflow run on every commit, and only changing it to trigger on releases just before merging. That way we can test on a branch without doing lots of releases on the main repo. Or possibly another alternative is to try from another repo
Anyway, despite of triggering 4 times the workflow, as It's a commit, the first one works just fine, the other ones don't dectect any changes so they push nothing as is up to date!
But does the current version rely on you putting your personal access token into the PRQL GitHub variables, such that anyone with commit access has access to your repos? That's my concern about the current approach. We could create a new user as an alternative. Or the cron / manual release if that's easier.
About the PAT_TOKEN, I think is as easy as creating a new secret on the prql repo, and using it in order to confirm it is an authorized workflow.
This is what I have on my dummy repo of prql:
Maybe using PAT_TOKEN as name for the secret wasn't the most indicated 😅
Ah OK! What is the PAT token? Is it a personal access token? Can you limit that scope sufficiently?
Here you have the docs about it 👀
Summarized, it's like a token you can create for the workflow with the just permissions you want
Right but what is the content of the secret? Is it a personal access token? Because anything running on main will be able to get access to it, including any administrators of the repo, so we can't have your someone's full GH access available from it.
Alright now I get your point! Well, yes It has to be a PAT_TOKEN, so it would be necesary that you create a PAT_TOKEN with just the right permission for this repo. If not It would be necessary to create a new user just for that token.
If you do want to trigger a workflow from within a workflow run, you can use a personal access token instead of GITHUB_TOKEN to trigger events that require a token. You'll need to create a personal access token and store it as a secret.
Extrated from: https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#triggering-a-workflow-from-a-workflow
P.D: Sorry I didn't get you earlier! 😅
Closing as completed!