search

PRQL / homebrew-prql

2 stars 2 forks source link

Integration with prql #2

Closed roG0d closed 2 years ago

roG0d commented 2 years ago

Issue containing all the considerations to keep in mind when integrating with prql

roG0d commented 2 years ago

The solution is divided in two main files:

BUG: As #1 Issue reflect, there's a bug on release.yml.

max-sixty commented 2 years ago

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)

roG0d commented 2 years ago

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!

max-sixty commented 2 years ago

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.

roG0d commented 2 years ago

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: imagen Maybe using PAT_TOKEN as name for the secret wasn't the most indicated 😅

max-sixty commented 2 years ago

Ah OK! What is the PAT token? Is it a personal access token? Can you limit that scope sufficiently?

roG0d commented 2 years ago

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

max-sixty commented 2 years ago

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.

roG0d commented 2 years ago

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! 😅

max-sixty commented 2 years ago

Closing as completed!