Integration testing #8
Labels
No Label
abra
abra-gandi
awaiting-feedback
backups
bug
build
ci/cd
community organising
contributing
coopcloud.tech
democracy
design
documentation
duplicate
enhancement
finance
funding
good first issue
help wanted
installer
kadabra
performance
proposal
question
recipes.coopcloud.tech
security
test
wontfix
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coop-cloud/organising#8
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Holy shit, CI testing that sets up a swarm and deploys an app to it
Yeah, this would be quite cool to do. That one looks a bit hard to maintain and consider that we'll have a
.drone.yml
for each application which will easily balloon and be a headache to take care of. Maybe this is a job for anotherabra
-like script. The question is what is appropriate for testing? Spinning things up and checking that the URL comes up and maybe that all containers are definitely deployed? That'd be a good start.Plus your idea from the meeting: Yunohost-style central CI server running swarm, where stacks get torn down after runs.
One hurdle I can think of with this idea is that
docker stack rm
sometimes takes a while to take down containers, which meansdocker stack rm demo_service && docker volume rm demo_service_vol ...
fails whenever I've tried it.sleep 30
could be an adequate workaround. Or maybe we'd be generating a unique stack name for each test run?Good point. I guess I wouldn't be too worried about tearing things down immediately. We can just
stack rm
and then leave the hourly cron (or whatever) to rundocker system prune -a
to clean up all volumes/networks/images/etc. that are not connected to a running container.I think the only thing stopping this ticket from being a cake-walk is the fact that managing the docker daemon certificates is still a PITA. We'll need to re-generate them all the time and re-load them into Drone so that it can make contact. Need to automate that somehow.
Some progress towards this here: https://drone.autonomic.zone/compose-stacks/wordpress/6/1/2
You need to manually deploy
traefik
onswarm-test
(or if we configured thetraefik
repo the same way aswordpress
).Then, push to the
wordpress
repo, wait a little while, and you can reach the deployed application at https://wordpress.swarm-test.autonomic.zoneNot flipping this "more magic" switch until we have some authentication on the Wordpress instance by default or a method of regularly tearing down apps.
Also still in search of a Drone plugin to run some basic checks using cURL, or checking
docker stack ps
on the remote hostWe should maybe use this: https://github.com/issuu/sure-deploy for the CI. Comes from some $corp and does a bunch of stuff after deployment to check that things went well. I guess the engineering managers were like "wtf we're not using swarm until there is a --detach=false flag".
Could potentially bake that into stack-ssh-deploy?
Traefik is now also configured to auto-deploy to swarm-test.autonomic.zone; once autonomic-cooperative/stack-ssh-deploy#1 is fixed then this will give us basic safety checks on our stacks and we can move on to more CI excitement like:
shellcheck
on custom entrypoints and.envrc.sample
?yaml-lint
on compose files?)OK nice. The next thing I will work on is then the issue regarding the fact that when we know want to deploy these stacks onto a fresh slate each time. That is different from before because we usually assume that the stack is already up (along with its secrets) and then we're just updating it. We're going want to deploy as a fresh stack, and update now. Soooo, we need to integrate dummy secret creation for the CI. We're thinking along the lines of integrating abra into the stack-ssh-deploy plugin or something that lines up with what we do ourselves. In the meantime, if you want to just get moving, you can manually create the secrets on the swarm-test machine.
OK sitrep is now that we put secret generation and cleaning up into
stack-ssh-deploy
so this means that we can move on with getting CI setup for all the compose stacks we care about.Question: auto-creating networks? e.g. my
postfix-relay
build is failing because themail
network doesn't exist: https://drone.autonomic.zone/compose-stacks/postfix-relay/2/1/2Could just create it on the test server, or make it part of
abra context init
, but wondering if we want to automate this to make it more reproducible.@3wordchant maybe let's add a config for
stack-ssh-deploy
:And just pick the default as
--driver overlay
until we need something otherwise?Tight, I'll do that now 👌
@decentral1se should we close this or is there anything you wanna see done (aside from coop-cloud/traefik#6) before declaring testing "ready(ish")?