ci: allow dd-trace-*/libdatadog to write pr comments on libdatadog#2133
Open
igoragoli wants to merge 1 commit into
Open
ci: allow dd-trace-*/libdatadog to write pr comments on libdatadog#2133igoragoli wants to merge 1 commit into
igoragoli wants to merge 1 commit into
Conversation
Contributor
|
🎯 Code Coverage (details) 🔗 Commit SHA: 95e60dc | Docs | Datadog PR Page | Give us feedback! |
Contributor
Artifact Size Benchmark Reportaarch64-alpine-linux-musl
aarch64-unknown-linux-gnu
libdatadog-x64-windows
libdatadog-x86-windows
x86_64-alpine-linux-musl
x86_64-unknown-linux-gnu
|
ekump
reviewed
Jun 18, 2026
Comment on lines
+3
to
+6
| subject_pattern: "project_path:DataDog/apm-reliability/(dd-trace-.*|libdatadog):.*" | ||
|
|
||
| permissions: | ||
| pull_requests: write |
Collaborator
There was a problem hiding this comment.
Suggested change
| subject_pattern: "project_path:DataDog/apm-reliability/(dd-trace-.*|libdatadog):.*" | |
| permissions: | |
| pull_requests: write | |
| subject_pattern: "project_path:DataDog/apm-reliability/dd-trace-[a-z0-9-]+:ref_type:branch:ref:(main|master)" | |
| claim_pattern: | |
| project_path: "DataDog/apm-reliability/dd-trace-[a-z0-9-]+" | |
| ref_type: "branch" | |
| ref_protected: "true" | |
| pipeline_source: "pipeline" | |
| ci_config_ref_uri: "gitlab.ddbuild.io/DataDog/apm-reliability/dd-trace-[a-z0-9-]+//.gitlab-ci.yml@refs/heads/(main|master)" | |
| permissions: | |
| pull_requests: write |
The policy as-is is too lax. I don't think libdatadog should be included as a subject as we already have benchmark jobs triggered internally and use a different existing policy. They shouldn't share a policy with this workflow.
I don't know how these benchmarks are going to work, but my suggestion assumes they are going to run on the default branch of the SDKs.
Contributor
There was a problem hiding this comment.
The current plan is to have those benchmarks run on some branch of the SDK/tracers (but not the default one, since the idea is to auto update the SDK to some version of libdatadog corresponding to a PR, so this will be on a new, dedicated branch). At some point this SDK benchmark job needs to write back a comment here to report the result, which I think is the goal of this policy change. Hopes that clarifies. But also maybe there's a better way to orchestrate all of this, so open to suggestions here!
Collaborator
There was a problem hiding this comment.
Got it. If it's a dedicated branch then my suggestion would still mostly work. You'd just need to update it to match on that branch name instead of main/master.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Allows dd-trace-* and libdatadog to write PR comments on libdatadog.
Motivation
libdatadog will run benchmarks by triggering downstream dd-trace-* pipelines. Those pipelines need to report results back to libdatadog. One way to report results back is through PR comments.
Additional Notes
This policy can be tightened to make it absolutely secure, but the risks it incurs (an attacker might create PR comments on branches on dd-trace-* repos' CIs) are too low compared to the complexity of setting up and testing a more fleshed-out policy.
I'd be happy to update the policy if these risks are something we should address :)
How to test the change?
Should be verified ad-hoc with prototype PR comments, due to how dd-octo-sts works. Changes need to be on
mainto be effective.