Update (or create) opentelemetrybot/semantic-conventions-v* branch daily

[trask]

Attempting to automate parts of open-telemetry/semantic-conventions#1817

This daily action will check if there's an existing opentelemetrybot/semantic-conventions-v* branch, and update that branch with the latest from main and update the semconv submodule with the latest from that repo's main.

If there's no existing opentelemetrybot/semantic-conventions-v* branch, it will create one and open a draft PR against it.

cc @open-telemetry/specs-semconv-maintainers

[trask]

removed since going in a different direction now

[chalin]

I would prefer that the scripts work on a PR branch rather than a dedicated and "permanent" repo branch. We don't need to preserve a continuous history of semconv integration as a part of this repo. A PR branch seems more appropriate IMHO.

Thoughts?

[trask]

would naming it integration/semantic-conventions-1.31.0 be better, to be clear that we merge and delete it with each release?

I could have the script automatically create the branch (and associated PR) if it doesn't find one (meaning we've rolled over to the next release)

[chalin]

Yes, I'd like that: a branch per release that can be closed once the release has landed (hence it becomes a PR branch). Thanks!

[trask]

Yes, I'd like that: a branch per release that can be closed once the release has landed (hence it becomes a PR branch). Thanks!

done, ptal, thanks!

[chalin]

Thanks for working on this. See inline comments.

[chalin]

Hmm, I'm not sure that I'd want to automatically rebase the otel.io repo (that is what this is doing, right?). My gut feeling is that we might want to do this by hand. Maybe introduce a script bool argument to control this? Or just omit it and we can do it fully manually.

[trask]

it's merging from main (no force pushing involved), I can remove it if you'd prefer to do it by hand for now

[chalin]

I'd prefer rebasing, to keep the PR branch clean, and make it easier to cherry pick if/once we want to create a final PR.

But let's leave this as is for now. We can revisit later if necessary.

[chalin]

Ideally, we should be running npm run get:submodule, but that would require that in this step we not only update the submodule commit, but that we change the value of semconv-pin to correspond to the value returned by git describe --tags. Can we do that further below in this step?

[trask]

I updated semconv-pin now, but I'm not sure what npm run get:submodule is for, or when to run it?

[chalin]

Actually, npm run get:submodule is mainly to help local devs sync their submodules to the pinned versions. Come to think of it, we won't need it here.

[chalin]

Looking forward to giving this a spin.