Skip to content

Bump GET_GEO_TAG to 0.7.9 to fix GET:Geo pipeline

Michael Kozonorequested to merge
bump-get-geo-tag-to-0.7.5 into master

What does this MR do?

Bumps the GET:Geo tag to https://gitlab.com/gitlab-org/geo-team/geo-ci/-/tags/0.7.9 in order to fix this error during GET:Geo pipeline:

╷
│ Error: Unsupported Terraform Core version
│ 
│   on /gitlab-environment-toolkit/terraform/modules/gitlab_gcp_instance/main.tf line 2, in terraform:
│    2:   required_version = ">= 1.9"
│ 
│ Module module.gitlab_ref_arch_gcp.module.consul (from
│ ../gitlab_gcp_instance) does not support Terraform version 1.5.0. To
│ proceed, either choose another supported Terraform version or update this
│ version constraint. Version constraints are normally set for good reason,
│ so updating the constraint may lead to other errors or unexpected behavior.
╵

Fine details

See discussion thread in this MR:

In the end of the day, what the qa-geo job is attempting to do is simple. It just installs the gitlab-qa gem and runs the "Test::Instance::Geo" scenario against the previously deployed environment using docker-in-docker. So it really only needs Ruby, Bundler and Docker.

I've searched through the gitlab-build-images build jobs we have nowadays, and I think that's the one that best fits your use case, and it's up-to-date:

registry.gitlab.com/gitlab-org/gitlab-build-images/ci/debian-bookworm-slim-ruby-3.4.5:rubygems-3.6-git-2.49-docker-27.4.1

This image is built by the ci-docker job and it only adds Ruby, Git, and Docker.

If 3.4.5 is a too far Ruby version for Geo, you can still use:

  • registry.gitlab.com/gitlab-org/gitlab-build-images/ci/debian-bookworm-slim-ruby-3.3.9:rubygems-3.6-git-2.49-docker-27.4.1
  • registry.gitlab.com/gitlab-org/gitlab-build-images/ci/debian-bookworm-slim-ruby-3.2.9:rubygems-3.6-git-2.49-docker-27.4.1

Related issues

Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion.

Required

  • MR title and description are up to date, accurate, and descriptive.
  • MR targeting the appropriate branch.
  • Latest Merge Result pipeline is green.
  • When ready for review, MR is labeled workflowready for review per the Distribution MR workflow.

For GitLab team members

If you don't have access to this, the reviewer should trigger these jobs for you during the review process.

  • The manual Trigger:ee-package jobs have a green pipeline running against latest commit.
  • If config/software or config/patches directories are changed, make sure the build-package-on-all-os job within the Trigger:ee-package downstream pipeline succeeded.
  • If you are changing anything SSL related, then the Trigger:package:fips manual job within the Trigger:ee-package downstream pipeline must succeed.
  • If CI configuration is changed, the branch must be pushed to dev.gitlab.org to confirm regular branch builds aren't broken.

Expected (please provide an explanation if not completing)

  • Test plan indicating conditions for success has been posted and passes.
  • Documentation created/updated.
  • Tests added.
  • Integration tests added to GitLab QA.
  • Equivalent MR/issue for the GitLab Chart opened.
  • Validate potential values for new configuration settings. Formats such as integer 10, duration 10s, URI scheme://user:passwd@host:port may require quotation or other special handling when rendered in a template and written to a configuration file.
Edited by Michael Kozono

Merge request reports