This wouldn't give a PR the "all clear" (green check) because overall_status would still be pending, correct?

This wouldn't give a PR the "all clear" (green check) because overall_status would still be pending, correct?

Exactly it's posted right after the initial pending status.

Didn't Graham say he'd be AFK for a while this month? Hasn't been active on github or irc for a week.

cc @LnL7

NixOS/nixpkgs@5ca7be3

I've bumped the timeout from 30min to 45min as we're still getting builds going red.

Update: I've just reset a bunch of PRs that timed out at 45mins.

Just a quick note: I'm in favor of merging this, but I just tried to redeploy to get our 3rd evaluator back, which failed.

Even if I did merge this, nothing would change until Graham has time to look into the deployment problem, so I'll just wait for him to be available again and 1) have him look at that; and 2) comment on this PR (if necessary).

NixOS/nixpkgs#95126

Lets disable the actions until this is resolved so we don't have pages of red PRs.

What do we think about using actions to manually set a pending status without a timeout that is then cleared as part of this step?

There would be two actions statuses, one for the pending job and another from the job that sets it.

What do we think about using actions to manually set a pending status without a timeout that is then cleared as part of this step?

There would be two actions statuses, one for the pending job and another from the job that sets it.

That would work too and is probably the better solution.

What do we think about using actions to manually set a pending status without a timeout that is then cleared as part of this step?
There would be two actions statuses, one for the pending job and another from the job that sets it.

That would work too and is probably the better solution.

I am not quite sure if it is possible so because the github token in github actions comes from the user that opens the pull request.

https://docs.github.com/en/actions/reference/events-that-trigger-workflows#pull_request_target

This event is similar to pull_request, except that it runs in the context of the base repository of the pull request, rather than in the merge commit. This means that you can more safely make your secrets available to the workflows triggered by the pull request, because only workflows defined in the commit on the base repository are run.

Hopefully this would allow us to use a token in PRs?

docs.github.com/en/actions/reference/events-that-trigger-workflows#pull_request_target
This event is similar to pull_request, except that it runs in the context of the base repository of the pull request, rather than in the merge commit. This means that you can more safely make your secrets available to the workflows triggered by the pull request, because only workflows defined in the commit on the base repository are run.

Hopefully this would allow us to use a token in PRs?

Yes. This sounds great. We could also use this for cachix. We could even implement this without using ofborg:

1. Having a workflow that just creates a Waiting for ofborg task
2. Use a second action that mark the first as complete if the ofborg suite is complete https://docs.github.com/en/actions/reference/events-that-trigger-workflows#check_suite

I will update this PR to mark the Wait for ofborg as non-pending once this project is maintained again.

ping @grahamc

@grahamc If we're going to start running more actions in PRs it would be nice to get this resolved.

Ping @cole-h @grahamc

cc @SuperSandro2000

Why did you ping me?

Sorry, meant to link to IRC. This PR would address your comment about wait for ofborg: https://logs.nix.samueldr.com/nixos-borg/2021-01-27#4546552

Note that I haven't deployed this change yet. In order to streamline this: which PR, if any, needs to be merged after the deploy succeeds?

which PR, if any, needs to be merged after the deploy succeeds?

NixOS/nixpkgs#96707

Done.