Separate Bot User GitHub Tokens from regro GitHub Tokens

[ytausch]

Description:

Our proposed integration tests for #261 need to interact with the GitHub API with multiple different identities in a staging environment. Since nowadays, fine-grained personal access tokens are recommended by GitHub whenever possible, they clearly separate access to different GitHub users/organizations.

This means the bot needs to support using different access tokens depending on which GitHub user/org it is interacting with. This PR contributes the necessary changes.

Essentially, BOT_TOKEN can now be filled with a fine-grained access token for regro-cf-autotick-bot and REGRO_TOKEN with a fine-grained token for regro.

Note that these changes do not prevent from continuing to run the bot with a classic access token in production.

I carefully reviewed the source code to verify that the correct tokens are available and used everywhere. It would be helpful if you, @beckermr, could double-check.

I leave it up to you if you also want to update the production tokens to fine-grained tokens together with these changes. It involves more risk of breaking the bot but would ensure that future source code changes correctly differentiate between the two tokens. We can also wait for the integration tests to have more assurance here.

@pavelzw

Checklist:

• Pydantic model updated or no update needed

Cross-refs, links to issues, etc:

[ytausch]

I removed BOT_TOKEN for install_bot_code.sh entirely everywhere because I could not find where it uses the token.

[ytausch]

Explanation: This only pushes to cf-graph so the permissions for regro are sufficient

[codecov]

Codecov Report

Attention: Patch coverage is 38.77551% with 30 lines in your changes missing coverage. Please review.

Project coverage is 76.40%. Comparing base (4ba3b0b) to head (2ca2b70).
Report is 39 commits behind head on main.

Files with missing lines	Patch %	Lines
conda_forge_tick/git_utils.py	27.27%	16 Missing ⚠️
tests/conftest.py	0.00%	7 Missing ⚠️
conda_forge_tick/events/push_events.py	0.00%	2 Missing ⚠️
conda_forge_tick/lazy_json_backends.py	0.00%	2 Missing ⚠️
tests/test_lazy_json_backends.py	33.33%	2 Missing ⚠️
conda_forge_tick/all_feedstocks.py	50.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3326      +/-   ##
==========================================
- Coverage   76.42%   76.40%   -0.03%     
==========================================
  Files         130      130              
  Lines       14234    14255      +21     
==========================================
+ Hits        10879    10891      +12     
- Misses       3355     3364       +9     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[beckermr]

I don't follow the need for this change. I thought the plan was to put testing feedstocks in the regro org directly and let the bot fork them, in which case we can use one token and things are a lot simpler.

[ytausch]

I don't follow the need for this change. I thought the plan was to put testing feedstocks in the regro org directly and let the bot fork them, in which case we can use one token and things are a lot simpler.

I know we talked about this already so sorry if I confused you.

The test environment needs three things:

1. A copy of cf-graph-countyfair which is not the real one.
2. A bot user account which is not the real bot user account.
3. A GitHub org containing the mock feedstocks.

It is possible to put the mock cf-graph (1) in regro if the permissions are restricted correctly.

Mock feedstocks or forks thereof (2/3) should not be put in regro or any other existing org: The test setup needs permission to create and delete arbitrary repositories for the owners of the feedstocks and forks. The test setup should not be able to delete production resources such as cf-graph.

Even if the mock graph is put into regro, 2 and 3 require that there is a separation between actions on the bot user account and regro.

[beckermr]

It seems a lot easier to start with something simpler. Making and then deleting repos for running the tests is slow and error prone. We can post some notes on how to set things up and do most of it by hand.

[ytausch]

It seems a lot easier to start with something simpler. Making and then deleting repos for running the tests is slow and error prone. We can post some notes on how to set things up and do most of it by hand.

Automatic test environment creation is already implemented. And it's surely not a bad thing that testing is as much automated as possible. Did not see that anything is slow or raises errors. So I'd appreciate if this PR moves forward.

[ytausch]

Converting to draft because a GitHub app could solve this issue in another way.

[ytausch]

We decided to use a classic PAT for now, although GitHub discourages their usage, making this PR redundant. There are reasons though why we want to migrate the bot to use GitHub app authentication eventually.
Let's discuss the exact distribution of repositories separately! Happy to set up a call or use the next bot sync for that. I will reach out to you as soon as we have something to show.

[beckermr]

The bot cannot fully use a GitHub app due to GitHub apps not being able to fork feedstocks. We manage a mix of apps and machine users on conda-forge and it is a pain. The only reason we do it there is for the increased api request limits. If we do not need those limits here, then the complexity is not worth it.

[ytausch]

I double-checked and found that GitHub apps indeed can't be used to fork repositories into a user account, but I could successfully fork into an organization if the app is installed in an organization. It requires the original repo to be public, but this should not be a concern for us. Nothing should speak against cf-regro-autotick-bot being an organization, right?

I agree that the increased rate limits are the main reason why we should consider using a GitHub app.

[beckermr]

The bot is going to remain a machine user and not be changed to an org.