Instead, I’ll be sharing some of the general concepts. In other words, it’s clunky, so I won’t be copying the entire solution here. To be honest, I’m not super proud of the Python solution as it’s very much a quick and dirty solution. Of course, that’s not very exciting on its own, so we added data columns like the number of snippets per language as well as links to the open issues and the various articles. In other words, the wiki structure would almost mirror the directory structure exactly. From there, each letter page would contain a list of the languages for that letter. The alphabetical list would contain at least the links to the 26 letter pages. In their design, the wiki was composed of 27 pages: 1 alphabetical list and 26 letter pages. In general, I just wanted to clone what already existed thanks to Alcha, one of our contributors. With the directory structure in mind, all we had to do was determine what we wanted our wiki to look like, so we knew what data to collect.
GITHUB WIKI TAB HOW TO
Next, we’ll take a look at the wiki plan, so we can figure out how to connect the dots. In each language folder, there’s a set of scripts as well as a README file and occasionally a Dockerfile. Under each letter folder, we’ll find a list of language folders which share the same first letter. Or if it makes more sense, here’s a cross-section of the collection: archiveĪs you can see, the archive folder contains 26 folders-one for each letter of the alphabet. The typical trajectory through the repo from the top layer to the script looks as follows: Top -> archive -> -> -> Directory StructureĬurrently, all code snippets sit several layers deep in the repo. In order to understand how the Python Script works, we’ll have to get an understanding of the directory structure of the Sample Programs repo. In other words, we never have to touch the wiki again.Īt this point, let’s get into the details a bit. Once we had the script, we used a continuous integration tool called Travis CI to trigger a fresh build of the wiki every time a commit is made to master. In other words, the Python script only generates the wiki files. Scripting alone isn’t enough to automate the solution as far as I can tell. In terms of scripting, we used a Python script to gather data about our repository and generate a wiki in Markdown. In general, our solution to automating the wiki came in two parts: scripting and continuous integration. That said, the following article details how we implemented the solution, and you’re free to do the same.
GITHUB WIKI TAB UPDATE
In fact, I may have mentioned in the update that we considered a few alternatives.
As a word of caution, the following solution provided in this article is by no means the standard or de facto solution to automating a GitHub wiki.
0 kommentar(er)
