{{ message }}
[APPS-2784] feat(apps): add description, selfService, permissions to manifest and config#446
Merged
gh-worker-dd-mergequeue-cf854d[bot] merged 6 commits intoJul 2, 2026
Conversation
… config Exposes the three new fields that app-builder-code (ddoghq/dd-source#8713) added support for server-side: - description: human-readable app description - selfService: whether the app appears in the self-service catalog - permissions.protectionLevel: direct_publish | approval_required - permissions.runAs: service account UUID for backend function execution Fields flow from AppsOptions (vite.config.ts) into the generated manifest.json bundle, which app-builder-code reads on upload and applies via the appropriate app-builder-api endpoints. Omitting any field leaves the existing value unchanged on the server. Refs: APPS-2784
Contributor
Author
|
@codex review |
|
To use Codex here, create a Codex account and connect to github. |
Contributor
Author
|
@cursor review |
There was a problem hiding this comment.
Pull request overview
Adds support in the Apps build plugin for configuring additional app metadata and deployment/identity settings (description, selfService, permissions.protectionLevel, permissions.runAs) so they can be emitted into the generated manifest.json and applied by the upload pipeline.
Changes:
- Extend
AppsOptions/AppsManifesttypes withdescription,selfService, andpermissions(includingAppsProtectionLevel). - Plumb the new options through validation/default-resolution and into
manifest.jsongeneration. - Add unit tests and README documentation for the new configuration fields.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Previously description, selfService, and permissions were always present in the returned object (with undefined values) even when the caller did not configure them. This changed the observable shape of AppsOptionsWithDefaults and could pass null values through to the manifest builder if a caller explicitly passed null. Use conditional spreading so the keys are absent entirely when the option is not provided, and guard against null via != null. Update the test to assert key absence with not.toHaveProperty() rather than toBeUndefined(). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Assigning options.permissions directly to manifest.permissions would
pass through null subfield values (e.g. { protectionLevel: null }) since
they satisfy the !== undefined guard. The server does not accept null as
a valid permissions value and null subfields are observably different
from absent keys.
Reconstruct the permissions object from only non-null subfields, and
align description/selfService guards to use != null consistently with
validate.ts. Add a test covering the null-subfield case.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
buildManifest now uses != null throughout; update the test comment to match so the documentation stays accurate. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
sdkennedy2
approved these changes
Jul 2, 2026
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
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.

Motivation
app-builder-codeservice (ddoghq/dd-source#8713) now acceptsdescription,selfService,permissions.protectionLevel, andpermissions.runAsin the uploadedmanifest.json. Previously there was no way to set these from the build plugin — developers had to configure them manually in the App Builder UI after each deploy.Changes
AppsProtectionLeveltype anddescription,selfService,permissionsfields toAppsOptionsandAppsManifestsrc/types.tsAppsOptionsWithDefaults; omit entirely when unset so callers usingin/hasOwnPropertysee a stable shapesrc/validate.tsdescription,selfService,permissionsintomanifest.jsononly when configured; reconstruct permissions from non-null subfields only to prevent null values or empty objects reaching the serversrc/vite/handle-upload.tsselfService:falsepreserved,runAsincluded, emptypermissions:{}omitted, null subfields strippedsrc/index.test.tsvalidateOptions; keys absent entirely (notundefined) when not configuredsrc/validate.test.tsdescription,selfService,permissions.protectionLevel,permissions.runAsconfig options with defaults and behaviourREADME.mdArchitecture
Fields configured in
vite.config.tsflow into the generatedmanifest.jsonbundle, whichapp-builder-codereads on upload and applies via the appropriateapp-builder-apiendpoints. Omitting any field leaves the existing server-side value unchanged.Example
vite.config.ts:QA Instructions
Test URL: local Vite build — no service required for manifest verification.
1. Build and test
2. Local manifest verification
In any Vite app using
@datadog/vite-plugin:3. Staging end-to-end
Using the
apps-2780-qaTD (still live from ddoghq/dd-source#8713) withdd-auth --actions-api --domain dd.datad0g.com:Blast Radius
Documentation