Continuously Building and Hosting our Swift DocC Documentation using Github Actions and Netlify
Rate this tutorial
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.
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.
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.
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.
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.
As shown in this by , 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).
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!