git automation secrets syntax

tl;dr

---

- name: deploy website
        uses: easingthemes/ssh-deploy@main
        env:
          SSH_PRIVATE_KEY: ${{ secrets.YOUR_PRIVATE_SSHKEY_NAME_HEREEEE }}
          ARGS: "-rlgoDzvca -i" 
          REMOTE_HOST: "ADDRESS"
          REMOTE_PORT: "PORT"
          REMOTE_USER: "USER"
          SOURCE: "_site/"
          TARGET: "PATH/public_html/"
          SCRIPT_BEFORE: |
            whoami
            ls -al            
          SCRIPT_AFTER: |
            whoami
            ls -al
            echo $RSYNC_STDOUT    

you need to replace the YOUR_PRIVATE_SSHKEY_NAME_HEREEEE with the name of the key you defined in your repo’s secrets panel. this took me about 4 hours to figure out because no one makes it clear online. 💀

the ssh key itself is the private key. it’s the content of the id_rsa file after you generate one, found in ~/.ssh. this one:

-----BEGIN OPENSSH PRIVATE KEY-----
<key>
-----END OPENSSH PRIVATE KEY-----

some people point to the fact that if it doesn’t work, adding a newline at the end of your private key when adding it into the gitea panel might do the trick. I didn’t have to do it myself.

context

---

when building the latest version of this website, I went with Jekyll & the Chirpy theme, as I’ve been meaning to try them out for a while.

they offer a nice starter repo on GitHub, which makes use of GitHub Pages. I set this up and it was all great until I realized I want to add my webmaster tokens into the config. I did so, made the repo private just to find that you need to pay if you want Pages on private repos. bye github, *hello gitea**

I moved my repo to my gitea instance as I have one anyway, and I had to make some changes to the workflow:

• went through it to see what it does
• realized I just have to take out the pages deployment and replace it with my own way of deploying the website

extras

---

it is worth mentioning that the runner makes a Docker container for every job. by default, it doesn’t have access to the host filesystem.

in my case, I was testing this on the same server I run my Gitea instance on as well as my runner, so I was trying to deploy the website by simply copying the contents of _site to my website path. this didn’t work and was failing quietly, all while reporting success within the workflow.

if you look around on Google, you will find that if you search for:

• docker copy files from container to host
• docker copy files from inside container to host
• docker cp file to host

you will find answers seemingly pointing to docker cp being able to just escape to the host fs, but this is fact not true (and for good reason)

in this case what you can do is mount a folder (called mounting a volume) to the docker container, but this was a bit too messy and annoying for my liking.

in between testing I tried mounting a folder with sshfs within the docker container, but you cannot simply modprobe fuse to enable the Fuse kernel module required for sshfs without, again, passing a docker container parameter. I suppose you can do this (for the act_runner process which creates the docker containers), but I didn’t like that idea. i’m lazy.

for my solution I used easingthemes/ssh-deploy@main which works well. I suppose other SSH deployments work just as well.

⚠ keep in mind you need to copy the files over before the docker container destroys them, so do it right after the website builds.