Skip to content

ci: allow dd-trace-*/libdatadog to write pr comments on libdatadog #2133

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
igoragoli wants to merge 1 commit into
base: main
Choose a base branch
from
+6 −0
Open

ci: allow dd-trace-*/libdatadog to write pr comments on libdatadog #2133

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions .github/chainguard/gitlab.write.benchmarking-pr-comments.sts.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
issuer: https://gitlab.ddbuild.io

subject_pattern: "project_path:DataDog/apm-reliability/(dd-trace-.*|libdatadog):.*"

permissions:
pull_requests: write
Comment on lines +3 to +6

@ekump ekump Jun 18, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@yannham yannham Jun 19, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 a version of libdatadog corresponding to q 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!

Loading