[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/11297355358
As well as the generated PR in my fork:
jackgopack4#19

This is obviously not required to be used, but since I have already updated the documentation in core repo for release: open-telemetry/opentelemetry-collector#11234, I split this file out of the ocb docker release PR (#671) to make this easier to merge in prior to v0.111.0 release

EDIT: I have added stable and beta version update capability. One of either 'stable' or 'beta' arguments are needed, and if a 'next' stable/beta version is not provided, then minor version will be bumped by default (e.g. v0.110.0 -> v0.111.0).

This can be overridden by providing a manual version number update (like v0.110.0 -> v0.110.1, as in my sample run)

[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 logs errors trying to remove non-existent .bak files when run with only the --current-beta-contrib flag:

./.github/workflows/scripts/bump-versions.sh --current-beta-contrib v0.111.0
rm: cannot remove '/tmp/tmp.h6AQVOKLTG.bak': No such file or directory
rm: cannot remove '/tmp/tmp.VsQcTga32N.bak': No such file or directory
Version update completed.
Changes not committed and PR not created.

I propose to add an existence check before removing the .bak files.

Suggested change

	rm "${temp_file}.bak"
	[ -f "${temp_file}.bak" ] && rm "${temp_file}.bak"

[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.

[andrzej-stencel]

Why does the script run sed for each line separately? Putting efficiency aside, this seems harder to understand than just running sed on the whole file(s). The replacement patterns are also less precise. For example, there are lines in Makefile that have github.com/open-telemetry/opentelemetry-collector-contrib in them, but are not subject to replacements.

I would imagine running the sed command on the whole files and specifying the replacement patterns specifically for each purpose. For example:

• to replace core versions in manifests: sed "s/\(^.*go\.opentelemetry\.io\/collector\/.*\) v0\.111\.0/\1 v0.112.0/" distributions/otelcol/manifest.yaml
• to replace otelcol_version in manifests: sed "s/\(^\s\+otelcol_version:\) 0\.111\.0/\1 0.112.0/" distributions/otelcol/manifest.yaml
• etc.

[andrzej-stencel]

Thinking about this more, do we actually even need the "current" versions from the user? Seems that we can read the current versions from the manifest files, e.g. with awk:

$ current_beta_core=$(awk '/^.*go\.opentelemetry\.io\/collector\/.* v0/ {print $4; exit}' distributions/otelcol/manifest.yaml)
$ echo $current_beta_core
v0.111.0