Post a vendor-neutral run summary on completion#7
Merged
Conversation
BootstrapMate status was local-only (registry + status.json + logs), so checking whether a PC provisioned cleanly meant an RDP/registry expedition. Add an optional reporting POST: when ReportingUrl is configured, a JSON run summary is sent on completion (success and failure paths). The payload is backend-agnostic and emits the SAME schema as the macOS client, so one fleet view covers both platforms. It includes runId, version, success, start/end/duration, architecture, hostname, serial number, manifest URL, and per-phase outcomes (reusing StatusManager data). The POST is best-effort: failures are logged and never block or fail the run. Configurable via Intune CSP / Group Policy (new ADMX Reporting category: ReportingUrl, ReportingHeader) and the machine/user registry.
There was a problem hiding this comment.
Pull request overview
Adds optional “vendor-neutral” run-summary reporting for BootstrapMate Windows, configurable via Intune/Group Policy (ADMX) and registry, and posts a JSON summary on both success and failure completion paths to enable fleet-level visibility.
Changes:
- Added
ReportingUrl/ReportingHeaderconfiguration keys with policy/registry wiring (including new ADMX/ADML “Reporting” category). - Introduced
ReportManagerto build and POST a JSON run summary with phase outcomes. - Hooked reporting into
Program.ProcessManifestcompletion (success + failure) and documented the feature inREADME.md.
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| src/BootstrapMate.Core/PolicyDetector.cs | Adds policy key aliases for reporting settings. |
| src/BootstrapMate.Core/ConfigManager.cs | Persists/loads reporting settings from policy + registry; supports CLI override parameters. |
| src/BootstrapMate.Core/BootstrapMateConfig.cs | Adds config properties for reporting endpoint + header. |
| resources/en-US/BootstrapMate.adml | Adds localized strings + UI presentation for reporting policies. |
| resources/BootstrapMate.admx | Adds new Reporting category and policies for URL/header. |
| ReportManager.cs | New run-summary payload builder + HTTP POST implementation. |
| Program.cs | Captures run start time and posts report on both success/failure paths. |
| README.md | Documents reporting configuration and payload fields. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+35
to
+38
| try | ||
| { | ||
| var payload = BuildPayload(success, startTimeUtc, DateTime.UtcNow, version, config.ManifestUrl ?? ""); | ||
| var json = JsonSerializer.Serialize(payload); |
Comment on lines
+101
to
+102
| private static string CurrentArchitecture() | ||
| => RuntimeInformation.OSArchitecture == Architecture.Arm64 ? "ARM64" : "X64"; |
| | `ReportingUrl` | string | Endpoint to POST the run summary to. When unset, no report is sent. | | ||
| | `ReportingHeader` | string | Optional `Authorization` header value sent with the POST. | | ||
|
|
||
| The POST is best-effort: failures are logged and never block or fail the run. Payload fields include `tool`, `platform`, `version`, `runId`, `success`, `startTime`/`endTime`, `durationSeconds`, `architecture`, `hostname`, `serialNumber`, `manifestUrl`, and per-phase outcomes. |
Comment on lines
+106
to
+110
| <string id="ReportingUrl_Help">URL to POST a vendor-neutral JSON run summary to when a bootstrap run completes. | ||
|
|
||
| The payload includes the run ID, version, success, duration, architecture, hostname, serial number, manifest URL, and per-phase outcomes. Any endpoint that accepts a JSON POST can consume it. | ||
|
|
||
| Leave empty to disable reporting. The POST is best-effort and never blocks or fails the run.</string> |
- Report the manifest URL actually used for the run (passed from ProcessManifest, which honors --url) rather than ConfigManager's value, which can differ. - Map architecture explicitly (ARM64/X64/X86, else uppercased name) so x86 is no longer mislabeled as X64. - Lower the POST timeout to 15s and correct README/ADML wording: the report is bounded by a short timeout (it does not 'never block'), but never fails the run.
# Conflicts: # README.md # resources/BootstrapMate.admx # resources/en-US/BootstrapMate.adml # src/BootstrapMate.Core/BootstrapMateConfig.cs # src/BootstrapMate.Core/ConfigManager.cs # src/BootstrapMate.Core/ManagementDetector.cs
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.
Problem
BootstrapMate's run status was local-only (registry +
status.json+ logs), so answering "did this PC provision cleanly?" across a fleet meant an RDP/registry expedition.Fix
Add an optional, vendor-neutral run-summary POST. When
ReportingUrlis configured,ReportManagerposts a JSON summary on completion — on both the success and failure paths. The payload emits the same schema as the macOS client (bootstrapmate-macintosh#5), so one fleet view covers both platforms.Payload fields:
tool,platform,version,runId,success,startTime/endTime,durationSeconds,architecture,hostname,serialNumber,manifestUrl, and per-phase outcomes (reusing the dataStatusManageralready persists).Best-effort: failures are logged and never block or fail the run (30s timeout). Serial number is read dependency-free from the SMBIOS registry key.
Configuration
Intune CSP / Group Policy via the bundled ADMX (new Reporting category):
ReportingUrl,ReportingHeader. Also readable fromHKLM\SOFTWARE\BootstrapMate\Settings(machine) /HKCU(GUI).Testing
dotnetunavailable on the author's machine) — relying on CI (windows-latest, dotnet 10) to compile-verify. Please confirm CI is green before merging.ReportManagerlives in the root project (alongsideStatusManager), since the WindowsStatusManageris not inBootstrapMate.Core.Notes
Based on
main, independent of the Authenticode PR #5 and rename PR #6, which also touchConfigManager.cs/PolicyDetector.cs/ the ADMX. Expect merge resolution depending on merge order; happy to rebase.