Add first-class support for build version matrixes (especially Node)

[rarkins]

What would you like Renovate to be able to do?

Support build matrixes in a non-hacky manner.

Did you already have any implementation ideas?

Travis support previously had this but in a hacky approach which needed removing. We need to think of a better way which can co-exist with our regular updating approach.

[vindvaki]

Would love to have this for GitLab's parallel:matrix!

My use case is that I have jobs of the form

test:
  parallel:
    matrix:
      - K3S_VERSION:
        - v1.20.15-k3s1
        - v1.21.10-k3s1
        - v1.22.7-k3s1
        - v1.23.4-k3s1
  services:
    - name: registry.gitlab.com/gitlab-org/cluster-integration/test-utils/k3s-gitlab-ci/releases/$K3S_VERSION
      alias: k3s
  # ... 

and I want K3S_VERSION to be a sliding window of the latest N minor releases, each kept at their latest patch release. And would prefer a single MR updating the entire K3S_VERSION array.

I can imagine this working as a combination of two more general features:

• a generic YAML/JSON manager that can do structural replacements based on something like jq or jsonpath (or even just full blown javascript)
• multi-version support, such as the sliding window of latest N minor releases

[compscidr]

I know this is quite an old issue, but have ran into a similar usecase. I have a GH actions workflow with a build matrix that tracks release tags from another repo, so I have something like this:

  build-nvidia:
    strategy:
      matrix:
        os:
          - "ubuntu20.04"
          - "ubuntu22.04"
        cuda:
          - "11.7.1"
          - "12.2.0"
        lolminer:
          - "1.52a"
          - "1.53"
          - ...

It looks like I am able to able to obtain the latest release for "lolminer" with the "github-releases" data source template, however, I'm not sure how to have renovate append this latest release to the list of "lolminer" versions in the build matrix.