From e1e311c5119eb81317da6770873dd2abf9e014be Mon Sep 17 00:00:00 2001 From: Roman Cattaneo <> Date: Sun, 10 Aug 2025 17:33:50 +0200 Subject: [PATCH] ci: Clean up deployments Things I learned during work on PR #34: - A dummy DATABASE_URL is sufficient to build the release - Run migrations as part of `ExecStartPre` in the service file definition. This allows to re-use the production env vars already configured in the service defintion file. --- .github/workflows/release_deploy.yaml | 9 ++++++--- dev_docs/release-and-deploy.md | 6 +++++- mix.exs | 2 +- 3 files changed, 12 insertions(+), 5 deletions(-) diff --git a/.github/workflows/release_deploy.yaml b/.github/workflows/release_deploy.yaml index b2e0c6b..2244ec0 100644 --- a/.github/workflows/release_deploy.yaml +++ b/.github/workflows/release_deploy.yaml @@ -1,7 +1,7 @@ name: Deploy release on: - # useful for (manually) deploying test/draft releases + # Manually deploy a release candidate for testing in a staging environment. workflow_dispatch: push: @@ -14,7 +14,10 @@ jobs: env: SECRET_KEY_BASE: ${{ secrets.SECRET_KEY_BASE }} MIX_ENV: prod - DATABASE_URL: ${{ secrets.DATABASE_URL }} + # Dummy DATABASE_URL used when building a release. Otherwise, runtime.exs + # is complaining. But actually, we have no need to connect to the database + # while building a release. + DATABASE_URL: "ecto://USER:PASS@HOST/DATABASE" steps: - uses: actions/checkout@v4 @@ -71,6 +74,6 @@ jobs: - name: Activate new release if: github.event_name == 'push' run: | - ssh -o StrictHostKeyChecking=no -p ${{ secrets.DEPLOY_PORT }} ${{ secrets.DEPLOY_USER }}@${{ secrets.DEPLOY_HOST }} "cd ${{ secrets.DEPLOY_PATH_RELEASES }}; ./${{ env.release }}/bin/migrate; rm current; ln -s ${{ env.release }}/ current; ${{ secrets.DEPLOY_RESTART_SERVER }}" + ssh -o StrictHostKeyChecking=no -p ${{ secrets.DEPLOY_PORT }} ${{ secrets.DEPLOY_USER }}@${{ secrets.DEPLOY_HOST }} "cd ${{ secrets.DEPLOY_PATH_RELEASES }}; rm current; ln -s ${{ env.release }}/ current; ${{ secrets.DEPLOY_RESTART_SERVER }}" env: release: cklist-${{ steps.info.outputs.version }}-${{ steps.info.outputs.git-hash }} diff --git a/dev_docs/release-and-deploy.md b/dev_docs/release-and-deploy.md index cde347b..8fbacaa 100644 --- a/dev_docs/release-and-deploy.md +++ b/dev_docs/release-and-deploy.md @@ -9,6 +9,10 @@ In (slightly) more detail: 1. When a pull request is opened, various tests run. 2. Pull requests can only be merged, when all tests pass (and the version number is updated). -3. Upon merge, a release (with the new version number) is built and automatically deployed to [cklist.org](cklist.org). +3. Upon merge, a release (with the new version number) is built and automatically deployed to [cklist.org](cklist.org). Migrations are configured to run as part of `ExecStartPre` in the service file definition. The repository is configured such that tests need to pass and run against the latest[^1] version of `main`. A [merge queue](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue) might be used in the future to avoid congestion when multiple developers work at the same time. Merge queues require an organization. We might move there anyway once we have multiple people contribute. + +## Release candidates + +The release & deploy workflow can be triggered manually, which will deploy a release candidate to [rc.cklist.org](https://rc.cklist.org). Release candidates operate in a staging environment with a separate database. The mailserver configuration is shared. diff --git a/mix.exs b/mix.exs index 28beb8c..cda0289 100644 --- a/mix.exs +++ b/mix.exs @@ -4,7 +4,7 @@ defmodule Cklist.MixProject do def project do [ app: :cklist, - version: "0.0.9", + version: "0.0.10", elixir: "~> 1.14", elixirc_paths: elixirc_paths(Mix.env()), start_permanent: Mix.env() == :prod,