[chore] add update version automation workflow for artifacts release

[jackgopack4]

Add quality-of-life enhancement to automate bumping version number in the Makefile as well as the various distribution manifests (as the number of distros grows, this step will become more of a pain).

Feel free to run in your own fork to verify; also see the successful run in my fork:
https://github.com/jackgopack4/opentelemetry-collector-releases/actions/runs/12320554731/job/34390067049
As well as the generated PR in my fork:
jackgopack4#23

If this gets merged I will open a PR to update collector release doc in opentelemetry-collector repo.

Automatic version bump (increase minor version number) is default behavior; this can be overridden by providing a manual version number update (like bugfix v0.110.0 -> v0.110.1)

[andrzej-stencel]

I 💯 agree that bumping the version should be a simple, single step. This change implements this as a series of steps in GitHub Actions, which makes it not usable if you want to run it outside of GitHub Actions. I'd rather see a shell script written that does the version updates, and that script called as a single step in GitHub Actions. Committing changes should be separate from the script, so that anyone can run the script locally and preview the changes before making it a commit.

Note that there are (to my knowledge) three potentially different versions that need to be bumped in the manifests, as described here:

• stable components all use the stable version - currently v1.15.0
• unstable components from core repository use the core's version - currently v0.109.0
• unstable components from contrib repository use the contrib's version - currently v0.109.0

The core and contrib versions are usually the same, but they are not guaranteed to be the same.

[jackgopack4]

I 💯 agree that bumping the version should be a simple, single step. This change implements this as a series of steps in GitHub Actions, which makes it not usable if you want to run it outside of GitHub Actions. I'd rather see a shell script written that does the version updates, and that script called as a single step in GitHub Actions. Committing changes should be separate from the script, so that anyone can run the script locally and preview the changes before making it a commit.

Would be happy to do it this way, just was modeling it after the existing action script in collector core: https://github.com/open-telemetry/opentelemetry-collector/blob/main/.github/workflows/prepare-release.yml

(EDIT: just realized that only uses github actions to take in the variables and passes them to a Bash script; will make similar changes)

Note that there are (to my knowledge) three potentially different versions that need to be bumped in the manifests, as described here:

• stable components all use the stable version - currently v1.15.0
• unstable components from core repository use the core's version - currently v0.109.0
• unstable components from contrib repository use the contrib's version - currently v0.109.0

Got it, will add stable and beta component update

[jackgopack4]

@andrzej-stencel made the changes you requested; runs in one bash script that can be ran locally in addition to in github actions and adds stable/beta functionality

[andrzej-stencel]

The script in the current form does not update the following places:

• otelcol_version and version in manifest.yaml files
• OTELCOL_BUILDER_VERSION in Makefile

I think the script should use the --next-beta-core version for the OTELCOL_BUILDER_VERSION in Makefile and for the otelcol_version field in manifests. As for the version field in manifest, it's probably max(next_beta_core, next_beta_contrib). Or we could add a new parameter to the script and action to specify it.

[jackgopack4]

successful release PR in my fork: jackgopack4#22

[jackgopack4]

@andrzej-stencel @mx-psi waiting for checks to run but I feel better about this attempt. incorporated feedback from code review and added changelog step

[jackgopack4]

The script in the current form does not update the following places:

• otelcol_version and version in manifest.yaml files
• OTELCOL_BUILDER_VERSION in Makefile

I think the script should use the --next-beta-core version for the OTELCOL_BUILDER_VERSION in Makefile and for the otelcol_version field in manifests. As for the version field in manifest, it's probably max(next_beta_core, next_beta_contrib). Or we could add a new parameter to the script and action to specify it.

addressed both of these. well for version I just set it to next beta core, but if we run into the issue where contrib is updated but core isn't we can address it then.

[andrzej-stencel]

Thank you for your patience with my comments @jackgopack4. Just a couple small things and this will be ready to merge.

[andrzej-stencel]

Thanks Jack!