Automate OBI chart update PRs

[MrAlias]

Daily, check for a new OBI release, and create a PR automatically that updates the OBI chart.

[Copilot]

Pull request overview

This PR automates the process of updating the OBI (OpenTelemetry eBPF Instrumentation) chart by adding a scheduled GitHub Actions workflow and a supporting shell script.

Changes:

• Adds a new workflow (.github/workflows/update-obi-chart.yaml) that runs daily, on manual dispatch, or on repository dispatch to detect new OBI releases and create/update a PR.
• Adds a shell script (.github/scripts/update-obi-chart.sh) that resolves the latest release tag, updates Chart.yaml, re-renders examples, and sets workflow outputs for the PR step.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
.github/workflows/update-obi-chart.yaml	New workflow for scheduled/manual OBI chart update with PR creation
.github/scripts/update-obi-chart.sh	Script to resolve release, update chart metadata, and signal changes via outputs

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[TylerHelmuth]

Instead of a script, is it possible to use dependabot? I know dependabot can be told to watch a helm chart's dependencies, can it be told to watch for new images that correspond to the appVersion?

[MrAlias]

Instead of a script, is it possible to use dependabot? I know dependabot can be told to watch a helm chart's dependencies, can it be told to watch for new images that correspond to the appVersion?

Let me look into this 👍

[MrAlias]

I do not think Dependabot is a good fit for this specific OBI update flow.

The important distinction is what that Honeycomb config is doing. The:

- package-ecosystem: "helm"
  directories:
    - "./charts/htp-bindplane"

pattern is for Helm dependency updates, i.e. entries under dependencies: in a chart's Chart.yaml. That is useful when a chart consumes other charts and you want Dependabot to open PRs for subchart version bumps.

That is not what we are doing for OBI here.

For charts/opentelemetry-ebpf-instrumentation, the thing we need to track is the upstream OBI release and then:

1. bump appVersion in Chart.yaml
2. bump the chart version
3. regenerate the rendered example manifests
4. open the PR using OTelBot

The chart's image tags are also not explicitly pinned in values.yaml; they inherit from appVersion. So even if we tried to approach this from the image-update angle, the effective version is indirect. Dependabot generally works best when the version it is managing is explicitly declared where it expects to update it.

From all this:

• the Honeycomb pattern is valid, but it solves Helm dependency updates, not upstream app release tracking
• Dependabot does not cleanly cover the OBI appVersion bump flow in this repo
• even if we expanded Dependabot usage here, we would still need additional automation for chart versioning and regenerating examples

Given that, I think the GitHub Action and script is the more appropriate tool for this case.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[MrAlias]

@open-telemetry/helm-approvers please take a look. This automation ensures the OBI chart stays up to date and helps the OBI team avoid drift.