[BUG] Fix eventual consistency of repository create API

[deiga]

Supersedes #3034

Resolves #2604

Probably also resolves the following issues:
Resolves #897
Resolves #577
Resolves #2655
Resolves #2700
Resolves #2766

---

Before the change?

• Repository creation can be flaky, since the API endpoint doesn't wait for repo creation
• Repository sweeper didn't actually work

After the change?

• Repository creation waits for up to 2 minutes before trying to modify any parts of the repository to ensure that it exists
• Some test repo names have been aligned to enable sweeper
• Added make target for sweep

Pull request checklist

• Schema migrations have been created if needed (example)
• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

• Yes
• No

---

[github-actions]

👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labeled with Status: Up for grabs. You & others like you are the reason all of this works! So thank you & happy coding! 🚀

[stevehipwell]

@deiga is this specifically to fix the template create issues? If so then I could get behind waiting for the repo for that specific case, but I 100% wouldn't want additional API calls when creating a new repo from scratch.

The initial fix for issues like this should be to remove the call to read after create/update pattern and to separate resources out that use multiple different API endpoints.

[deiga]

@stevehipwell This is to fix ANY interaction with the repository after it's been created. We have a bunch of bug reports about flakyness around repo creation and I assume it's because of https://github.com/google/go-github/blob/v81.0.0/github/repos.go#L528-L531

We could of course add a boolean field to allow users to toggle the wait if you think that makes sense

[stevehipwell]

@deiga we should do all of the other fixes before even considering increasing the API load.

For example I regularly create 100s of repos from a template repo via TF and I've not had any eventual consistency failures since the last bit of reworking (well over a year ago). I would question the validity of the current reports and suggest we work from first principles once the current code has been correctly optimised.

[deiga]

Yeah, the API impact I didn't consider. This would add 1-2 API calls which user up Rate per repo creation (max 2, since EtagTransport should ensure that after first empty response further empty responses don't use rate)

Maybe we could add the optional default false flag to enable this waiting to give the bug reports a way to try if that helps?

[stevehipwell]

Yeah, the API impact I didn't consider. This would add 1-2 API calls which user up Rate per repo creation (max 2, since EtagTransport should ensure that after first empty response further empty responses don't use rate)

I'm not 100% sure this even works at the moment. For v7 we should investigate using bored-engineer/github-conditional-http-transport so we don't need to explicitly manage etags at the resource level.

Maybe we could add the optional default false flag to enable this waiting to give the bug reports a way to try if that helps?

I really would leave this for now as a premature optimisation and focus on getting the resource into a better shape. The current create path not only uses multiple API calls in the create function, but it also calls update and read; this should be fixed before anything else is done. While we're at it we can figure out which functionality need to be moved into its own resource (e.g. vulnerabilities & pages).