https://pantsbuild.org/ logo
Join SlackCommunities
Powered by
<@U02KAN6061E>: hm: does <https://github.com/pants...
# development
w
it doesn’t look like it should/would
but it went green on your PR (and is blocking the 
2.17.0a0
release prep PR)
…hm. but you pushed it to 
origin
. is that why it is green…?
b
No, that's the following step. So: 1. Ugh I need a stiff drink 2. This shouldn't gate PR, obviously 3. #1 again 😐
w
heh. i’m going to disable it for now.
b
I'm starting to daydream my life as a humble farmer. Far away from technology
So from:
Error: Input required and not supplied: repo-token
Tells me the PAT might be wrong? Or unset? Here's the workflow for the run: https://github.com/pantsbuild/pants/actions/runs/5017155703/workflow?pr=19038
Can you check that secret?
Also FYI IDK how the branch protection is set, but I assume that this action isn't gating PRs. So just informational
w
branch protection is “all checks”
b
Ah
w
…oh. or. hm. wait.
that’s a lie… it won’t gate. branch protection is on “Merge OK”
b
So annoying and should be fixed, but not fatal at the moment
w
yea, thanks. i’ll re-enable.
b
I also don't understand what's going on. The error says that 
repo-token
wasn't provided,... • Expanding the log shows it isn't being logged • Expanding the "Workflow file" shows it is
w
um. are secrets actually provided to PR builds?
b
Yes
By default, GitHub settings: • Doesn't allow secrets to be accessed on a fork's actions • Runs the workflow definition from the mainline on PR builds (from forks from PRs I think. Unsure about PRs from same-repo-branches) So security is on-by-default
w
b
😮‍💨
Workflows triggered via 
pull_request_target
have write permission to the target repository. They also have access to target repository secrets. The same is true for workflows triggered on 
pull_request
from a branch in the same repository, but not from external forks. The reasoning behind the latter is that it is safe to share the repository secrets if the user creating the PR has write permission to the target repository already.
w
it’s not shown as a check for that PR
i think you need to trigger it differently, perhaps.
b
Oh yeah that's an issue not a PR
It seems there hasn't been a run in that repo on a PR since it was introduced 7 months ago? 😐 https://github.com/actions/first-interaction/actions/workflows/first-interaction.yml?query=event%3Apull_request
w
😬
b
The only explanation (because there have been PRs) is that they disabled it?
So it should be safe to use 
pull_request_target
since we aren't checking out code
w
🚢
(with comment)
b
Yeah this is still an issue, I'm seeing failures on merges with bases older than my fix. We might wanna look into the right GH setting
So some observations: • Cherry pick has merge strategy options. So there might be some amount of "merging" • The error is that both we and the other branch added the same files (seemingly every file in the repo
2 Views
Open in Slack
PreviousNext
Powered by