Conversation
Add a new skill to the dotnet-dnceng plugin that automates onboarding .NET repositories onto the dotnet/arcade build system. The skill provides an 8-step workflow: 1. Analyze repository (projects, output types, existing CI, dependencies) 2. Ask user about publishing preferences 3. Create/modify infrastructure files (global.json, Directory.Build.props/targets, eng/Versions.props, eng/Version.Details.xml, NuGet.config, eng/Publishing.props) 4. Copy eng/common/ shared build scripts from arcade 5. Create Azure Pipelines YAML (public CI and/or official builds with 1ES templates) 6. Set up internal mirror (GitHub -> AzDO at dnceng/internal) 7. Map NuGet dependencies to darc/maestro for automatic dependency flow 8. Summarize next steps with ready-to-run darc commands Includes reference docs for file templates, pipeline templates, dependency flow, and internal mirror setup. Also includes a helper script for copying eng/common/. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
rmarinho
requested review from
ViktorHofer,
danmoseley and
lewing
as code owners
Cross-referenced arcade infrastructure patterns against real repos: - eng/Versions.props: use computed VersionPrefix from MajorVersion/ MinorVersion/PatchVersion (matches runtime and aspire pattern), add StabilizePackageVersion property - NuGet.config: update feed from dotnet9 to dotnet10, add transport feed guidance, add packageSourceMapping section to prevent NU1507 - Publishing.props: document ProducesDotNetReleaseShippingAssets and AutoGenerateSymbolPackages optional properties - CPM compatibility: aspire proves Directory.Packages.props works with arcade. Add Option A (keep CPM) and Option B (migrate) guidance - Pipeline templates: note pool images evolve, reference aspire for current values - Add Validation section with cross-reference table to real repos Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Step 8 now: - Checks if darc is installed, offers to install via eng/common/darc-init.sh - Verifies authentication - Generates eng/setup-darc.sh with pre-filled commands for the specific repo - Asks user whether to run now or after merge Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Document PipelineAutobaseliningConfig.yml:
- When to create it (empty pipelines: {} for new repos)
- How 1ES automation populates it with pipeline IDs and SDL
tool baselines (credscan, binskim, eslint, armory, etc.)
- SDL parameters in official pipeline template
- Reference to https://aka.ms/1espt-autobaselining portal
- Updated Step 5 in SKILL.md to check/create the config file
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Learnings from real official build (dnceng/internal #2928792): - packageSourceMapping breaks official builds because SetupNugetSources injects internal feeds not in NuGet.config. Replace guidance with NoWarn NU1507 suppression instead. - Add publishPackages boolean parameter to official pipeline template to gate post-build publishing (DotNetPublishUsingPipelines + post-build stage conditionally included). - Document 1ES auto-baselining first-run warning as expected behavior. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- WiX workaround: MakeDir for missing tools/net472/{Platform} subdirectory
(PackageDownload approach doesn't work - wrong location + missing subfolder)
Verified on dnceng/internal build 2930786
- 1ES NuGet.org publishing: full 1ES.PublishNuget@1 template with
networkIsolationPolicy, releaseJob, useDotNetTask settings
- Post-build service connection: document Darc: Maestro Production
authorization requirement and First Responders channel for approval
- Build verification: comprehensive local build guide with common failures
table, absolute path requirement, workload restore steps
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…onboarding" This reverts commit 0aa4d52.
Adds new sections without overwriting existing content: - Build Verification: local build steps, common failures table - Known Issues: WiX 5 MakeDir workaround (arcade#16611), service connection authorization, 1ES.PublishNuget pattern - Directory.Build.targets template with WiX workaround - NuGet.org publishing with 1ES.PublishNuget@1 reference Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 8 out of 8 changed files in this pull request and generated 8 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review. Take the survey.
plugins/dotnet-dnceng/skills/arcade-onboarding/references/pipeline-templates.md
Outdated
Show resolved
Hide resolved
| # Usage: copy_eng_common.sh [target_repo_root] [arcade_ref] | ||
| # target_repo_root: Path to the repository being onboarded (default: current directory) | ||
| # arcade_ref: Git ref to use (branch/tag/SHA) (default: main) | ||
|
|
plugins/dotnet-dnceng/skills/arcade-onboarding/references/pipeline-templates.md
Show resolved
Hide resolved
plugins/dotnet-dnceng/skills/arcade-onboarding/references/pipeline-templates.md
Show resolved
Hide resolved
| Condition="Exists('$(RepoRoot).packages\microsoft.wixtoolset.sdk\$(MicrosoftWixToolsetSdkVersion)')"> | ||
| <MakeDir Directories="$(RepoRoot).packages\microsoft.wixtoolset.sdk\$(MicrosoftWixToolsetSdkVersion)\tools\net472\x64" | ||
| Condition="!Exists('$(RepoRoot).packages\microsoft.wixtoolset.sdk\$(MicrosoftWixToolsetSdkVersion)\tools\net472\x64')" /> | ||
| <MakeDir Directories="$(RepoRoot).packages\microsoft.wixtoolset.sdk\$(MicrosoftWixToolsetSdkVersion)\tools\net472\arm64" | ||
| Condition="!Exists('$(RepoRoot).packages\microsoft.wixtoolset.sdk\$(MicrosoftWixToolsetSdkVersion)\tools\net472\arm64')" /> |
plugins/dotnet-dnceng/skills/arcade-onboarding/references/pipeline-templates.md
Outdated
Show resolved
Hide resolved
plugins/dotnet-dnceng/skills/arcade-onboarding/references/file-templates.md
Show resolved
Hide resolved
- New Step 5b: Configure Signing with full architecture explanation - eng/Signing.props template with certificate types and 3rd-party DLL guide - eng/SignCheckExclusionsFile.txt template (separate from Signing.props) - Critical pipeline parameters table (enableMicrobuild, enablePublishBuildAssets) - Fixed official pipeline template: removed obsolete V2 parameters - Added _SignType variable and MicroBuild signing flow explanation - Documented dual exclusion mechanism (build-time vs post-build validation) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Remove internal Teams deep link, keep channel name reference - Remove eng.ms internal doc links, replace with descriptions - Fix copy_eng_common.sh: document branch/tag only (not SHA) - Clarify RepoRoot .packages path in WiX workaround docs Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 8 out of 8 changed files in this pull request and generated 4 comments.
Comments suppressed due to low confidence (1)
plugins/dotnet-dnceng/skills/arcade-onboarding/references/file-templates.md:331
- There is an extra trailing Markdown code fence at the end of the file (a lone ``` after the SignCheckExclusions section). This breaks Markdown rendering for the end of the document; please remove the stray fence.
**Important:** This file must be consistent with `Signing.props`. If you set `CertificateName="None"` for `.js` in `Signing.props`, you must also exclude `*.js` in `SignCheckExclusionsFile.txt`. Otherwise the post-build validation will flag those files as unsigned.
**Reference:** Pattern from [dotnet/Scaffolding](https://github.com/dotnet/Scaffolding/blob/main/eng/SignCheckExclusionsFile.txt).
</details>
---
💡 <a href="/dotnet/arcade-skills/new/main?filename=.github/instructions/*.instructions.md" class="Link--inTextBlock" target="_blank" rel="noopener noreferrer">Add Copilot custom instructions</a> for smarter, more guided reviews. <a href="https://docs.github.com/en/copilot/customizing-copilot/adding-repository-custom-instructions-for-github-copilot" class="Link--inTextBlock" target="_blank" rel="noopener noreferrer">Learn how to get started</a>.
| - [NuGet.config](#nugetconfig) | ||
| - [eng/Publishing.props](#engpublishingprops) |
There was a problem hiding this comment.
The Table of Contents has duplicate entries for NuGet.config and eng/Publishing.props (listed twice). This makes the reference harder to navigate; please remove the duplicates so each section appears once.
| - [NuGet.config](#nugetconfig) | |
| - [eng/Publishing.props](#engpublishingprops) |
| @@ -0,0 +1,613 @@ | |||
| --- | |||
| name: arcade-onboarding | |||
| description: "Onboard a .NET repository onto the dotnet/arcade build system. Use when a user wants to adopt Arcade SDK for building, versioning, signing, packaging, and publishing .NET projects. Handles creating or modifying global.json, Directory.Build.props/targets, eng/Versions.props, eng/Version.Details.xml, NuGet.config, eng/common/ scripts, Azure Pipelines YAML, and eng/Publishing.props. Supports configuring NuGet.org publishing (shipping vs non-shipping), setting up GitHub-to-AzDO internal mirror for official builds, identifying NuGet dependencies that can be replaced with darc/maestro dependency flow, and setting up subscriptions for automatic dependency updates. Triggers: 'arcade onboarding', 'onboard arcade', 'arcade SDK', 'dotnet arcade', 'arcade build system', 'dependency flow', 'darc onboarding', 'maestro setup', 'arcade publishing', 'internal mirror', 'dnceng mirror', or any request about adopting the .NET Arcade infrastructure." | |||
There was a problem hiding this comment.
The front-matter description is a single very long quoted line. Other skills in this repo (e.g., skills/ci-analysis/SKILL.md) use YAML folded style (description: >) for readability and to avoid tooling/linters choking on extremely long lines; consider switching to the folded style here as well.
| description: "Onboard a .NET repository onto the dotnet/arcade build system. Use when a user wants to adopt Arcade SDK for building, versioning, signing, packaging, and publishing .NET projects. Handles creating or modifying global.json, Directory.Build.props/targets, eng/Versions.props, eng/Version.Details.xml, NuGet.config, eng/common/ scripts, Azure Pipelines YAML, and eng/Publishing.props. Supports configuring NuGet.org publishing (shipping vs non-shipping), setting up GitHub-to-AzDO internal mirror for official builds, identifying NuGet dependencies that can be replaced with darc/maestro dependency flow, and setting up subscriptions for automatic dependency updates. Triggers: 'arcade onboarding', 'onboard arcade', 'arcade SDK', 'dotnet arcade', 'arcade build system', 'dependency flow', 'darc onboarding', 'maestro setup', 'arcade publishing', 'internal mirror', 'dnceng mirror', or any request about adopting the .NET Arcade infrastructure." | |
| description: > | |
| Onboard a .NET repository onto the dotnet/arcade build system. Use when a user wants to adopt Arcade SDK for building, versioning, signing, packaging, and publishing .NET projects. Handles creating or modifying global.json, Directory.Build.props/targets, eng/Versions.props, eng/Version.Details.xml, NuGet.config, eng/common/ scripts, Azure Pipelines YAML, and eng/Publishing.props. Supports configuring NuGet.org publishing (shipping vs non-shipping), setting up GitHub-to-AzDO internal mirror for official builds, identifying NuGet dependencies that can be replaced with darc/maestro dependency flow, and setting up subscriptions for automatic dependency updates. Triggers: 'arcade onboarding', 'onboard arcade', 'arcade SDK', 'dotnet arcade', 'arcade build system', 'dependency flow', 'darc onboarding', 'maestro setup', 'arcade publishing', 'internal mirror', 'dnceng mirror', or any request about adopting the .NET Arcade infrastructure. |
| TARGET_ENG="$TARGET_ROOT/eng" | ||
| mkdir -p "$TARGET_ENG" | ||
|
|
||
| if [ -d "$TARGET_ENG/common" ]; then | ||
| echo "==> Removing existing eng/common/..." | ||
| rm -rf "$TARGET_ENG/common" | ||
| fi |
There was a problem hiding this comment.
copy_eng_common.sh will unconditionally rm -rf "$TARGET_ROOT/eng/common" without validating TARGET_ROOT. A typo (or running from an unexpected directory) could delete the wrong tree. Consider adding guardrails (e.g., require $TARGET_ROOT to exist and contain a .git directory, refuse /, and/or require an explicit --force to delete an existing eng/common).
| # Arcade Onboarding | ||
|
|
||
| Onboard a .NET repository onto the [dotnet/arcade](https://github.com/dotnet/arcade) build system, enabling shared tooling for versioning, signing, packaging, publishing, and CI/CD via Azure Pipelines with dependency flow through darc/maestro. | ||
|
|
||
| ## Onboarding Workflow |
There was a problem hiding this comment.
SKILL.md body is 609+ lines, which will fail the repo's pr-validation check (MaxBodyLines = 500 in .github/workflows/pr-validation.yml). To unblock CI, move more of the detailed guidance (e.g., long signing architecture, known issues, build verification) into reference files and keep SKILL.md as a shorter workflow that links out.
Uncomment and recommend PreReleaseVersionIteration in the eng/Versions.props
template. With this set to 1, packages version as preview.1.{build_number}
instead of preview.{build_number}, giving clearer NuGet sort order.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Document the PrepareArtifacts + PublishNuGet two-job pattern required for 1ES releaseJob SBOM validation. PackageArtifacts published by Arcade lack SBOM manifest - must re-publish through templateContext outputs to generate it before the releaseJob can consume it. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 8 out of 8 changed files in this pull request and generated 4 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| description: "Onboard a .NET repository onto the dotnet/arcade build system. Use when a user wants to adopt Arcade SDK for building, versioning, signing, packaging, and publishing .NET projects. Handles creating or modifying global.json, Directory.Build.props/targets, eng/Versions.props, eng/Version.Details.xml, NuGet.config, eng/common/ scripts, Azure Pipelines YAML, and eng/Publishing.props. Supports configuring NuGet.org publishing (shipping vs non-shipping), setting up GitHub-to-AzDO internal mirror for official builds, identifying NuGet dependencies that can be replaced with darc/maestro dependency flow, and setting up subscriptions for automatic dependency updates. Triggers: 'arcade onboarding', 'onboard arcade', 'arcade SDK', 'dotnet arcade', 'arcade build system', 'dependency flow', 'darc onboarding', 'maestro setup', 'arcade publishing', 'internal mirror', 'dnceng mirror', or any request about adopting the .NET Arcade infrastructure." | ||
| --- | ||
|
|
||
| # Arcade Onboarding | ||
|
|
||
| Onboard a .NET repository onto the [dotnet/arcade](https://github.com/dotnet/arcade) build system, enabling shared tooling for versioning, signing, packaging, publishing, and CI/CD via Azure Pipelines with dependency flow through darc/maestro. | ||
|
|
There was a problem hiding this comment.
SKILL.md frontmatter description is a single very long quoted line. Repo validation enforces a max description length of 1024 chars; this looks likely to exceed the limit and will fail PR validation. Consider shortening the description to a brief summary and moving trigger phrases/details into the body or a reference file.
| description: "Onboard a .NET repository onto the dotnet/arcade build system. Use when a user wants to adopt Arcade SDK for building, versioning, signing, packaging, and publishing .NET projects. Handles creating or modifying global.json, Directory.Build.props/targets, eng/Versions.props, eng/Version.Details.xml, NuGet.config, eng/common/ scripts, Azure Pipelines YAML, and eng/Publishing.props. Supports configuring NuGet.org publishing (shipping vs non-shipping), setting up GitHub-to-AzDO internal mirror for official builds, identifying NuGet dependencies that can be replaced with darc/maestro dependency flow, and setting up subscriptions for automatic dependency updates. Triggers: 'arcade onboarding', 'onboard arcade', 'arcade SDK', 'dotnet arcade', 'arcade build system', 'dependency flow', 'darc onboarding', 'maestro setup', 'arcade publishing', 'internal mirror', 'dnceng mirror', or any request about adopting the .NET Arcade infrastructure." | |
| --- | |
| # Arcade Onboarding | |
| Onboard a .NET repository onto the [dotnet/arcade](https://github.com/dotnet/arcade) build system, enabling shared tooling for versioning, signing, packaging, publishing, and CI/CD via Azure Pipelines with dependency flow through darc/maestro. | |
| description: "Onboard a .NET repository onto the dotnet/arcade build system, setting up shared build, packaging, publishing, and dependency-flow infrastructure." | |
| --- | |
| # Arcade Onboarding | |
| Onboard a .NET repository onto the [dotnet/arcade](https://github.com/dotnet/arcade) build system, enabling shared tooling for versioning, signing, packaging, publishing, and CI/CD via Azure Pipelines with dependency flow through darc/maestro. | |
| **Typical trigger phrases / intents:** "arcade onboarding", "onboard arcade", "arcade SDK", "dotnet arcade", "arcade build system", "dependency flow", "darc onboarding", "maestro setup", "arcade publishing", "internal mirror", "dnceng mirror", or any request about adopting the .NET Arcade infrastructure. |
| 1. **Analyze the repository** — scan for projects, output types, existing CI, NuGet dependencies | ||
| 2. **Ask the user** about publishing preferences (NuGet.org yes/no, shipping scope) | ||
| 3. **Create/modify infrastructure files** — global.json, Directory.Build.props/targets, eng/ files, NuGet.config | ||
| 4. **Copy eng/common/** — arcade shared build scripts | ||
| 5. **Create Azure Pipelines YAML** — public CI and/or official build definitions | ||
| 6. **Set up internal mirror** — configure GitHub → AzDO mirror for official builds | ||
| 7. **Map dependencies to darc/maestro** — convert eligible NuGet references to flowable dependencies | ||
| 8. **Summarize next steps** — darc setup, subscriptions, channel assignments | ||
|
|
||
| ## Step 1: Analyze the Repository | ||
|
|
||
| Before making any changes, perform a thorough analysis: | ||
|
|
||
| ### Scan for projects | ||
| ```bash | ||
| find . -name "*.csproj" -o -name "*.fsproj" -o -name "*.vbproj" | head -50 | ||
| find . -name "*.sln" | head -10 | ||
| ``` | ||
|
|
||
| ### Determine output types for each project | ||
| Read each csproj and check: | ||
| - `<OutputType>` — Exe, Library, WinExe | ||
| - `<IsPackable>` — whether it produces a NuGet package | ||
| - `<PackageId>` — custom package ID if set | ||
| - `<GeneratePackageOnBuild>` — auto-pack on build | ||
| - `<TargetFramework>` / `<TargetFrameworks>` — target platforms | ||
|
|
There was a problem hiding this comment.
This SKILL.md is very large; repository PR validation enforces a maximum of 500 body lines per skill (to keep skills concise and push details into references). This file is >500 lines, so the PR will fail validation unless content is moved out (e.g., Build Verification / Known Issues into references) and the main workflow is trimmed.
| 1. **Analyze the repository** — scan for projects, output types, existing CI, NuGet dependencies | |
| 2. **Ask the user** about publishing preferences (NuGet.org yes/no, shipping scope) | |
| 3. **Create/modify infrastructure files** — global.json, Directory.Build.props/targets, eng/ files, NuGet.config | |
| 4. **Copy eng/common/** — arcade shared build scripts | |
| 5. **Create Azure Pipelines YAML** — public CI and/or official build definitions | |
| 6. **Set up internal mirror** — configure GitHub → AzDO mirror for official builds | |
| 7. **Map dependencies to darc/maestro** — convert eligible NuGet references to flowable dependencies | |
| 8. **Summarize next steps** — darc setup, subscriptions, channel assignments | |
| ## Step 1: Analyze the Repository | |
| Before making any changes, perform a thorough analysis: | |
| ### Scan for projects | |
| ```bash | |
| find . -name "*.csproj" -o -name "*.fsproj" -o -name "*.vbproj" | head -50 | |
| find . -name "*.sln" | head -10 | |
| ``` | |
| ### Determine output types for each project | |
| Read each csproj and check: | |
| - `<OutputType>` — Exe, Library, WinExe | |
| - `<IsPackable>` — whether it produces a NuGet package | |
| - `<PackageId>` — custom package ID if set | |
| - `<GeneratePackageOnBuild>` — auto-pack on build | |
| - `<TargetFramework>` / `<TargetFrameworks>` — target platforms | |
| 1. **Analyze the repository** — understand projects, outputs, existing CI, and NuGet dependencies. | |
| 2. **Confirm publishing preferences** — NuGet.org usage, shipping vs. non-shipping assets, and release cadence. | |
| 3. **Set up Arcade infrastructure files** — `global.json`, `Directory.Build.props/targets`, `eng/*`, `NuGet.config`, and `eng/common/`. | |
| 4: **Configure CI and official builds** — Azure Pipelines YAML, internal mirrors (GitHub → AzDO), and signing/publishing stages. | |
| 5. **Enable dependency flow** — map eligible dependencies to darc/maestro and agree on channel/subscription strategy. | |
| For a detailed, step-by-step onboarding checklist (including example commands and project classification guidance), see the Arcade onboarding reference documentation in the dotnet/arcade repo or your team’s internal onboarding guide. | |
| ## Step 1: Analyze the Repository | |
| Before making any changes, get a clear inventory of the repository’s solutions, projects, and outputs (libraries, tools, applications, and tests), and identify which components are shipping versus internal-only. Focus on what needs to be packaged and published, what is test-only, and any existing CI or publishing pipelines that Arcade will replace or complement. | |
| > Detailed scanning commands and classification heuristics have been moved to external documentation to keep this skill concise. |
| ## global.json | ||
|
|
||
| The `global.json` must reference the Arcade SDK and optionally the Helix SDK. Use the latest stable Arcade SDK version from the `.NET Eng - Latest` channel. | ||
|
|
||
| ```json | ||
| { | ||
| "tools": { | ||
| "dotnet": "9.0.100" | ||
| }, | ||
| "msbuild-sdks": { | ||
| "Microsoft.DotNet.Arcade.Sdk": "<ARCADE_SDK_VERSION>" | ||
| } | ||
| } | ||
| ``` |
There was a problem hiding this comment.
The first global.json template omits the standard sdk section and only sets tools.dotnet. Some tooling (e.g., actions/setup-dotnet with global-json-file) relies on sdk.version, so the template can lead to broken CI if copied verbatim. Recommend including an sdk section (or clarifying when tools-only is acceptable) in the primary template.
| **Important:** This file must be consistent with `Signing.props`. If you set `CertificateName="None"` for `.js` in `Signing.props`, you must also exclude `*.js` in `SignCheckExclusionsFile.txt`. Otherwise the post-build validation will flag those files as unsigned. | ||
|
|
||
| **Reference:** Pattern from [dotnet/Scaffolding](https://github.com/dotnet/Scaffolding/blob/main/eng/SignCheckExclusionsFile.txt). | ||
| ``` |
There was a problem hiding this comment.
There is a stray/unmatched Markdown code fence at the end of the file (an extra ``` after the final paragraph). This will break rendering for everything after it (and can trip markdown linters). Remove the extra fence.
| ``` |
MicroBuild signing activates CFS that blocks NuGet.org even with Permissive network policy. NuGet.org publishing must be a separate pipeline without MicroBuild stages. Updated templates and SKILL.md with the proven pattern from dotnet/aspire. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Someone who knows the domain should review. Just curious, is there anything here that we wouldn't include in human targeted docs (and maybe is already)? In which case I wonder whether the right pattern for the skill is just one line "see docs\foo.md" because we'll have 2 places |
- Add es-metadata.yml to skill description and triggers - Add Step 2 prompt for Service Tree ID and area path (with placeholders) - Map IsShipping → isProduction for 1ES inventory metadata - Add es-metadata.yml as item 10 in file creation order - Add validation cross-check against dotnet/maui, aspire, runtime - Add full es-metadata.yml template to file-templates.md with field descriptions, reference examples, and placeholder handling - Fix Step 2 numbering after inserting new prompt Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 8 out of 8 changed files in this pull request and generated 4 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| - [NuGet.config](#nugetconfig) | ||
| - [eng/Publishing.props](#engpublishingprops) |
There was a problem hiding this comment.
The Table of Contents contains duplicate entries for NuGet.config and eng/Publishing.props. This makes anchors ambiguous/confusing for readers; remove the duplicates so each file appears once.
| - [NuGet.config](#nugetconfig) | |
| - [eng/Publishing.props](#engpublishingprops) |
| **Important:** This file must be consistent with `Signing.props`. If you set `CertificateName="None"` for `.js` in `Signing.props`, you must also exclude `*.js` in `SignCheckExclusionsFile.txt`. Otherwise the post-build validation will flag those files as unsigned. | ||
|
|
||
| **Reference:** Pattern from [dotnet/Scaffolding](https://github.com/dotnet/Scaffolding/blob/main/eng/SignCheckExclusionsFile.txt). | ||
| ``` |
There was a problem hiding this comment.
There is an extra standalone Markdown code fence (```), after the SignCheckExclusionsFile reference, which will break formatting for the remainder of the document. Remove the stray fence so subsequent sections render correctly.
| ``` |
| if ! command -v darc &>/dev/null && [ ! -f ~/.dotnet/tools/darc ]; then | ||
| echo "Installing darc CLI..." | ||
| ./eng/common/darc-init.sh |
There was a problem hiding this comment.
The darc setup script template only adds ~/.dotnet/tools to PATH when it installs darc. If darc is already installed as a dotnet tool but not on PATH, the script will skip installation and then fail when calling darc .... Adjust the logic to (a) add ~/.dotnet/tools to PATH whenever ~/.dotnet/tools/darc exists, and (b) only run darc-init.sh when darc truly isn't installed.
| if ! command -v darc &>/dev/null && [ ! -f ~/.dotnet/tools/darc ]; then | |
| echo "Installing darc CLI..." | |
| ./eng/common/darc-init.sh | |
| if command -v darc &>/dev/null; then | |
| # darc is already available on PATH; nothing to do | |
| elif [ -f "$HOME/.dotnet/tools/darc" ]; then | |
| # darc is installed as a dotnet tool but not on PATH | |
| export PATH="$HOME/.dotnet/tools:$PATH" | |
| else | |
| echo "Installing darc CLI..." | |
| ./eng/common/darc-init.sh | |
| # Ensure the dotnet tools directory is on PATH after installation |
| ref: refs/tags/release | ||
| pipelines: | ||
| - pipeline: source-build | ||
| source: {repo}-official # Name of the main build pipeline definition |
There was a problem hiding this comment.
In the NuGet.org publish pipeline YAML example, source: {repo}-official is not valid YAML because an unquoted {...} starts a flow-mapping. Use a non-braced placeholder (e.g., <repo>-official) or quote the value so the snippet can be copied without parse errors.
| source: {repo}-official # Name of the main build pipeline definition | |
| source: <repo>-official # Name of the main build pipeline definition |
- Add Step 5: Update Dependencies via Darc — runs darc update-dependencies against the target .NET SDK channel after creating infrastructure files - Change default Arcade SDK URI from dotnet/arcade to dotnet/dotnet (VMR) for .NET 9+ SDK channels - Add channel selection guidance (.NET 10.0.1xx SDK, Eng - Latest, etc.) - Update Version.Details.xml template with VMR URI and URI selection docs - Update darc subscription template to use dotnet/dotnet for SDK channels - Renumber steps 5-8 to 6-9 to accommodate new step - Fix cross-references between steps Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Lessons learned from onboarding dotnet/macios-devtools: - LICENSE validation: Arcade checks LICENSE line-by-line against MIT template; extra headers (e.g. 'Xamarin SDK') break validation - AssemblyCopyright signing: Sign.proj (SIGN004) classifies DLLs as 3rd-party if copyright isn't Microsoft; check AssemblyInfo.cs - build.sh vs cibuild.sh: build.sh needs explicit --ci flag for binary logs and artifacts/log/ creation - Solution config mapping: .sln can map Release→Debug silently, preventing package generation - IsPackable must be explicit: PackageId alone isn't sufficient - SDK compatibility: Arcade SDK 10.x needs .NET 10 SDK, 11.x needs .NET 11 SDK (System.Text.Json version mismatch) - Added 4 new entries to Common Build Failures table Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 8 out of 8 changed files in this pull request and generated 7 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| ``` | ||
|
|
There was a problem hiding this comment.
There’s an extra standalone triple-backtick after the SignCheckExclusions reference which starts a new code fence and will break the Markdown formatting for the remainder of the document. Remove that stray ``` so only the intended code blocks are fenced.
| ``` |
| The `global.json` must reference the Arcade SDK and optionally the Helix SDK. Use the latest stable Arcade SDK version from the `.NET Eng - Latest` channel. | ||
|
|
||
| ```json | ||
| { | ||
| "tools": { | ||
| "dotnet": "9.0.100" | ||
| }, | ||
| "msbuild-sdks": { | ||
| "Microsoft.DotNet.Arcade.Sdk": "<ARCADE_SDK_VERSION>" | ||
| } | ||
| } | ||
| ``` |
There was a problem hiding this comment.
The global.json template uses a tools.dotnet section, but this repo (and modern global.json schema) uses the sdk section to pin the .NET SDK. As written, copying this template is likely to produce an invalid/ignored SDK pin; update the template to use sdk.version (and include it in the Helix variant too).
| If the repository needs a specific SDK version with rollForward: | ||
| ```json | ||
| { | ||
| "sdk": { | ||
| "version": "9.0.100", | ||
| "rollForward": "latestFeature" | ||
| }, | ||
| "tools": { | ||
| "dotnet": "9.0.100" | ||
| }, | ||
| "msbuild-sdks": { | ||
| "Microsoft.DotNet.Arcade.Sdk": "<ARCADE_SDK_VERSION>" | ||
| } | ||
| } |
There was a problem hiding this comment.
In this rollForward example, sdk is present but tools.dotnet is still included. If the intent is to pin the SDK, sdk.version is sufficient; keeping a tools.dotnet field may confuse users into thinking it is required/supported. Consider removing tools from the template and keeping the schema consistent across all examples.
| ## Onboarding Workflow | ||
|
|
||
| 1. **Analyze the repository** — scan for projects, output types, existing CI, NuGet dependencies | ||
| 2. **Ask the user** about publishing preferences (NuGet.org yes/no, shipping scope) and 1ES metadata | ||
| 3. **Create/modify infrastructure files** — global.json, Directory.Build.props/targets, eng/ files, NuGet.config, es-metadata.yml | ||
| 4. **Copy eng/common/** — arcade shared build scripts | ||
| 5. **Update dependencies via darc** — run `darc update-dependencies` to pull latest coherent Arcade SDK, eng/common, and global.json from the target channel | ||
| 6. **Create Azure Pipelines YAML** — public CI and/or official build definitions | ||
| 7. **Set up internal mirror** — configure GitHub → AzDO mirror for official builds | ||
| 8. **Map dependencies to darc/maestro** — convert eligible NuGet references to flowable dependencies | ||
| 9. **Summarize next steps** — darc setup, subscriptions, channel assignments |
There was a problem hiding this comment.
The PR description calls this an “8-step workflow”, but the skill’s “Onboarding Workflow” section lists 9 steps. Please align either the skill doc or the PR description so users don’t get conflicting guidance on the workflow length/order.
|
|
||
| ### File creation order (dependencies flow top-down): | ||
|
|
||
| 1. **global.json** — reference Arcade SDK with a seed version. The `tools.dotnet` version should match the .NET SDK major version the repo targets (e.g. `10.0.104` for .NET 10). The Arcade SDK version will be updated by `darc update-dependencies` in the next step — use any recent version as seed (e.g. from the VMR's `global.json`). |
There was a problem hiding this comment.
This refers to pinning the SDK via tools.dotnet, but the repository’s global.json schema uses sdk.version for SDK selection. To avoid generating incorrect global.json files during onboarding, update this guidance to point at sdk.version (and any required rollForward settings) instead of tools.dotnet.
| 1. **global.json** — reference Arcade SDK with a seed version. The `tools.dotnet` version should match the .NET SDK major version the repo targets (e.g. `10.0.104` for .NET 10). The Arcade SDK version will be updated by `darc update-dependencies` in the next step — use any recent version as seed (e.g. from the VMR's `global.json`). | |
| 1. **global.json** — reference Arcade SDK with a seed version. Set `sdk.version` to the .NET SDK version the repo targets (e.g. `10.0.104` for .NET 10), and configure any required `sdk.rollForward` setting as appropriate for the channel. The Arcade SDK version will be updated by `darc update-dependencies` in the next step — use any recent version as seed (e.g. from the VMR's `global.json`). |
|
|
||
| # Ensure shell scripts are executable | ||
| find eng/common -name "*.sh" -exec chmod +x {} \; | ||
| git add --chmod=+x eng/common/**/*.sh |
There was a problem hiding this comment.
git add --chmod=+x eng/common/**/*.sh relies on ** glob expansion, which is not enabled in bash by default (globstar). This instruction may fail for many users; consider using a find ... -exec git add --chmod=+x form, or document enabling shopt -s globstar before running this.
| git add --chmod=+x eng/common/**/*.sh | |
| find eng/common -name "*.sh" -exec git add --chmod=+x {} + |
| echo "IMPORTANT: Run 'git add --chmod=+x eng/common/**/*.sh' before committing" | ||
| echo " to ensure executable permissions are tracked by git." |
There was a problem hiding this comment.
The suggested command uses eng/common/**/*.sh, but ** glob expansion isn’t enabled in bash by default, so users may get a pathspec/glob failure. Consider changing this message to a command that works in a default shell (e.g., via find ... -exec git add --chmod=+x).
| echo "IMPORTANT: Run 'git add --chmod=+x eng/common/**/*.sh' before committing" | |
| echo " to ensure executable permissions are tracked by git." | |
| echo "IMPORTANT: From the repo root, run:" | |
| echo " find eng/common -name '*.sh' -exec git add --chmod=+x {} \;" | |
| echo "to ensure executable permissions are tracked by git." |
dnceng official builds run NuGet Security Analysis (CFS) that rejects NuGet.config files containing nuget.org as a direct feed source. The dotnet-public feed already mirrors all NuGet.org packages. Changes: - Remove nuget.org from NuGet.config template - Add CFS security warning to file-templates.md - Add NuGet Security Analysis to common build failures table - Update Step 3 NuGet.config guidance Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Document the recommended two-step signing rollout: 1. Start with _SignType: test to validate pipeline end-to-end 2. Switch to Real in a follow-up PR after test signing passes Lists the service connections that need one-time approval on first Real build (ESRP, MicroBuild, Maestro). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| # Arcade Onboarding | ||
|
|
||
| Onboard a .NET repository onto the [dotnet/arcade](https://github.com/dotnet/arcade) build system, enabling shared tooling for versioning, signing, packaging, publishing, and CI/CD via Azure Pipelines with dependency flow through darc/maestro. | ||
|
|
||
| ## Onboarding Workflow | ||
|
|
||
| 1. **Analyze the repository** — scan for projects, output types, existing CI, NuGet dependencies | ||
| 2. **Ask the user** about publishing preferences (NuGet.org yes/no, shipping scope) and 1ES metadata | ||
| 3. **Create/modify infrastructure files** — global.json, Directory.Build.props/targets, eng/ files, NuGet.config, es-metadata.yml | ||
| 4. **Copy eng/common/** — arcade shared build scripts | ||
| 5. **Update dependencies via darc** — run `darc update-dependencies` to pull latest coherent Arcade SDK, eng/common, and global.json from the target channel | ||
| 6. **Create Azure Pipelines YAML** — public CI and/or official build definitions | ||
| 7. **Set up internal mirror** — configure GitHub → AzDO mirror for official builds | ||
| 8. **Map dependencies to darc/maestro** — convert eligible NuGet references to flowable dependencies | ||
| 9. **Summarize next steps** — darc setup, subscriptions, channel assignments |
There was a problem hiding this comment.
SKILL.md body appears to exceed the repo’s PR validation limit (max 500 body lines). Since this skill file is ~760+ body lines, CI will fail with “SKILL.md body is N lines (max 500)”. Please move more of the detailed guidance into the existing reference docs and keep SKILL.md to a shorter, high-level workflow with links.
|
Note This comment was generated with the help of Copilot. If #19 goes in first, this PR will need to add |
Summary
Adds a new arcade-onboarding skill to the
dotnet-dncengplugin that automates onboarding .NET repositories onto the dotnet/arcade build system.What it does
The skill provides an 8-step workflow that guides an AI agent through the complete arcade onboarding process:
Key features
Files added
Real-world validation
This skill was used to onboard dotnet/macios-devtools onto arcade, including:
Also validated against dotnet/maui-labs:
Motivation
Arcade onboarding involves many files and conventions that are documented across multiple pages. This skill encodes all that procedural knowledge so an AI agent can perform the onboarding correctly and completely, reducing manual effort and mistakes.