-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
clarify github actions for fork PRs #262
Comments
@VerenaHeld @Testuser13029 could you paste the screenshot in here? It appears that first of all, non-beta users don't see the "actions" tab in repos with actions. |
says GitHub support:
|
so, to sum up, for now:
So this isn't so great for the tidyverse developer day, unless we want to invite everyone as repo contributors. This all works fine for PRs within the same repo (which is all I have used so far, never noticed this). |
also relevant from the docs:
|
taken together, this seems like a pretty foundational / wide-reaching limitation, unrelated to the limitations for non-beta users, that I hadn't really grasped before.
So at the moment, out-of-the-box, this is pretty limiting for CI/CD via actions out of the box for anything involving forks.
These limitation make sense, unless/until GitHub adds some kind of protection around secret environment variables. |
Work around 1 would be to use This is what the impressive zeit get-stats action appears to do:
This might work, but would essentially open us up to all the dangers this limitation is supposed to mitigate, so I think that's a bad idea. |
Work around 2 might be to use The downstream workflow might then also clone the upstream repo to run tests and comparisons. This should (?) be safer, because never is code run in the environments where there are secrets (the upstream repo). But this seems like quite a bit of work and custom stuff for something that really, github actions ought to be doing out of the box. |
Option 3 might be to just hum loudly and hope for the problem to disappear (i.e. for github to roll out more features). Seems like this might be the best use of resources for now. The The |
going to put this on |
obsolete or done in the new yml-based GitHub actions. |
Ran into the same issue with fork repos, even in yml based actions. Going to test it with 2 beta accounts and see if that works. If it does, whenever Github releases it to general, everyone should have access to actions and it won't be a problem. |
I am using forks and have beta access in the github organization as well as my personal account and I can confirm that PR's from my fork to the organization upstream does not trigger a workflow for pull requests. |
@tomfriedhof are you still experiencing this problem? |
@s-i-l-k-e just tested this again. Builds still do not trigger from a forked repo when PR'd |
I'm pretty sure that that is getting triggered once each from the pull request and from the push. |
Ah, I need to set push to only run on specific branches like |
GitHub Actions are not usable for PR based workflow, see maxheld83/ghactions#262 (comment) This reverts commit 8d3114f.
GitHub Actions are not usable for PR based workflow, see maxheld83/ghactions#262 (comment) This reverts commit 8d3114f.
GitHub Actions are not usable for PR based workflow, see maxheld83/ghactions#262 (comment) This reverts commit 8d3114f.
Any updates on this issue? I think a comment trigger would be also really helpful for this scenario: https://docs.microsoft.com/en-us/azure/devops/pipelines/repos/github?view=azure-devops&tabs=yaml#comment-triggers |
I think most of the discussion in here was about the old (HCL-based) GitHub Actions. Just in case people are still wondering, this is how you can explicate when a workflow should run: on:
push:
pull_request:
types: [assigned, opened, synchronize, reopened]
release:
types: [published, created, edited] More on the official documentation. |
it's a bit unclear how users (at tidyverse developer day etc.) can use github actions if they are not on the beta.
The text was updated successfully, but these errors were encountered: