Use OS-dependent cache key for specs

#7736 (closed) revealed that we use Debian bullseye to build all native gems for the specs. Since native gems may depend on system libraries or specific versions of glibc, we should adjust the gem caching for the specs to depend on the builder image.

Currently, in https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/518a980bcf1c687b6246ccf56267a6f24c5ac114/gitlab-ci-config/gitlab-com.yml#L100-101:

.spec_template: &spec_template
  extends: .gems-cache

.gems-cache is used for:

1. generate-facts
2. spec-template
3. update-gems-cache
4. rubocop
5. yard

spec-template should be treated differently here.

changed the description

mentioned in issue #7736 (closed)

Wonder if CI_JOB_IMAGE can be used here: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html. Looks like it.

mentioned in commit 8bbdf952

mentioned in merge request !6801 (merged)

assigned to @stanhu

changed milestone to %15.11

@stanhu - please see the following guidance and update this issue.

	1 Error
	Please add typebug typefeature, typemaintenance and a subtype label to this issue.

If you do not feel the purpose of this issue matches one of the types, you may apply the typeignore label to exclude it from type tracking metrics and future prompts.

This message was generated automatically. You're welcome to improve it.

added devopssystems groupdistribution labels

added sectioncore platform label

added maintenancepipelines typemaintenance labels

This makes sense to me. We will end up with more in cache, but considering the implications, this is well worth it in addressing problematic behavior or polluted cache on rebuilds.

mentioned in commit cafd3709

added to epic &10287

I'm going to unassign myself on this. !6801 (merged) should address this issue, but it's not clear to me whether it will be merged.

closed

unassigned @stanhu

assigned to @stanhu