re-use cmlxc workflow, replacing CI with hetzner staging servers with local lxc containers#917
re-use cmlxc workflow, replacing CI with hetzner staging servers with local lxc containers#917
Conversation
7ea8cfd to
51b930a
Compare
8677378 to
3ec2c7f
Compare
| cmlxc_commands: | | ||
| cmlxc init | ||
| cmlxc deploy-cmdeploy --source ./repo -vv cm0 | ||
| cmlxc test-mini cm0 | ||
| cmlxc test-cmdeploy -vv cm0 | ||
| cmlxc deploy-cmdeploy --source ./repo -vv --ipv4-only cm1 | ||
| cmlxc test-cmdeploy -vv cm0 cm1 |
There was a problem hiding this comment.
This is a good start :) I wonder whether the deploys could maybe run concurrently to speed this up a bit - but we should first gather some experience with this new workflow.
There was a problem hiding this comment.
tests are generally very fast, it's the deploys that are slow -- they could run concurrently against several hosts but then the option-handling gets more complex. for now it's simpler, and more helpful for logging and debugging any issues, to run things sequentially.
| # save previous acme & dkim state | ||
| rsync -avz root@staging-ipv4.testrun.org:/var/lib/acme acme-ipv4 || true | ||
| rsync -avz root@staging-ipv4.testrun.org:/etc/dkimkeys dkimkeys-ipv4 || true | ||
| # store previous acme & dkim state on ns.testrun.org, if it contains useful certs | ||
| if [ -f dkimkeys-ipv4/dkimkeys/opendkim.private ]; then rsync -avz -e "ssh -o StrictHostKeyChecking=accept-new" dkimkeys-ipv4 root@ns.testrun.org:/tmp/ || true; fi | ||
| if [ "$(ls -A acme-ipv4/acme/certs)" ]; then rsync -avz -e "ssh -o StrictHostKeyChecking=accept-new" acme-ipv4 root@ns.testrun.org:/tmp/ || true; fi | ||
| # make sure CAA record isn't set | ||
| scp -o StrictHostKeyChecking=accept-new .github/workflows/staging-ipv4.testrun.org-default.zone root@ns.testrun.org:/etc/nsd/staging-ipv4.testrun.org.zone | ||
| ssh root@ns.testrun.org sed -i '/CAA/d' /etc/nsd/staging-ipv4.testrun.org.zone | ||
| ssh root@ns.testrun.org nsd-checkzone staging-ipv4.testrun.org /etc/nsd/staging-ipv4.testrun.org.zone | ||
| ssh root@ns.testrun.org systemctl reload nsd |
There was a problem hiding this comment.
ngl, I'm going to miss this caching logic a little bit.
j4n
left a comment
There was a problem hiding this comment.
Looks good, could not test much; I suppose this will mean ci-testing locally and then having a nightly run of the old-fashioned non-local testing?
| @@ -1,15 +1,26 @@ | |||
| name: CI | |||
| name: Run unit-tests and container-based deploy+test verification | |||
There was a problem hiding this comment.
| name: Run unit-tests and container-based deploy+test verification | |
| name: CI: unit tests + LXC deploy |
So its always visible in UI
| on: | ||
| pull_request: | ||
| # Triggers when a PR is merged into main or a direct push occurs | ||
| push: |
There was a problem hiding this comment.
maybe we should bring back excluding the non-code files:
paths-ignore:
- 'scripts/**'
- '**/README.md'
- 'CHANGELOG.md'
- 'LICENSE'
There was a problem hiding this comment.
don't forget doc/** ;)
cd9d4df to
096acf3
Compare
cmlxc is meanwhile regularly published (via the https://github.com/chatmail/cmlxc repo) via an OIDC-automated github workflow (which means anyone with write rights can create a new release, see README):
https://pypi.org/project/cmlxc/
The chatmail/cmlxc repo also offers a re-usable "lxc-test" workflow that is used here in this PR, to replace the staging-* hetzner host testing with testing against local containers. The "cmlxc" commands executed in the github CI should be possible to run unmodified locally to recreate any problems.
i think it would be sufficient to only daily deploy to "real" servers, maybe laso doing the docker tests there. It is not neccessary for each commit in a PR to cause the whole remote dance and dependency (if something fails in staging, it's not easy to replicate locally).
A sister PR is also in the madmail repo, also re-using the same lxc-test workflow.
sidenote: The "chatmail/cmlxc" is still incrementally developing, although i think i finished the largest refactorings i wanted to do. I'll see to give a sign when i feel the code base is sufficiently stable, and worth a more thorough review. Meanwhile PRs or issue-filing ist welcome.