Python2 is long deprecates and is not in the amazon linux 2023 repos

aws-cli v2 automatically uses signature v4: https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingAWSSDK.html#UsingAWSSDK-move-to-Sig4

Some tabs have to be kept because <<-HEREDOCs ignore tabs but not
spaces. Also standardise some spacing.

The http calls are nicer because we don't have to format the output with `cut`

It's meant to be installed locally, not on EC2 instances

This follows https://docs.docker.com/build/building/multi-platform/

Most likely, commands were timing out because we ran some of the tests on `t3.nano`s, which have variable CPU, and the tests exhausted allowed CPU bursts. We conduct more intensive tests now, so we upgraded to `t3.small`. This may mean the longer timeouts are no longer needed.

…t instead of "success"

Co-authored-by: paul david <[email protected]>

… `BuildkiteAgentEnableGitMirrors`""

It has been deprecated. Instead, customers should use `OnDemandPercentage`.

With v6, we will be renaming the default branch to main using the GitHub UI. When this change is made, the next build on the main branch won't push a stack template to the same location. So let's push to both locations for now.

…15-git-mirrors-only-works-as-an-experment

…id-to-securitygroupids

They need to have some level of nested templates because otherwise,
goss will attempt to evaluate the templates that are intended to be
evaluated by docker.

Also, the elements of `stdout` are regexes, so we
adapt it to test for each expected element of the list. Goss will report
which regex did not match the output, so we can use this determine which
plugin are missing. It won't be able to tell if there are other plugins,
but that is very much a feature.

…all-elastic-stack.sh

Amazon's recommended strategy is `price-capacity-optimized`: https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_InstancesDistribution.html but the default strategy for a InstancesDistribution is `lowest-price`.
In the elastic ci stack v5, we overrode the default and set it to `capacity-optimized`.

However, for a CI system, I think the strategy with the lowest risk of interruption is preferable.
There are two distinct reasons for this:
- Interrupting a CI job has a cost in developer time. Usually, developers are
  more expensive than instances.
- The instances carry state, e.g. the checkout dir and docker caches.
  Loosing this state costs time on subsequent jobs, which means those
  instance could be running for longer, and developers could be waiting
  for longer.

This is clearly a tricky balancing act, so giving users the freedom to
select a different strategy is also a good idea.

…-elastic-ci-stack

…stack-image-based-on-al2023

Otherwise the symlinks, for example, from python to python3 won't be
created.

Both of them work for now, and yum is a symlink to dnf. But dnf is now
the way™️.
See https://docs.aws.amazon.com/linux/al2023/ug/package-management.html

…tartup script

…ite_agent_enable_git_mirrors-not-being

…hat-are-not-on-al2023-by-default

…r-works-in' into v6

…ram-from-elastic-ci-stack

When the InstanceName parameter is the empty string, use the stack name
instead.

…er-and-main-for-the-time-being

…-name-to-the-stack-name

Default InstanceName to stack name

…-parameters

This is useful for users that are doing blue-green deployments and want
the (eg blue) stack to be able to be scaled in to 0 instances while the
green stack is fully scaled out.

…n-packer-instead-of-startup

It's in /usr/bin/cfn-signal now, which should be in the $PATH

…al-in-install-scripts

It was found on Amazon Linux 2023 that the default 10s grace period was
insufficient to allow the bootstrap to tear down cleanly when a job is
cancelled from the Buildkite API.

…d-for-cancellation-sigkill

Update changelog for v6.0.0-beta1

…-flag-to-docker-compose-on-elastic-stack

It's root on most systems. Seems unnecessary to do this. If it needs to
be written to, it should be done as root.

In particular we want the root user in the docker container to be
buildkite-agent:docker on the host, so use id -u and getent group to
determine these dynamically.

…ockerfilepostgres-on-bkbk-is-failing-and

…to-v2200

# Conflicts:
#	packer/linux/scripts/install-buildkite-agent.sh
#	packer/windows/scripts/install-buildkite-agent.ps1

…ker-compose-buildx-and-buildkite-agent