150 lines
6.1 KiB
YAML
150 lines
6.1 KiB
YAML
on:
|
|
push:
|
|
# paths:
|
|
# - "content/**"
|
|
# - "static/**"
|
|
# - "templates/**"
|
|
branches:
|
|
- "main"
|
|
|
|
|
|
jobs:
|
|
job1:
|
|
name: Build static site, docker image, upload artifact...
|
|
runs-on: catthehacker-ubuntu
|
|
steps:
|
|
-
|
|
name: Get current date
|
|
id: date
|
|
run: echo "::set-output name=date::$(date +'%Y%m%d%H%M%S')"
|
|
-
|
|
name: Checkout the git repo...
|
|
uses: https://github.com/actions/checkout@v3
|
|
-
|
|
name: Set up docker buildx...
|
|
uses: https://github.com/docker/setup-buildx-action@v3
|
|
-
|
|
name: Login to gitea registry
|
|
uses: https://github.com/docker/login-action@v3
|
|
with:
|
|
registry: gitea.raer.me
|
|
username: ${{ secrets.REGISTRY_USERNAME }}
|
|
password: ${{ secrets.REGISTRY_TOKEN }}
|
|
-
|
|
name: Install required system packages...
|
|
run: |
|
|
export DEBIAN_FRONTEND=noninteractive
|
|
apt update
|
|
apt upgrade -y
|
|
apt install -y curl tar p7zip-full python3.11 pip pipx
|
|
-
|
|
name: Install pipenv, build blog...
|
|
env:
|
|
PIPENV_USER: ${{ secrets.REGISTRY_USERNAME }}
|
|
PIPENV_PASS: ${{ secrets.REGISTRY_TOKEN }}
|
|
run: |
|
|
pip install pipenv
|
|
pipenv install
|
|
pipenv run blag build
|
|
-
|
|
name: Create artifact...
|
|
run: 7z a -mx=9 ./artifact.7z build
|
|
-
|
|
name: Upload artifact...
|
|
uses: https://github.com/actions/upload-artifact@v3
|
|
with:
|
|
name: artifact_${{ steps.date.outputs.date }}
|
|
path: ./artifact.7z
|
|
retention-days: 7
|
|
-
|
|
name: Build and push docker image to gitea package store
|
|
uses: https://github.com/docker/build-push-action@v5
|
|
with:
|
|
context: .
|
|
push: true
|
|
platforms: linux/amd64
|
|
tags: gitea.raer.me/${{ gitea.repository }}:${{ gitea.ref_name }}
|
|
# It seems that the deploy stage here is the only thing that really needs changing.
|
|
## Further, changing this actually simplifies things. We no longer need this complex things that have been commented out below, instead, we do a much simpler process. The more complex process *should* be managed in a separate repo, anyway, because actually doing work on the machine that this is deployed to should be a more protected process.
|
|
|
|
job2:
|
|
needs: job1
|
|
name: Connect to deployment host, update, and redeploy docs website.
|
|
runs-on: ubuntu-latest
|
|
steps:
|
|
-
|
|
name: Install required system packages...
|
|
run: |
|
|
export DEBIAN_FRONTEND=noninteractive
|
|
apt update
|
|
apt upgrade -y
|
|
apt install -y iputils-ping
|
|
-
|
|
name: Configure SSH...
|
|
env:
|
|
SSH_USER: ${{ secrets.DEPLOYMENT_USER }}
|
|
SSH_KEY: ${{ secrets.DEPLOYMENT_KEY }}
|
|
SSH_HOST: ${{ secrets.DEPLOYMENT_HOST }}
|
|
run: |
|
|
mkdir -p ~/.ssh/
|
|
echo "$SSH_KEY" > ~/.ssh/staging.key
|
|
chmod 600 ~/.ssh/staging.key
|
|
cat >> ~/.ssh/config <<END
|
|
Host staging
|
|
HostName $SSH_HOST
|
|
User $SSH_USER
|
|
IdentityFile ~/.ssh/staging.key
|
|
StrictHostKeyChecking no
|
|
END
|
|
cat ~/.ssh/config
|
|
-
|
|
name: Ping SSH host...
|
|
env:
|
|
SSH_HOST: ${{ secrets.DEPLOYMENT_HOST }}
|
|
run: ping -c 3 $SSH_HOST
|
|
-
|
|
name: Run deploy script.
|
|
run: ssh staging
|
|
## The above is far cleaner than below. That means less things have to change in this repo, when things on the deployment host change. In fact, looking over this... it seems that *NO* changes must be made to the actions when things on the deployment host change. As it should be. When the deployment host changes, the scripts related to deployment should change. And because those should be more tightly managed, they should not be spread out in places like this gitea action config.
|
|
|
|
## Even the deployment key needn't change, due to how variable scopes work in gitea. The lowest level variable takes precedence, so repo variables are always preferred over user/org and system variables.
|
|
|
|
## Thus, from the developer's pov, the repo must simply have five secrets, three of which are managed by an administrator with root-level access to the deployment host who will configure the repo secrets as needed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Now, stuff like this can be stuck in a shell script that's stored on the deployment host and activated by an SSH key that is restricted to running only the deployment script.
|
|
# name: Safety check (ensure dirs exist and repo has been cloned)...
|
|
# run: |
|
|
# echo "Adding ci dir if it doesn't exist..."
|
|
# ssh staging 'bash -c "[ -d ci ] || mkdir ci"'
|
|
# echo "Cloning git repo if it isn't already cloned..."
|
|
# ssh staging 'cd ci; bash -c "[ -d ${{ gitea.event.repository.name }} ] || git clone https://${{ secrets.PRODUCTION_API_TOKEN }}@gitea.raer.me/${{ gitea.repository }}.git"'
|
|
# -
|
|
# name: Deploy testing script on remote...
|
|
# run: |
|
|
# ssh staging '\
|
|
# cd ci/${{ gitea.event.repository.name }}; \
|
|
# git remote remove origin; \
|
|
# git remote add origin https://${{ secrets.PRODUCTION_API_TOKEN }}@gitea.raer.me/${{ gitea.repository} }.git; \
|
|
# git checkout ${{ gitea.ref_name }}; \
|
|
# git reset --hard HEAD; \
|
|
# git pull origin ${{ gitea.ref_name }}; \
|
|
# git remote remove origin;'
|
|
# # -
|
|
#
|
|
#
|
|
# name: Pull new image and redeploy...
|
|
# run: |
|
|
# ssh staging '\
|
|
# echo "${{ secrets.PRODUCTION_REGISTRY_TOKEN }}" | docker login --password-stdin --username ${{ secrets.PRODUCTION_REGISTRY_USERNAME }} gitea.raer.me; \
|
|
# docker stop blog.raer.me-prod; \
|
|
# docker rm blog.raer.me-prod; \
|
|
# docker pull gitea.raer.me/${{ gitea.repository }}:${{ gitea.ref_name }}; \
|
|
# docker run -d --name blog.raer.me-prod -p ${{ secrets.PRODUCTION_DEPLOYMENT_HOST }}:4020:80 gitea.raer.me/${{ gitea.repository }}:${{ gitea.ref_name }}; \
|
|
# docker logout gitea.raer.me;'
|
|
|