Move functional tests to the Cloud

Design Document

• Runner should pass the latest build artifact to the instance
  CI_PROJECT_ID
  CI_PIPELINE_ID

  Get build job number. BUILD_JOB_NUMBER
  curl https://salsa.debian.org/api/v4/projects/6526/pipelines/344947/jobs where name == "build"

  artifacts_download_url = https://salsa.debian.org/api/v4/projects/{CI_PROJECT_ID}/jobs/{CI_PIPELINE_ID}/artifacts
  curl $artifacts_download_url > /tmp/artifacts.zip extract and install *_all.deb

  Can't store in an SSM parameter since there could be parallel pipelines.
  Construct ec2 instance user-data on the fly?

  Feels icky, but the params can be stored as tags of the instance and retrieved as follows
  curl http://169.254.169.254/latest/meta-data/tags/instance/salsa:project-id
  http://169.254.169.254/latest/meta-data/tags/instance/salsa:build-job-id

  The tag must be added before launching the instance, since user_data needs to read it.
  Override the tags in aws ec2 run-instances command.
  https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html

  Extract "PublicDnsName" property from the response to pass on to the next stage (as a custom environment variable?)

• Runner should pick the correct Debian distribution

• Runner should wait for the instance to come up

• Build 3 AMIs with the Tenable Nessus agents installed Optional: Automate this. ThoughtWorks Linking Key an be an SSM secret parameter.

  1. Installing Nessus agents on each app server after startup
     Might increase the time taken by functional tests. If the latest Debian AMI can be picked up at instance launch, we no longer have to do upgrades. The identification can be kept unique based on the instanceId. Otherwise, linking and unlinking would be necessary. Determining when to unlink is hard.

• Debian Instance Launch Template
  Launch Template launches one instance each of 3 different AMIs. Is this possible?

• The subsequent jobs get the public IP address of the FreedomBox instance.
  Can this just be one instance running 3 different instances of Splinter?
  Would be nice to have this setup containerized.
  How to pass on the environment variable to the next stage
  https://stackoverflow.com/questions/44774520/exporting-environment-variables-from-one-stage-to-the-next-in-gitlab-ci/62261174#62261174

• Build artifacts

  • HTML Report
  • Screenshots

• Termination of app-server instances

• Remove functional tests pipeline from Buildbot

• Move documentation about this setup to a public Wiki page.

• Commit the cloud-init script to the infrastructure git repository.

• For bullseye-backports (could be a different GitLab issue)

  • Additional build step with DIST=bullseye-backports
  • The app server for stable should use the above build