Machine-readable list of currently maintained branches/versions

[brianseeders]

Add a machine-readable list of currently maintained versions and branches for use with various tools and automation. This file should be updated as part of the version bump processes, and will only be maintained in the main branch.

I've added a few redundant fields to the structure to aid in filtering, etc (e.g. so you can filter on .currentMajor and not ! .previousMajor).

I've avoided adding duplicate versions/branches to cut down on possible places for human error. For example, it might be nice to have top-level fields for certain things like currentMinorVersion: 8.3.0, previousMajorBranch: 7.17, versions: [8.3.0, 8.2.0, ...] to make them easier to grab, but this increases places where human error could occur.

As an example, here is what it looks like to use terraform to grab the list of current dev branches from this JSON file:

data "github_repository_file" "kibana_versions" {
  repository = "kibana"
  branch     = "machine-versions"
  file       = "versions.json"
}

locals {
  kibana_versions      = jsondecode(data.github_repository_file.kibana_versions.content)["versions"]
  kibana_branches      = [for k, v in local.kibana_versions : v["branch"]]
  current_dev_branches = local.kibana_branches
  hourly_branches      = local.kibana_branches
  daily_branches       = setsubtract(local.current_dev_branches, local.hourly_branches)
}

Here are some things that should be able to be driven by this data pretty easily:

• current-dev-branches in terraform
• upcoming new backport/version labels
• version gap fixing
• .backportrc.json (if we wanted to start auto-generating it)
• es perf team's needs
• es snapshot dashboard
• triage test skip tool branch choices

Additionally, we should be able to launch a task any time this file changes in main, and automate some/most of the version bump process.

[spalger]

I like it, should we maybe prevent people from importing this file? Is there a reason we don't want people to rely on it in code? I think the size might be a problem but there is currently also a decent amount of version-specific product stuff happening in the repo which I think could be informed by a file like this. Just something to think about

[brianseeders]

I like it, should we maybe prevent people from importing this file? Is there a reason we don't want people to rely on it in code? I think the size might be a problem but there is currently also a decent amount of version-specific product stuff happening in the repo which I think could be informed by a file like this. Just something to think about

Hmm, is there a reason you know of that someone would want to grab the version or branch information for a version other than what is running / checked out?

It will be inaccurate outside of main, so it probably wouldn't be able to be relied upon for anything except in main.

[tylersmalley]

This is great. Looks like you covered the use cases and the terraform looks really clean.

@spalger do you mean prevent people from importing this in Kibana?

[tylersmalley]

cc @danielmitterdorfer

[spalger]

@tylersmalley @brianseeders Yeah, I'm trying to think about how people might try to import this file and use it for version information. I think the fact that it won't be accurate outside of main is enough for us to forbid importing it.

[tylersmalley]

Works for me!

Maybe we add something to the top of the JSON?

"notice": "This file is not maintained outside the main branch and to only be used for tooling.",

I don't think we should convert to something like JSON5 just for the comment. This way we maintain as much compatibility with whatever tooling folks will use.

[danielmitterdorfer]

Nice, I like it! It definitely does the trick for generating snapshots for the correct versions. What I like specifically is that it does not only contain the branch but also the specific version.

[elasticmachine]

Pinging @elastic/kibana-operations (Team:Operations)

[brianseeders]

cc @mistic

[jbudz]

Do we define "current" as development e.g. snapshots or release versions?

[brianseeders]

Do we define "current" as development e.g. snapshots or release versions?

The terminology in the file from a development standpoint. So, the "current" major is the current major that we are currently developing, e.g. 8.

The (currentMajor, currentMinor) would then be the minor version we are currently developing toward, e.g. 8.3.
The (currentMajor, previousMinor) would then be the minor version we were previously developing toward and has been released, e.g. 8.2

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: e3a93d1
• Storybooks Preview
• Webpack Bundle Analyzer

Metrics [docs]

✅ unchanged

History

• 💛 Build #35592 was flaky 05606e4
• 💚 Build #35335 succeeded 1bdbd22

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream