Label PRs with change type according to changelog

[lmolkova]

This allows to label PRs as "breaking" simplifying filtering and querying breaking changes before they are released.

Tested here lmolkova#6

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• schema-next.yaml updated with changes to existing conventions.

[trask]

I suspect this only worked in your test because the PR wasn't from a forked repo:

https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#workflows-in-forked-repositories

The GITHUB_TOKEN has read-only permissions in pull requests from forked repositories.

this kind of automation probably requires pull_request_target, which brings security considerations

[lmolkova]

It was necessary in my fork and failed without it.
`I assume it should not even be necessary in the original repo since

semantic-conventions/.github/workflows/scripts/prepare-new-issue.sh

Line 67 in e73d500

gh issue edit "${ISSUE}" --add-label "${LABELS}" || true

runs perfectly fine without any permissions

[lmolkova]

thanks! yeah, you're right.

So the pull_request_target executes workflows from the target branch (main) where the GH_TOKEN will be exposed to the version of this script checked into main. Is there any security concern with it?

I believe it's used today by collector and .net and in the https://github.com/open-telemetry/assign-reviewers-action, so I assume it's considered to be safe and ok to use

[trask]

I believe it's used today by collector and .net and in the https://github.com/open-telemetry/assign-reviewers-action

these don't also check out the PR branch though, which is where things get tricky

e.g. you don't want to run a build on the PR branch, since PR could modify the build steps and print out secrets

your automation only needs to read a file, which sounds safe, but I'm not sure if the checkout alone could be compromised, e.g. by a post-checkout hook that prints out secrets (I'll test this... now I'm curious...)

[trask]

ah, git hooks have to be explicitly enabled after checkout, e.g. git config --local core.hooksPath .githooks/, so that seems safe

I'm good with pursuing this, just want to be careful about it

[trask]

I think this defaults to checking out main after switching to pull_request_target (I suspect due to the security concerns), I think need:

Suggested change

	- uses: actions/checkout@v4
	- uses: actions/checkout@v4
	with:
	ref: ${{ github.head_ref }}

[joaopgrassi]

Trick here, because people may forget to add the changelog and this will only run on PR open. Once they add it later no label will be there. Maybe we also have to run it on push?