RUM-16661: Add dogfooding branch infrastructure#3519
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #3519 +/- ##
===========================================
- Coverage 72.34% 72.19% -0.15%
===========================================
Files 965 965
Lines 35609 35609
Branches 5933 5933
===========================================
- Hits 25760 25705 -55
- Misses 8255 8291 +36
- Partials 1594 1613 +19 🚀 New features to boost your workflow:
|
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6e0c555e70
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| echo "Committing version patch..." | ||
| git add "$ANDROID_CONFIG" | ||
| git commit -m "Reset dogfooding branch to develop" |
There was a problem hiding this comment.
Generate policy-compliant reset commits
When this script is used to reset dogfooding, it creates the pushed commit with a non-ticketed title and no explicit signing. The repo instructions in AGENTS.md require all commits to be GPG-signed and titled RUM-XXXXX: <short description>, so in environments without commit.gpgsign=true or with server-side commit-message/signature checks this reset can be rejected or leave policy-violating commits on the long-lived branch. Please sign the commit and use a RUM-ticketed title.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
About the commit title: RUM-XXXXX: <short description> I think that's acceptable.
require all commits to be GPG-signed
For the moment, we'll use the script locally so the scripts will be signed with the local configuration. We can iterate on this if necessary.
There was a problem hiding this comment.
| test-pyramid:legacy-integration-instrumented-median-api: | ||
| extends: | ||
| - .base-cache-pull-job | ||
| - .except-dogfooding-branch |
There was a problem hiding this comment.
If most of the jobs are disabled in the dogfooding branch, we could create a dedicated yaml for its CI and route to it like this.
However I'm not sure that we need to skip our usual tests in the dogfooding branch. It is more-or-less the same situation as the develop branch.
| paths: | ||
| - "**/verification-metadata.xml" | ||
|
|
||
| publish:snapshot-dogfooding: |
There was a problem hiding this comment.
In the develop branch we use the publish:release-all job. Why can't we reuse it here?
What does this PR do?
Adds the infrastructure needed to support a long-lived
dogfoodingbranch that publishesx.y.z-dogfooding-SNAPSHOTMaven artifacts for internal dogfooding of in-flight features before they land ondevelop.Motivation
The team needs a structured way to dogfood in-flight SDK features in the Datadog Android app and Shopist Android, mirroring what the iOS SDK already does with its
dogfoodingbranch. Previous ad-hoc approaches (e.g.bplasovska/feature/timeseries-dogfooding) were undiscoverable, one-off, and required consumers to update their version string for every feature.Additional Notes
Version.Type.Snapshotis extended from a singletonobjectto adata classwith an optional label —Snapshot("dogfooding")→x.y.z-dogfooding-SNAPSHOT,Snapshot()→x.y.z-SNAPSHOT(develop behaviour unchanged).dogfoodingbranch via.except-dogfooding-branch; only the new manualpublish:snapshot-dogfoodingjob runs there.ci/scripts/reset-dogfooding.shautomates resetting thedogfoodingbranch todevelopHEAD and re-applying the version label — run after a feature graduates todevelop.Review checklist (to be filled by reviewers)