The number of Github repositories that I end up maintaining in one way or another ends up growing week by week. And keeping all of the descriptions and settings up to date in sync can be painful todo by hand.
A little while ago I migrated my addwiki project to use a monorepo, and thus needed to bulk update all of the github repository descriptions. While doing so I made use of the github cli and created a single bash script to let me configure all of the repositories at once.
Assuming you already have the github cli install and configured getting started with this is easy.
The below command is one of many in my bash script for repo configuration. This sets a description, homepage and various other flags that I want to be consistent across repositories.
gh api --method PATCH repos/addwiki/addwiki \
--field description='Monorepo containing all addwiki libraries, packages and applications'\
Github provided some advice for renaming branches focused around how this can be done in the UI. But with the Github CLI tool that was also release at the end of 2020 you can programatically make this change too.
The Github CLI tool is called gh. The README for the tool has installation instructions for a variety of platforms. One of the commands that it enables is called api, which can be used to “Make an authenticated GitHub API request”.
The Github API obviously allows you to perform most actions that can be performed by the UI, this we can use the gh cli tool to rename the branches of repositories.
For example, for the addwiki/addwiki repository, we can rename the master to main branch using the following command:
gh api --method POST repos/addwiki/addwiki/branches/master/rename --field new_name='main'
And you can use such a command in whatever loops etc you want to, to quickly rename a whole bunch of branches in a whole bunch of repositories.
Open Sourcing the code and config for WBStack has always been part of the plan, although functionality came first throughout the first year or so. Finally there is a github organization for wbstack containing 16 public repositories that make up the entire deployment for wbstack.com.
This effort took a few weeks trying to split sensible components out of the original mono repo that was started back in 2017 that now has over 1600 commits, making sure that no secrets were swept up along the way, and also trying to preserve git history where possible.
Although everything is now on Github that doesn’t mean that it is clearly understandable just yet, or in the most sensible layout, that will come with time.
I was looking for a new tool for easily visualizing git branches and workflows to try and visually show how Gerrit works (in terms of git basics) to clear up some confusions. I spent a short while reading stackoverflow, although most of the suggestions weren’t really any good as I didn’t want to visualize a real repository, but a fake set of hypothetical branches and commits.
I was suggested Graphviz by a friend, and quickly found webgraphviz.com which was going in the right direction, but this would require me to learn how to write DOT graph files.
GitHub tracks the number of downloads for all assets (files) that are attached to a release, but GitHub currently makes it very hard for users to get at this information. The number of downloads is currently only accessible through the API.
I noticed this many months ago when wondering how many people were downloading the new C++ version of Huggle. At the time I started coming up with some odd little script that I could set running somewhere checking the download counts and updating a static list, I even thought about just uploading the build files to some other site that tracked this information.
A few days ago I took my first look at developing chrome extensions for a referencing tool for Wikidata, and thus today I thought, why not just make an extension for chrome that adds the download counts to the GitHub releases page!