feat: detect untracked repo

[amustaque97]

Closes: #1863

[github-actions]

Dry-run check results

[WARN  sync_team] sync-team is running in dry mode, no changes will be applied.
[INFO  sync_team] synchronizing crates-io
[INFO  sync_team] synchronizing github

[amustaque97]

I have resolved all the comments, synced with the latest main branch and squashed commits. PR is ready for review 🙌🏻

[Kobzol]

I'm kinda confused why does this needs any permissions at all? We can just read the publicly available list of repositories without any GitHub token, right? I don't think that we need to even read private repositories; in fact this action could leak the existence of said repositories when it runs on CI (sometimes private repos can be created manually, I think, e.g. for security responses, I don't even think that team currently tracks all private repositories).

That would also allow this CI workflow run completely unprivileged, which would be better in general.

By the way, this will probably fail (at least) for the gll repository, which is still untracked.

[amustaque97]

I'm kinda confused why does this needs any permissions at all? We can just read the publicly available list of repositories without any GitHub token, right? I don't think that we need to even read private repositories; in fact this action could leak the existence of said repositories when it runs on CI (sometimes private repos can be created manually, I think, e.g. for security responses, I don't even think that team currently tracks all private repositories).

That would also allow this CI workflow run completely unprivileged, which would be better in general.

By the way, this will probably fail (at least) for the gll repository, which is still untracked.

Interesting, thank you for saving us from a leak. I never realised until now that we only manage public repos using team repos. I'm glad we found it soon. I have refactored the code to use the public api.

Can you please take a second look?

[Kobzol]

It looks great, thank you!

We should eventually just switch to octocrab for the simple stuff, or at least unify the team and sync-team GitHub APIs, it's annoying to reimplement the same GitHub endpoints again and again :D

[Kobzol]

I don't think we need to skip archived repositories, we should also have those in team.

[Kobzol]

Opened #2180 to unblock this.

[marcoieni]

It looks great, thank you!

We should eventually just switch to octocrab for the simple stuff, or at least unify the team and sync-team GitHub APIs, it's annoying to reimplement the same GitHub endpoints again and again :D

Let's create our own common crate and not depend on octocrab, so that:

• we have full control of the http client and we can implement better error handling, retries, etc
• we minimize dependencies

At least this is my preference. Because for example we might want to use graphql for certain calls.

We could create a common crate later as a separate issue

[Kobzol]

So, I agree that we should definitely have our own interface (and use that in both team and sync-team). But inside that interface, we can just offload the simpler things to octocrab, even using the same shared HTTP client. The beauty of octocrab is that it allows you to do even fully custom REST API calls, and even GraphQL calls (we do that in bors), using the same authenticated client. So you can use octocrab's code for the simple stuff, but then still do more advanced stuff manually. And you can also reuse (but also easily extend!) its serde types for GitHub REST API datatypes. It's a win-win, IMO.

[marcoieni]

Can you customize it with middlewares? E.g. retry automatically on every 500?

[Kobzol]

I think that you can configure it using any tower middleware (e.g. https://docs.rs/octocrab/latest/octocrab/struct.OctocrabBuilder.html#method.with_service). I'll try it.

EDIT: I forgot that octocrab is async. That's not worth the rewrite, IMO. Nevermind.