This blog series focuses on presenting complex DevOps projects as simple and approachable via plain language and lots of pictures. You can do it!
I’m migrating my current business from an internal BitBucket server to public GitHub. The migration has mostly been very exciting — GitHub is cutting edge, and the security and scalability features that GitHub makes available are a huge enabler for our velocity.
That’s not to say things are perfect — there are some functionality of BitBucket that is managed as metadata (like default reviewers on PRs), and can therefore be easily updated at scale, that GitHub manages with files that are committed to the repo directly.
The big ones are:
- CODEOWNERS file assigning different paths to teams who are auto-assigned as reviewers
- Actions files to run specific actions in repos
The short of it is — sometimes you need to make changes to A LOT of repos at a time. Like, say you need to make a change in every single repo you have in github, and you have 300. Well, that’s going to take a super long time.
So I wrote a tool for that. This tool iterates over every repo in an Org (or User space) and makes changes, then adds those changes to a git branch, pushes the branch, opens a PR, and optionally force-closes the PR with admin permissions. ✨It’s magic! ✨
Let’s look at it. ❤ And if you only care about downloading the code to run it, scroll to the end for a link to the repo!
We’ll need to do two different authentication methods to GitHub. First, we need a control-channel authentication to download the names of all the GitHub repos in your Org, as well as some metadata like the default branch in each repo.
For GitHub, this is usually a PAT, or Personal Access Token. Instructions for how to create one are at the link here ^^, and once you have it export it into your terminal as variable
GITHUB_TOKEN. The script will check to make sure that var is populated, and if not, it’ll exit with an error message.