search

EdgeTX / buddy

The next generation tool for EdgeTX. A cross platform app, with browser compatibility.
https://buddy.edgetx.org
MIT License
37 stars 19 forks source link

fix: preview-web can't be run on forks #84

Open pfeerick opened 4 months ago

pfeerick commented 4 months ago

GitHub repo SECRETS are not exposed to forks, thus the preview-web step can't be run on pull requests from forks.

It may be possible to use a different event trigger... pull_request_target ... in order to get around this, but this then also changes the context of the base of the pull request, from it being the merge commit, to that of the base of the pull request, and am not sure if this will have unexpected consequences, hence this more immediate quick fix.

codecov[bot] commented 4 months ago

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 39.54%. Comparing base (21b749c) to head (37c1dbb).

Additional details and impacted files ```diff @@ Coverage Diff @@ ## main #84 +/- ## ======================================= Coverage 39.54% 39.54% ======================================= Files 103 103 Lines 12006 12006 Branches 645 645 ======================================= Hits 4748 4748 Misses 7251 7251 Partials 7 7 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

freshollie commented 4 months ago

@pfeerick this makes sense, you could also try implement something like this https://michaelheap.com/access-secrets-from-forks/

pfeerick commented 4 months ago

Oh... thanks for that ... will look at that tomorrow :)

pfeerick commented 3 months ago

Ok, either something has changed in github, or that method only works for checkout... so it looks like the only real way to do this is how github themselves recommended it... by using a split workflow... one being the "insecure", and the second the "secure" one. Thankfully the current structure of the CI build seems to be suited to being split right down the middle where it's needed, so it shouldn't be that hard to simply split it in two.

https://securitylab.github.com/research/github-actions-preventing-pwn-requests/

pfeerick commented 3 months ago

Ok, I'm done for today :face_with_head_bandage: Both stage 1 and stage 2 appear to be working as intended.

stage 1 - test-and-compile - https://github.com/pfeerick/buddy/actions/runs/9591978099 stage 2 - build-app-and-preview - https://github.com/pfeerick/buddy/actions/runs/9592007656 stage 3 - release - https://github.com/pfeerick/buddy/actions/runs/9592184521

stage 2 was expected to fail where it did as while I gave it a valid cloudflare API and re-ran just that failed step, I don't have a mirror of the buddy project setup, so it merely progressed further than the first run.

stage 3 appears to have correctly skipped due to the failure of the prior stage.

Now sort of wondering if I should split it down a bit further... i.e. five workflows ... test, compile, app, web, release ... or maybe rename... test, build, release? :thinking: