Update blag version, improve workflow for new deployment host.

This commit is contained in:
2024-09-05 21:46:21 -07:00
parent 39ccd1c97f
commit ef1756df5e
2 changed files with 60 additions and 43 deletions

View File

@@ -28,8 +28,8 @@ jobs:
uses: docker/login-action@v3
with:
registry: gitea.raer.me
username: ${{ secrets.PRODUCTION_REGISTRY_USERNAME }}
password: ${{ secrets.PRODUCTION_REGISTRY_TOKEN }}
username: ${{ secrets.REGISTRY_USERNAME }}
password: ${{ secrets.REGISTRY_TOKEN }}
-
name: Install required system packages...
run: |
@@ -40,8 +40,8 @@ jobs:
-
name: Install pipenv, build blog...
env:
PIPENV_USER: ${{ secrets.PRODUCTION_REGISTRY_USERNAME }}
PIPENV_PASS: ${{ secrets.PRODUCTION_REGISTRY_TOKEN }}
PIPENV_USER: ${{ secrets.REGISTRY_USERNAME }}
PIPENV_PASS: ${{ secrets.REGISTRY_TOKEN }}
run: |
pip install pipenv
pipenv install
@@ -64,6 +64,9 @@ jobs:
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.
@@ -79,54 +82,68 @@ jobs:
-
name: Configure SSH...
env:
SSH_USER: ${{ secrets.PRODUCTION_SSH_USER }}
SSH_KEY: ${{ secrets.PRODUCTION_SSH_KEY }}
SSH_HOST: ${{ secrets.PRODUCTION_SSH_HOST }}
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
echo "$DEPLOYMENT_KEY" > ~/.ssh/staging.key
chmod 600 ~/.ssh/staging.key
cat >> ~/.ssh/config <<END
Host staging
HostName $SSH_HOST
User $SSH_USER
HostName $DEPLOYMENT_HOST
User $DEPLOYMENT_USER
IdentityFile ~/.ssh/staging.key
StrictHostKeyChecking no
END
cat ~/.ssh/config
-
name: Test SSH Host...
name: Ping SSH host...
env:
SSH_HOST: ${{ secrets.PRODUCTION_SSH_HOST }}
run: |
ping -c 3 $SSH_HOST
ssh staging 'ls'
SSH_HOST: ${{ secrets.DEPLOYMENT_HOST }}
run: ping -c 3 $DEPLOYMENT_HOST
-
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;'
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;'