How to use Issues on a Private Github repo as a Public Microblog
GitHub Issues on a private repository is the perfect microblogging platform. No one can comment or react to your posts but you still share your fleeting thoughts with the public world through your website.
The set up –
- A Hugo-powered website
- A remote virtual private server (DigitalOcean Droplet)
- A private GitHub repository for tracking the website’s source code
- A GitHub Issue thread on the same repository
The result –
- See the stream of consciousness microblog on this website.
Here’s how I connect the wires to make a private Issues thread publicly available on my VPS.
Giving the VPS access to the private GitHub repository
First, we need to give the VPS access to the GitHub repository so that it can –
- Pull the changes on a new commit
- Run
hugo
to build the site afresh - Serve the freshly brewed website to the Internet (I am assuming this is already happening for you using NGINX/Apache)
Create a new SSH key pair on the VPS
|
|
Add the public key to the private GitHub repo
Your public key will be stored at /home/YOU/.ssh/hugo_website_git_deploy_bot.pub
. It will look something like this:
ssh-ed25519 AAAA-S0M3OTH3RL3TT3R$ANDNUMB3RS <the_email_you_gave_when_generating_the_key>
Copy this key.
- Go to
Settings
on your GitHub repo and click onDeploy keys
- Add a new key. Give it a recognisable title like “VPS Site Deploy key”.
- Paste the public key.
Tell your SSH agent to default to this key when connecting to GitHub
Add these lines to the config
file in ~/.ssh
:
|
|
Run nano ~/.ssh/config
if the file doesn’t already exist. Make sure to save it.
Test that the connection works
Run ssh -T git@github.com
and you’ll get a positive response from GitHub acknowledging your GitHub username and repo.
Using webhooks to let the VPS know of new commits
Next, we need to create a webhook in the GitHub repository settings. This webhook will ping a URL which will tell our server that a new commit has occurred in the repository.
Get an API up and running
I have an existing API set up using FastAPI. I added the following function in my API code to speak to the webhook:
|
|
Set up the webhook config on GitHub
Go to Settings > Webhooks
in your GitHub repository.
Create a new webhook. Tell it to ping your API URL (https://yourapi.com/api/path/new_commit)
. Check the Just the push event.
option because you don’t need any other details for this to work.
Now whenever there is a new commit on the GitHub repository, this API path receives a POST request from the GitHub servers which in turn triggers the deploy.sh
script on your VPS.
Running a deploy script on the VPS
Before you create the deploy script, create a new folder on your VPS where you will clone the Git repo:
|
|
Create a new script in your API folder and call it deploy.sh
:
|
|
When interacting with your VPS in the Terminal, run echo $PATH
to get your current path. Paste this in the script above.
After creating the script run sudo chmod +x deploy.sh
to make the script executable.
Test the script by running it (./deploy.sh
) and check the log files.
Test the deploy script using the webhook
Make a new commit to your GitHub repo. Go to Settings > Webhooks
and check whether the webhook was successfully delivered or not.
If it was successful, the deploy script should have run on your VPS and the log files would have updated. And most importantly, the latest changes from your repo would have been pulled to your VPS and the site built afresh by hugo
.
Celebrate
You’ve done well. Now you can simply update your website using the GitHub mobile app or a web browser. And your site will automatically be redeployed to the public Internet thanks to your server.
Using Issues as a Microblog
Create a dedicated microblog page on your Hugo website
I use stream.md
on my site:
|
|
The stream
shortcode looks like this:
|
|
If you want your microblog to show your posts in reverse chronological order, you need to follow an extra step. Reverse chronological is the better way because it allows you to paginate the posts in future.
Create a static file that contains your stream.md
file’s frontmatter and any other opening notes. Mine is kept at static/stream-head
:
|
|
Create a GitHub Action
Anytime you post a new comment on the GitHub Issue thread, this action will run a workflow that will update the stream.md
file in your source code and make a new commit.
|
|
Test that it works
Create a new GitHub Issue in the repo and write the first fleeting thought in your microblog. Then go to the Actions
tab and see that workflow runs successfully. Your repo should have a new commit and the stream.md
file should have your comment’s body appended.
Make a new comment in the Issue thread and see that the there’s a new commit and the comment’s body is added to stream.md
but this time it is above the previous comment.
If the Actions workflow is working correctly and the commits are happening, your server’s deploy script should be automatically updating the website.
Celebrate again
You’ve got a working microblog on your blog! How cool is that?!
Keep in mind:
- Images probably won’t work in this setup. I dunno, I haven’t tested it.
- The size of your stream page is directly proportional to the number of posts/comments you make in the Issue thread. If it’s getting heavy, consider implementing a pagination technique or creating a new issue and reconfiguring the Actions workflow.
- Every single commit on your repo is going to run the deploy script on your server. If that is undesirable, consider updating the webhook to trigger only when commits are made to a certain branch (like
deployment
).
Cheers and happy hacking!