ci: pin all os images

[thompson-tomo]

This pins all os images rather than latest as we have renovate to update them. It also makes it explicit in which version we are testing against.

[robbkidd]

Pinning OS versions seems like a admirable goal, but I think it would ignore the OSes declared within workflow matrices. (At least according to this Renovate config, my read of the github-actions manager docs, and some judicious dry-running of this PR locally.)

Our Renovate config "extends" config:best-practices. That enables the Renovate github-actions manager (among other things). The github-actions manager extracts runs-on: values, but only assesses the literals that appear in the YAML for matching against runner types. Our runs-on: ${{ matrix.os }} won't be recognized as something that the Renovate manager would need to go searching through the matrix's parameters to figure out. So it would be ignoring the runners for the test, exporters, and propagators jobs.

These updates to workflows and renovate configs ought to be vetted locally with some skeptical dry-runs. Maybe our Renovate config can be taught new tricks with regexManagers to look at matrix.os? 🤷🏻

[thompson-tomo]

You are right, I am skeptical it would update the matrix as well and if it wasn't detecting it in the Dashboard I was going to go down the path of adding a custom manager to handle them. It is likely it would need to be a recursive like the example at https://docs.renovatebot.com/configuration-options/#custommanagersmatchstringsstrategy

I don't see it as urgent giving the long release cycles. Would it be OK to have it pinned like it is now & then follow up with the custom manager via seperate pr. More than happy for that issue to be assigned to me and I will do it within the next week or so.

[robbkidd]

What problem do we have today that is resolved by pinning these runners?

[thompson-tomo]

The main problem is that we are running the risk of github changing the version latest uses and that could break the builds etc. This also puts us in control of when we switch os versions.

[robbkidd]

OK. I'm convinced.

A bot assisted in cranking out this custom manager (as you proposed):

  "customManagers": [
    {
      "customType": "regex",
      "managerFilePatterns": [".github/workflows/**"],
      "matchStringsStrategy": "recursive",
      "matchStrings": [
        "os:\\s*\\n(?:\\s+-\\s+[\\w.-]+\\n)+", # 1st stage: match any 'os:' key that is followed by 1 or more list items
        "-\\s+(?<depName>\\w+)-(?<currentValue>[\\d.]+)\\n" # 2nd stage: for each list item, match and capture depName-currentValue
      ],
      "datasourceTemplate": "github-runners" # run the found depName-currentValue through this updater
    }
  ],

I'm inclined not to postpone putting the custom manager in to update our matrix'd OSes.

[thompson-tomo]

Thanks.

That is similar to what I imagined thompson-tomo/opentelemetry-ruby-contrib@847910d I just need to test it using the cli and will likely go with a hybrid of the 2. I should hopefully be able to do that today my time.

[robbkidd]

Yep! Let's pin with a soon follow-up to add a custom manager to our renovate config for detecting and updating GitHub runners declared in matrix'd jobs.

[thompson-tomo]

@robbkidd i have added the custom manager to the contrib repo open-telemetry/opentelemetry-ruby-contrib#2234 and if merged and runs as expected on Monday, I will sync renovate from contrib to this repo.

[thompson-tomo]

@robbkidd sync of renovate config from contrib has been proposed as #2102 which will update os etc.