Ideas for a major release

[kayman-mk]

Release date: ... months ahead

• clean-up of agent registration methods

  • use pre-registered runner only. (runner_gitlab.preregistered_runner_token_ssm_parameter_name) (When using the newer gitlab authentication token the SSM parameter should not be created by this module #1225)

  • rotate the runner token automatically and manage the SSM parameter within the module (Handling of the New Auto Token Rotation Feature #1196)

  • deprecated in GitLab 15.6 (November 2022). They are scheduled for removal in GitLab 20.0 (May 2027).

• GitLab Runner Docker Machine executor is deprecated

  • announced in GitLab 17.5 (Oct 2024), Removal in GitLab 20.0 (May 2027)

Support end dates:

• 15.6: Feb 2023
• 17.5: Jan 2025

GitLab deprecations: https://docs.gitlab.com/update/deprecations/

[abeluck]

I think it would also be nice for the next major release to include the deprecation/removal of the old authentication token system (like here).

Also I could contribute an example of using the gitlab provider to deploy gitlab runners entirely in one terraform run, based on our implementation.

However I would note that I had to workaround the issue #590 because in our case we could not accept that you had to run the terraform execution twice to have the separate cache.

[ben-ganley]

After seeing frequent spot interruptions, it would be good to change the default setting for runner_worker_docker_autoscaler_asg.spot_allocation_strategy from lowest-price to price-capacity-optimized which is the AWS recommended default per https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-allocation-strategy.html

[ben-ganley]

It would also be great if we could define multiple runners in the config.toml file.

This would be helpful for being able to launch jobs with different tags and configs from the one instance. For example if I want to have jobs that target small, medium and large workers I need to define this module three times and end up with three instances sitting there all the time waiting to dispatch jobs. Since we can do this in just one config.toml file it would be handy to be able to have multiple sections each with its own tags and in my case, different fleeting config to launch smaller or larger instances.

[david-sauer-turbinekreuzberg]

It would also be great if we could define multiple runners in the config.toml file.

This would be helpful for being able to launch jobs with different tags and configs from the one instance. For example if I want to have jobs that target small, medium and large workers I need to define this module three times and end up with three instances sitting there all the time waiting to dispatch jobs. Since we can do this in just one config.toml file it would be handy to be able to have multiple sections each with its own tags and in my case, different fleeting config to launch smaller or larger instances.

we use arm spot by default, but developers have the option to choose amd or on demand if needed (long running jobs).
because of this we currently deploy 4 runners (arm spot, arm on-demand, amd spot, amd on-demand).
i would like to see this feature a lot.

[david-sauer-turbinekreuzberg]

i would like to see the use of instance_requirements for resource "aws_launch_template" "gitlab_runner_instance"

something like

  instance_requirements {
    memory_mib {
      min = 1024
      max = 8 * 1024
    }
    vcpu_count {
      min = 1
      max = 4
    }
    burstable_performance = "included"
    local_storage = "included"
    cpu_manufacturers = ["arm"]
  }

instead of a single fixed instance_type