Continuously Building and Hosting our Swift DocC Documentation using Github Actions and Netlify
Rate this tutorial
of this series, we showed how easy it was to generate documentation for our frameworks and libraries using DocC and the benefits of doing it. We also saw the different content we can add, like articles, how-tos, and references for our functions, classes, and structs.
But once generated, you end up with an archived DocC folder that is not that easy to share. You can compress it, email it, put it somewhere in the cloud so it can be downloaded, but this is not what we want. We want:
- Automatic (and continuous) generation of our DocC documentation bundle.
- Automatic (and continuous) posting of that documentation to the web, so it can be read online.
.doccarchivearchive is, like many other things in macOS, a folder.
and look inside
BinaryTree.doccarchivefrom a terminal.
This is a single-page web application. Sadly, we can’t just open
index.htmland expect it to render correctly. As
, for this to work, it has to be served from a proper web server, with a few
To host a documentation archive on your website, do the following:
- Copy the documentation archive to the directory that your web server uses to serve files. In this example, the documentation archive is SlothCreator.doccarchive.
- Add a rule on the server to rewrite incoming URLs that begin with /documentation or /tutorial to SlothCreator.doccarchive/index.html.
- Add another rule for incoming requests to support bundled resources in the documentation archive, such as CSS files and image assets.
They even add a sample configuration to use with the Apache
httpdserver. So, to recap:
- We can manually generate our documentation and upload it to a web server.
- We need to add the rewrite rules described in Apple’s documentation for the DocC bundle to work properly.
Each time we update our documentation, we need to generate it and upload it. Let’s generate our docs automatically.
We’ll continue using our
as an example to generate the documentation. We’ll add a GitHub Action to generate docs on each new push to main. This way, we can automatically refresh our documentation with the latest changes introduced in our library.
To add the action, we’ll click on the
Actionsbutton in our repo. In this case, a Swift Action is offered as a template to start. We’ll choose that one:
After clicking on
Configure, we can start tweaking our action. A GitHub action is just a set of steps that GitHub runs in a container for us. There are predefined steps, or we can just write commands that will work in our local terminal. What we need to do is:
- Get the latest version of our code.
- Build out our documentation archive.
- Find where the
doccarchivehas been generated.
- Copy that archive to a place where it can be served online.
We’ll call our action
docc.yml. GitHub actions are YAML files,
. After adding them to our repository, they will be stored in
.github/workflows/. So, they’re just text files we can edit locally and push to our repo.
This is the easy part. Every time a Github action starts, it creates a new, empty container and clones our repo. So, our code is there, ready to be compiled, pass all tests, and does everything we need to do with it.
Our action starts with:
- We gave the action the name “Generate DocC”.
- Then we select when it’ll run, i.e., on any pushes to
- We run this on a macOS container, as we need Xcode.
- The first step is to clone our repo. We use a predefined action,
checkout, that GitHub provides us with.
Now that our code is in place, we can use
xcodebuildto build the DocC archive. We can
, run our tests, or in this case, build the documentation.
Here we’re building to generate DocC (
docbuildparameter), choosing the
BinaryTreescheme in our project, putting all generated binaries in a folder at hand (
docbuild), and using an iPhone 13 mini as Simulator. When we build our documentation, we need to compile our library too. That’s why we need to choose the Simulator (or device) used for building.
If everything goes well, we’ll have our documentation built inside
docbuild. We’ll search for it, as each build will generate a different hash to store the results of our build. And this is, on each run, a clean machine. To find the archive, we use:
Now that we know where our DocC archive is, it’s time to put it in a different repository. The idea is we’ll have one repository for our code and one for our generated DocC bundle. Netlify will read from this second repository and host it online.
So, we clone the repository that will hold our documentation with:
So, yes, now we have two repositories, one cloned at the start of the action and now this one that holds only the documentation. We copy over the newly generated DocC archive:
And we commit all changes:
$DOC_COMMIT_MESSAGEis just a variable we populate with the last commit message from our repo and current date. But it can be any message.
After this, we need to push the changes to the documentation repository.
Here we first print our
origin(the repo where we’ll be pushing our changes) with
This command will show the origin of a git repository. It will print the URL of our code repository. But this is not where we want to push. We want to push to the documentation repository. So, we set the origin pointing to
. As we will need permission to push changes, we authenticate using a Personal Access Token. From
You should create a personal access token to use in place of a password with the command line or with the API.
Luckily, Github Actions
, so they’re publicly accessible. Just go to your repository’s Settings and expand Secrets. You’ll see an “Actions” option. There you can give your secret a name to be used later in your actions.
As shown in this
, we'll be hosting our documentation in
. Creating a free account is super easy. In this case, I advise you to use your Github credentials to log in Netlify. This way, adding a new site that reads from a Github repo will be super easy. Just add a new site and select Import an existing project. You can then choose Github, and once authorized, you’ll be able to select one of your repositories.
Now I set it to deploy with “Any pull request against your production branch / branch deploy branches.” So, every time your repo changes, Netlify will pick up the change and host it online (if it’s a web app, that is).
But we’re missing just one detail. Remember I mentioned before that we need to add some rewrite rules to our hosted documentation? We’ll add those in a file called
. This file looks like:
To use it in your projects, just review the lines:
And change them accordingly.
In this post, we’ve seen how to:
Don’t wait and add continuous generation of your library’s documentation to your CI pipeline!
Build a Command Line Tool with Swift and MongoDBBuild a Command Line Tool with Swift and MongoDB
Feb 17, 2022