Hugo, Google Cloud Build & Firebase
When I originally moved my blog away from Tumblr, I followed the below pages:
- the Hugo folks’ guide to deploying on Firebase
- this helpful blog post by Robert Sahlin
- GCP notes on encrypting deployment tokens with KMS.
In short, this blog is:
- maintained in a Github repository
- deployed with Google Cloud Build
- hosted in Firebase.
This got me almost all of the way there. I encountered the below traps:
- Git submodules
- failing to add
public/[a-z]*
to.gitignore
and.gcloudignore
submodules
When initiating builds, GCP did not seem to clone the submodules referenced in the Git repository containing this Hugo blog. The Hugo theme I use is imported via a submodule. The result was that the Hugo build step would appear to succeed but no HTML content would be generated, and a bunch of 404s would ensue. Not ideal!
I addressed this by adding a submodules step to my cloudbuild.yaml
, and making Hugo
wait for it:
steps:
- id: 'submodules'
name: 'gcr.io/cloud-builders/git'
entrypoint: 'bash'
args:
- '-c'
- |
git submodule init
git submodule update
- id: 'hugo'
name: 'gcr.io/$PROJECT_ID/hugo'
waitFor: ['submodules']
public directory content
While messing about with cloudbuild.yaml
I submitted a bunch of builds via
the commandline. I noticed that I’d accidentally committed the contents of a
locally-rendered public
directory. I fixed that and added it to .gitignore
.
# hugo
public/[a-z]*
This is not the whole story, however. When builds are submitted via
commandline, eg. with gcloud builds submit --config=cloudbuild.yaml .
, the
current directory is copied into the build context, so it’s theoretically
possible for content in public/
that was rendered locally (eg. with hugo
server
) to be inadvertently published. Not good. To fix this, I created
a .gcloudignore
file.
Conveniently, these support referencing another file, so I simply told it to
include my entire .gitignore
file (and itself):
.gcloudignore
#!include:.gitignore
When I looked at it, Google’s example included .git
in the ignore list. This
broke the Git submodule initialisation step described above, so I removed it
and all was fine after that.
wrapup
With these two issues sorted, I feel a lot happier about my workflow. I can now author with Hugo locally and push to Github with confidence that I won’t break my blog quite as easily.