ci: add workflow to bump OpenTelemetry Kube Stack version

[rogercoll]

What does this PR do?

Automates the process of bumping the tested OpenTelemetry kube-stack Helm Chart version.

Why is it important?

Keep it up-to-date and catch breaking changes as released.

Checklist

• I have read and understood the pull request guidelines of this project.
• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in ./changelog/fragments using the changelog tool
• I have added an integration test or an E2E test

Disruptive User Impact

How to test this PR locally

Related issues

Questions to ask yourself

• How are we going to support this in production?
• How are we going to measure its adoption?
• How are we going to debug this?
• What are the metrics I should take care of?
• ...

[mergify]

This pull request does not have a backport label. Could you fix it @rogercoll? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-./d./d is the label that automatically backports to the 8./d branch. /d is the digit
• backport-active-all is the label that automatically backports to all active branches.
• backport-active-8 is the label that automatically backports to all active minor branches for the 8 major.
• backport-active-9 is the label that automatically backports to all active minor branches for the 9 major.

[rogercoll]

@elastic/observablt-ci Would you recommend any other way of running post-target commands? After the version has been updated in update-tested-kube-stack, we need to run mage integration:buildKubernetesTestData to update the local files

[v1v]

That's possible, however you might need to configure the environment first:

1. Install the tools as part of the script or the GitHub workflow, you choose
2. Configure the env variables in the updatecli manifest. See https://www.updatecli.io/docs/plugins/resource/shell/#_environments

For instance, for the elastic/apm-server you can see the below snippets (it configures the environment in the GitHub workflow):

• https://github.com/elastic/apm-server/blob/34e5414908094bd92d16f6c16134b87810b6bc38/.github/workflows/update-beats.yml#L41-L44
• https://github.com/elastic/apm-server/blob/34e5414908094bd92d16f6c16134b87810b6bc38/.ci/updatecli/update-beats.yml#L32-L42

---

I recommend to run those steps locally first, so if it works locally it should work with GH actions or any other CI vendor.

$ GITHUB_TOKEN=$(gh auth token) \
   GITHUB_ACTOR=<your-user> \
   updatecli diff \
           --config ci/updatecli/updatecli-bump-kube-stack.yml \
           --values .ci/updatecli/values.d/scm.yml

Then you can modify .ci/updatecli/values.d/scm.yml and use your github-user in .scm.owner and run:

$ GITHUB_TOKEN=$(gh auth token) \
   GITHUB_ACTOR=<your-user> \
   updatecli apply \
           --config ci/updatecli/updatecli-bump-kube-stack.yml \
           --values .ci/updatecli/values.d/scm.yml

[rogercoll]

That was really valuable, thanks! Sample execution #10629

[elasticmachine]

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

[v1v]

I'd suggest using regex groups, then you don't need to worry about the spaces.

If you go to https://www.updatecli.io/docs/plugins/resource/file/#_file_target, you can see an example:

e.g this example updates the year on the "Copyright" substrings to 2021 while keeping the existing content such as contributors).:

targets:
  updateCopyrightYear:
    kind: file
    sourceid: whateverSource # Will be ignored as `replacepattern` is specified
    spec:
      file: LICENSE
      matchpattern: 'Copyright \(c\) (\d*) (.*)'
      replacepattern: 'Copyright (c) 2021 $2'

[rogercoll]

good idea, capturing groups approach 34a766b

[v1v]

That's possible, however you might need to configure the environment first:

1. Install the tools as part of the script or the GitHub workflow, you choose
2. Configure the env variables in the updatecli manifest. See https://www.updatecli.io/docs/plugins/resource/shell/#_environments

For instance, for the elastic/apm-server you can see the below snippets (it configures the environment in the GitHub workflow):

• https://github.com/elastic/apm-server/blob/34e5414908094bd92d16f6c16134b87810b6bc38/.github/workflows/update-beats.yml#L41-L44
• https://github.com/elastic/apm-server/blob/34e5414908094bd92d16f6c16134b87810b6bc38/.ci/updatecli/update-beats.yml#L32-L42

---

I recommend to run those steps locally first, so if it works locally it should work with GH actions or any other CI vendor.

$ GITHUB_TOKEN=$(gh auth token) \
   GITHUB_ACTOR=<your-user> \
   updatecli diff \
           --config ci/updatecli/updatecli-bump-kube-stack.yml \
           --values .ci/updatecli/values.d/scm.yml

Then you can modify .ci/updatecli/values.d/scm.yml and use your github-user in .scm.owner and run:

$ GITHUB_TOKEN=$(gh auth token) \
   GITHUB_ACTOR=<your-user> \
   updatecli apply \
           --config ci/updatecli/updatecli-bump-kube-stack.yml \
           --values .ci/updatecli/values.d/scm.yml

[v1v]

I'd say add an entry in the CODEOWNERS for this file, otherwise, robots-ci will be the codeowners and we don't own it.

[rogercoll]

Sure, added an entry with @elastic/elastic-agent-control-plane as owners (please, let me know if another team should own this). 4a53ad5

Also, I changed the backport to active-9 for now. Otel components dependencies are only being updated in 9.1 and 9.2, which makes the alignment with the latest kube-stack versions harder.

[ycombinator]

LGTM but I'd like @swiatekm to also take a look since it pertains to OTel Helm charts.