Are we running CI on all PRs or only on PRs within...
# contributing-to-airbyte
a
Are we running CI on all PRs or only on PRs within team? I can’t see that it run for this https://github.com/airbytehq/airbyte/pull/1736
u
Once it was merged on master, there was this build i think: https://github.com/airbytehq/airbyte/runs/1742097539?check_suite_focus=true
u
well when its merged in master - there is commit from someone within the team. And its quite obvious that it will run in master, but shouldn’t it also run on every PR in some limited version?
u
currently the build doesn't run for PRs from forks.
u
it seems like if we can get it to run for forks though that we would prefer thyat.
u
i'm not sure if there was a technical reason we did it this way or if we set it up when we were still having to pay for github actions and were being conservative.
u
@Jared Rhizor (Airbyte) do you know off the top of your head?
u
IIRC workflows can run in forked repos but the owner of the forked repo has to enable actions themselves. Then the actions run on their fork (they can’t access creds on the main repo)
u
oh. interesting.
u
and that's free for them, right?
u
yeah should be
u
should we add this as a suggestion in the PR template as an (optional) suggestion if they want to see the build info?
u
I do not think that potential contributors want to enable git actions in their forked repo. Anyway it won’t give us much info as we will need to check their repo to make sure that PR is passing.
u
true.
u
The issue was that I totally missed that CI is not running in contributor’s PRs and merged it.
u
no big deal. it happens.
u
So ideally if somebody is contributing - we want to see whether we can merge or not.
u
what if we add a trigger to allow someone to run the build via a comment?
u
(like we do for running integration tests)
u
I don’t think that works for forked prs
u
for the same reason
u
actually
u
i don’t know how that works.
u
maybe it is possible since the trigger is defined in the main repo?
u
oh. i thought the zazmic guys were doing.
u
zazmic guys are now PR-ing without forks
u
this PR is from before they were using main repo.
u
that actually shows the problem
u
Error: No ref found for: source-mixpanel
u
you can trigger master branch builds with ref=master like hte later ones do
u
aaaah.
u
makes sense.
u
We can probably configure it to checkout a different project (the fork one) but that’s risky because anyone could run a PR and then print out all our secrets
u
yeah. that seems like a no go.
u
this seems like a weird problem.
u
I would better vote to not assume that we will run something in forks. Also if we use some env variables that are set in github, which one will it take for fork’s CI?
u
if we were using any other build system this would not be a problem, right? like i have contributed to OSS on a fork and the travis build or whatever has run
u
yeah
u
some non-github action things let you control secrets access on forks
u
so i guess the question is: is this specific to gh actions and it is intractable or is it specific to how we are using gh actions.
u
or let you run modified CI on forks that the forks cannot modify
u
I think it’s specific to github actions, and impossible to do safely on github actions.
u
well **
u
maybe not impossible, but it feels like it’d be hard to guarantee safety
u
it definitely is possible on some other platforms
u
I think Sherif was looking into some at some point