feat: support sf/sfdx retrieve & deploy of recursively-foldered TagSet - #1806
Draft
awarshavsky wants to merge 1 commit into
Draft
feat: support sf/sfdx retrieve & deploy of recursively-foldered TagSet#1806awarshavsky wants to merge 1 commit into
awarshavsky wants to merge 1 commit into
Conversation
Add TagSet registry entry (inFolder for unbounded recursive foldering) and translate the on-disk slash-separated fullName to the org's dot-separated TagSet contract in constructFullName. Verified by a ComponentSet.getObject test asserting A/B/C to A.B.C in the package manifest.
|
Thanks for the contribution! It looks like @awarshavsky is an internal user so signing the CLA is not required. However, we need to confirm this. |
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
1 participant
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.
DRAFT — internal review before engaging the CLI team. Do not merge.
Problem
sf project retrieve start -m TagSet:...fails withRegistryError: Missing metadata type definition in registry for id 'TagSet'— SDR has no registry entry for Tag/TagSet, so the command errors before contacting the org.Shape of the metadata
Core's Metadata API returns TagSet with a dotted
fullName(A.B.C) and a recursively-folderedfileName(tagSet/A/B/C.tagSet). Nested tag sets fold by parent-set identity, unbounded depth.Fix (3 files)
TagSetwithinFolder: true. This reuses the existing Report/Dashboard unbounded-folder mechanism (parseNestedFullName+calculateRelativePath), giving correct recursive foldering on retrieve-write for free.inFolderyields a slash-separated fullName on disk (A/B/C), but the TagSet MDAPI contract is dot-separated (A.B.C). Added aTagSetcase inconstructFullName, symmetric to the existingReportFolder/DashboardFolderspecial-cases, that translates/to.for the manifest.ComponentSet.getObject()assertsA/B/Cproduces<members>A.B.C</members>.Open question for CLI team
Tag/TagSet are v66+. SDR has no per-type API-version gating; that convention is the CLI team's call (ComponentSet layer or registry coverage).
Prerequisite
Server-side listMetadata foldering is fixed by Core W-23465184 (already committed).