A matrix to define compatibility across stack versions, where CI job generator leverages

[mashhurs]

Description

When we raise PR, we need to test the plugin changes against its base branch across multiple stacks to make sure we do not break the plugin. This PR introduces the pull-request matrix where all 8.series branches will align on 8.x map and main with main accordingly. The matrix entry for main covers the upgrade path where 8.last.last (will be maintained through release cycle) will be always tested against next major, 9.x/main for now.

Dynamic job generator PR applies this change with YAML() tool which easifies out life.

    matrix_map = call_url_with_retry(MATRIX_MAP)
    matrix_map_yaml = YAML().load(matrix_map.text)
    print(f"matrix_map: {matrix_map_yaml['8.x']}")

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: e37472d

History

• 💚 Build #446 succeeded b72f0e2

cc @mashhurs

[donoghuc]

So we are going to encode all the data in both branches? I was thinking these would be managed by branch. So main would not have anything about the 8.x and similarly 8.x would not have anything in main.

I suppose i could see a world in which updating just main and backporting to copy the whole thing to 8.x may be nice, otherwise it would be two separate PRs.

[mashhurs]

So we are going to encode all the data in both branches? I was thinking these would be managed by branch. So main would not have anything about the 8.x and similarly 8.x would not have anything in main.

I suppose i could see a world in which updating just main and backporting to copy the whole thing to 8.x may be nice, otherwise it would be two separate PRs.

We maintain the matrix only in main branch and static URL of main will be used. This will be called out in the release guide, so no need backporting.

[donoghuc]

I guess I tend to think of branches containing full information for running its CI. The idea that 8.x will be cloned, then a script from that cloned/checked out repo will reach out to github to get data from another branch is not a pattern i'm familiar with. The idea that branches depend on data from other branches is a bit unsettling to me, but it might just be that i'm unfamiliar with an established pattern...

Unrelated: How does step generation/execution handle versions that dont exist? I ask because for the main section it seems like many of those versions do not exist or are all the same, are we able to identify that early and not do too much work?

[mashhurs]

I guess I tend to think of branches containing full information for running its CI. The idea that 8.x will be cloned, then a script from that cloned/checked out repo will reach out to github to get data from another branch is not a pattern i'm familiar with. The idea that branches depend on data from other branches is a bit unsettling to me, but it might just be that i'm unfamiliar with an established pattern...

It is true somehow confusing 🤦 that should be branch specific but we can think of this is a place to keep a global map. We have similar maps such as logstash_release.json and branches.json where we keep maintaining in the main branch and widely used, not a branch specific.

Let's discuss with the team if we can move them to a central repository (create it or use simple S3, etc..). What do you think?

Unrelated: How does step generation/execution handle versions that dont exist? I ask because for the main section it seems like many of those versions do not exist or are all the same, are we able to identify that early and not do too much work?

I have a safeguard logic which will become no-op if versions doesn't exist. If you check now, 8.next should be null (or doesn't exist) as we have just released 8.17.

[donoghuc]

Looks good. We can discuss the comments without blocking forward momentum on this!