Drop dependabot in favor of automated pip-tools

[richardsheridan]

Closes #2594.

[codecov]

Codecov Report

Merging #2592 (74cef56) into master (9338657) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2592   +/-   ##
=======================================
  Coverage   92.45%   92.45%           
=======================================
  Files         118      118           
  Lines       16342    16342           
  Branches     3155     3155           
=======================================
  Hits        15109    15109           
  Misses       1104     1104           
  Partials      129      129           

Impacted Files	Coverage Δ
trio/_core/_run.py	98.49% <0.00%> (ø)

[richardsheridan]

One subtle quirk of this is that we have to manually delete branches after they've been merged.

[richardsheridan]

@A5rocks this primarily affects you at the moment so please review and merge when you can, as this PR seems to be the preferred option in #2594

[A5rocks]

I think I'm ok with this, but just to confirm: when a PR fails to automerge, if we don't merge it that day (? I can't read cron, I presume this runs once daily?) CI will remake it?

[richardsheridan]

I think I'm ok with this, but just to confirm: when a PR fails to automerge, if we don't merge it that day (? I can't read cron, I presume this runs once daily?) CI will remake it?

It's once a month (best webtool ever). The branch name is distinguished by the base commit SHA so if it so happens that the automerge fails AND no other commits are pushed over the month, then the PR branch will be overwritten by force-push. Otherwise, the bot will make a new branch and PR.

[A5rocks]

Once a month sounds reasonable! Alright then.

[A5rocks]

Looks alright to me! I'd like one other person skim through this before they press merge but I think this will work nicely.

[njsmith]

I am excited about getting rid of dependabot spam!

I think that we'll need to switch to using a personal access token to create the PR, because otherwise Github will refuse to run CI on the PR: peter-evans/create-pull-request#48

One subtle quirk of this is that we have to manually delete branches after they've been merged.

I just flipped this setting on, which I think should take care of it?

[richardsheridan]

I am excited about getting rid of dependabot spam!

I think that we'll need to switch to using a personal access token to create the PR, because otherwise Github will refuse to run CI on the PR: peter-evans/create-pull-request#48

I think I did know this at some point... can you help me make that token? I think it requires admin access

One subtle quirk of this is that we have to manually delete branches after they've been merged.

I just flipped this setting on, which I think should take care of it?

Nice!

[A5rocks]

I am excited about getting rid of dependabot spam!

I think that we'll need to switch to using a personal access token to create the PR, because otherwise Github will refuse to run CI on the PR: peter-evans/create-pull-request#48

I think I did know this at some point... can you help me make that token? I think it requires admin access

I found this just now and it seems useful; here's a list of what we could do: https://github.com/peter-evans/create-pull-request/blob/main/docs/concepts-guidelines.md#workarounds-to-trigger-further-workflow-runs

Choice options:

• close/reopen the PRs ;-)
• SSH "deploy keys" (we run the actions on push assuming the branch is on this repository, I believe?)
• Personal Access Tokens (on a machine account?)
• ... It seems we can just use the existing trio bot to make a token for maximum coolness? But that might leak secrets somehow which would suck.

[A5rocks]

Hi! Just coming back here to bump this PR again. I wouldn't mind having to close/reopen our automated PRs if necessary, if we can't decide on what to do.

[richardsheridan]

Right, you can merge it today and it should work just like that. In the future, someone with admin privileges can create an appropriately scoped personal token as in #2594 (comment) and simply make a PR to change the GH_TOKEN argument in the workflow to point to it and it should become fully automatic.

[njsmith]

Unfortunately, I think if we put a PAT in as a secret on this repo, then that can be trivially extracted by anyone with commit privileges and then used to impersonate the original person, right?

…

On Tue, Apr 4, 2023, 16:06 richardsheridan ***@***.***> wrote: Right, you can merge it today and it should work just like that. In the future, someone with admin privileges can create an appropriately scoped personal token as in #2594 (comment) <#2594 (comment)> and simply make a PR to change the GH_TOKEN argument in the workflow to point to it and it should become fully automatic. — Reply to this email directly, view it on GitHub <#2592 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEU42CIUODD44PYP6ID5TDW7SSOFANCNFSM6AAAAAAVQHWMAY> . You are receiving this because you commented.Message ID: ***@***.***>

[A5rocks]

I haven't wrapped my head around how secrets function in GitHub Actions (yet) but that certainly sounds right. I'd suggest some sort of machine account? The account making the PRs needs no permissions at all, after all. It could always make a PR from a fork (though that would complicate things).

I'll merge this now (assuming no immediate "no"s) cause there's a fix no matter how cludgey and we can figure out how to do this at a future point.