DEV Community

Adam.S
Adam.S

Posted on • Edited on • Originally published at bas-man.dev

1

Publish your next Hugo blog post automatically using Github Actions

The Challenge

I wanted to be able to publish a new post that has already been written at a future date, without needing to manaully publish the article.

The Solution

Github Actions.

I already push updates to my site using github actions. So I thought why not have articles published in the future after they are written.

A little background. I do all my edits in a private GitHub repo. When I push to master in this repo. A workflow action is triggered that causes my live site to be updated. The automatic merge that this system creates, results in my live site being updated without my taking further actions. You can find my post on this here

How I implemented this:

I added the file publish.yml to my .github/workflows folder.

Note:
cron runs based on UTC time. So you will need to take that into account when you define your cron job's time.

If you need some help understanding the crontab format. I would refer you to crontab.guru

name: Publish Future Article
on:
  schedule:
    - cron: '30 0 8 8 *' # Publish at 00:30 on August 8th UTC time.


jobs:
  createPullRequest:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: site-update

      # Required to make this commit ahead of the actual push
      - name: Make changes to pull request
        run: date +%s > lastAutoUpdate.txt

      - name: Create Pull Request
        uses: peter-evans/create-pull-request@v3.1.0
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          commit-message: Ready to publish
          committer: GitHub <noreply@github.com>
          author: ${{ github.actor }} <${{ github.actor }}@users.noreply.github.com>
          signoff: false
          base: master
          branch: PublishArticle
          title: 'PublishNewArticle'
          body: |
            Testing to publish a new article.
          labels: |
            automerge

Enter fullscreen mode Exit fullscreen mode

This published my new article at 00:30 on August 8th UTC.

Note:

  1. ref: site-update tells the action which branch to copy to generate the pull request.
  2. base: master tells the action which branch the pull request should be merged into.
  3. branch: PublishArticle the new temporary branch that the pull request will create. It will be deleted by the auto merge action listed below.
  4. The automerge label is needed to trigger the next action script that follows.

The next thing to do is to create an action that will actually merge this new pull request.

I created a file again in the .github/workflows called automerge.yml.

This file contains:

name: automerge
on:
  pull_request:
    types:
      - opened
  status: {}
jobs:
  automerge:
    runs-on: ubuntu-latest
    steps:
      - name: Merge pull requests
        uses: pascalgn/automerge-action@v0.9.0
        env:
          GITHUB_TOKEN: "${{ secrets.GITHUB_TOKEN }}"
          MERGE_DELETE_BRANCH: true

Enter fullscreen mode Exit fullscreen mode

I think this whole workflow could be improved to add more useful information to the generated pull_request. Something to consider.

In order to use these actions in the current form. You will need to edit the cron: time each time you want to have an article published in the future. Also note that cron does not support year. So if you leave this cron in place. It will run at the same time each year.

If anyone has any better options. I would be happy to hear about them.

DevCycle image

Ship Faster, Stay Flexible.

DevCycle is the first feature flag platform with OpenFeature built-in to every open source SDK, designed to help developers ship faster while avoiding vendor-lock in.

Start shipping

Top comments (0)

Tiger Data image

🐯 🚀 Timescale is now TigerData: Building the Modern PostgreSQL for the Analytical and Agentic Era

We’ve quietly evolved from a time-series database into the modern PostgreSQL for today’s and tomorrow’s computing, built for performance, scale, and the agentic future.

So we’re changing our name: from Timescale to TigerData. Not to change who we are, but to reflect who we’ve become. TigerData is bold, fast, and built to power the next era of software.

Read more

👋 Kindness is contagious

Explore this insightful write-up, celebrated by our thriving DEV Community. Developers everywhere are invited to contribute and elevate our shared expertise.

A simple "thank you" can brighten someone’s day—leave your appreciation in the comments!

On DEV, knowledge-sharing fuels our progress and strengthens our community ties. Found this useful? A quick thank you to the author makes all the difference.

Okay