Guten Tag!

Many greetings from Munich, Germany. Last week, we got started with GitHub Actions. This week, I want to show you how to set up secrets for your repository’s actions workflow. We’ll use this to publish our cool readme file not only to GitHub but also to Netlify.

Also, we’ll automate this action so that it runs on a schedule (e.g. every 10 minutes) rather than on push. Thus, this will be a jam-packed newsletter again. So lets dive in.

Publishing to Netlify

First, we need publish our Quarto file to Netlify using our local repository. That way, we can set everything up once and then only automate updates. Inside our RStudio project, in the terminal, run:

This will ask you where you want to publish. Select Netlify and follow the steps to sign up for Netlify if you don’t have an account (I always use my GitHub account for this).

Authenticate with Netlify

Notice how we had to authenticate to actually publish the rendered document? Here, we did that interactively via our browser. But when quarto publish is run by GitHub we don’t have the option to authenticate with our browser.

Hence, we need to come up with another way to tell Netlify that it’s really okay to publish the new document. And to do so, we can generate an authentication token on Netlify.

Now, let me stress here that this isn’t Netlify’s invention. Many services allow you to generate a token as an alternative way to authenticate. Anyway, on Netlify you can generate that token here:

This should give you a token like this:

Here I’m showing you the token because I will delete it immediately after having taken this screenshot. This is important! I don’t want to share my secrets with you. They’re mine and mine alone! Mwahahahaha.

Okay I’m getting distracted here. My point is: These authentication tokens are seriously confidential. We don’t want to show them to others. So we have to find a way to tell GitHub about it without writing it into the YAML file where anyone could potentially read it. That’s where the secrets store come into play.

Storing the Token as a Secret

For every repository, you can define environment variables aka secrets. To do so, you have to follow these steps here:

1. Go to Settings

2. Select Secrets and variables

3. Specify a new repository secret

4. Name it something good like NETLIFY_AUTH_TOKEN

Updating the Actions YAML File

Cool! With that we told GitHub our dirty little secret. (Sorry about these dumb secret puns. I can’t stop myself.) Now it’s time to add the quarto publish command to our YAML file. This will look like this:

But if we leave it like that, then the automatic authentication via the NETLIFY_AUTH_TOKEN won’t work. We have to tell the step to use the secrets.NETLIFY_AUTH_TOKEN environment variable. That’s the one we’ve just put into out secrets store.

Had we named that token MY_SECRET, then we’d have to tell the action to use secrets.MY_SECRET. But that wouldn’t be really informative so that’s why it makes sense to name the secret meaningfully (like we did).

Anyway, the quarto publish command expects an environment variable called NETLIFY_AUTH_TOKEN. “How do I know that”, you ask? Well, the docs say so:

So we define our action step to have such an environment variable and we fill it with secrets.NETLIFY_AUTH_TOKEN using ${{ }}

Nice, so once you push these changes to your repository, you’ll see that your published document on Netlify updated.

Running on a Schedule

Sweet, our action can now publish to Netlify. And with that we have unlocked a skill that lets us use all kinds of other services (as long as they let us authenticate via a token.) But I’ve also promised you a scheduling tool.

Well, to run your action on a particular schedule, all you have to do is modify the on argument of the action. Let’s check out how that looks and then I’ll explain the weird syntax.

Here, we use the cron tool to run on a schedule. It’s a popular tool to schedule events on Unix systems. To define a schedule all you need is 5 asterisks separated by white spaces, i.e. "* * * * *".

Here, the translation of each asterisk is perhaps best summarized by the following image from the Linux Handbook:

Now, whenever you want to say “every”, then you just leave the asterisk. So, "* * * * *" runs the job every minute of every hour of every day of the month… you get the idea. Similarly, "5 14 * * *" runs the job at the 5th minute of the 14th hour of every day of the month and so on.

Thus, it’s possible to give really precise instructions on when a job is supposed to run. But what about when we want to specify a frequency like “every 10 minutes”?

Well, in that case we can say something along the lines of “run the job at every minute that is divisible by 10”. In this particular example, this is denoted as "*/10 * * * *".

And that is exactly what we’ve put into our YAML file. Thus, once you push these changes, the workflow will be triggered again (as we still have the push trigger.) But you’ll also notice that 10 minutes later, the next iteration of your GitHub Action will start. Hooray!

With this, we have learned how to store secrets for GitHub Actions and how to publish Quarto files to other services like Netlify on a schedule. As always, if you have any questions, or just want to reach out, feel free to contact me by replying to this mail or finding me on Linkedin.

See you next week,
Albert 👋

Enjoyed this newsletter? Here are other ways I can help you:

• My playlist on YouTube

• Free book: Yet Again - R + Data Science

• Free book: Beautiful tables with {gt}

• Blog posts