CopilotAtelier.psd1
|
@{ RootModule = 'CopilotAtelier.psm1' # Replaced at build time by GitVersion. ModuleVersion = '2.0.0' GUID = '67bbef0b-f4de-4c1b-bb5a-b34104beb5b7' Author = 'raandree' CompanyName = 'raandree' Copyright = '(c) raandree. All rights reserved.' Description = 'Portable GitHub Copilot customization library. Ships custom agents, auto-applied instructions, on-demand skills, prompt templates, and lifecycle hooks, and installs them into the well-known ~/.copilot discovery folders that VS Code, the GitHub Copilot CLI, and Claude Code read.' PowerShellVersion = '5.1' FunctionsToExport = @('Get-CopilotAtelierVersion','Install-CopilotAtelier','Update-CopilotAtelier') CmdletsToExport = @() VariablesToExport = @() AliasesToExport = @() PrivateData = @{ PSData = @{ Tags = @( 'Copilot' 'GitHubCopilot' 'VSCode' 'Agents' 'Skills' 'Prompts' 'Instructions' 'Hooks' 'AI' 'Windows' 'Linux' 'MacOS' ) LicenseUri = 'https://github.com/raandree/CopilotAtelier/blob/main/LICENSE' ProjectUri = 'https://github.com/raandree/CopilotAtelier' IconUri = 'https://raw.githubusercontent.com/raandree/CopilotAtelier/main/assets/CA-glyph-on-light.png' Prerelease = '' ReleaseNotes = '## [2.0.0] - 2026-07-29 ### Changed - **CopilotAtelier is now a PowerShell module built with Sampler and published to the PowerShell Gallery** (2026-07-29). Until now the only supported distribution was "clone the repository and run the setup script", which gave no version identity, no update path, and no way for a consumer to tell whether their deployed customizations were current. The repository is now a [Sampler](https://github.com/gaelcolas/Sampler) project. Module sources live in [`source/`](source/) (`Public/`, `Private/`, and the manifest); the five Customization directories plus `Keybindings/` stay at the repository root — so [`plugin.json`](plugin.json), the documentation links, and a plain clone all keep working — and the new [`.build/Copy_Customizations_To_Output.build.ps1`](.build/Copy_Customizations_To_Output.build.ps1) task copies them verbatim into the built module, so a Gallery install carries exactly the same payload as a clone. Versioning is [GitVersion](https://gitversion.net/) via [`GitVersion.yml`](GitVersion.yml), so `ModuleVersion` in the source manifest is a placeholder the build replaces. The first Gallery release is **2.0.0**: the distribution model is a breaking change for anyone scripting against the old monolithic script. The 560-line `Setup-CopilotSettings.ps1` was decomposed into three exported commands and six private helpers with no behavioral change to the deployment itself. `Setup-CopilotSettings.ps1` survives as a thin shim that dot-sources `source/` and calls `Install-CopilotAtelier` against the clone, so every existing instruction, prompt, and README reference to it still works and no build is needed to deploy a working tree. Two behaviors did change: the canonical target folder is now fixed to `CopilotAtelier` (the module name) instead of being derived from the clone''s folder name, because a Gallery-installed module has no clone to derive from; and console output moved from `Write-Host` to the information stream, so `Install-CopilotAtelier` is quiet by default and returns a summary object — the shim passes `-InformationAction Continue` to preserve the familiar console experience. | Command | Purpose | |---|---| | `Install-CopilotAtelier` | Deploys the customizations, links `~/.copilot`, merges settings and keybindings, and records the deployed version in `<target>/.copilotatelier.json`. | | `Update-CopilotAtelier` | Compares the installed version with the Gallery, installs a newer one, and redeploys from it. `-Force` redeploys the current version; `-SkipDeployment` stages the update. | | `Get-CopilotAtelierVersion` | Reports the installed version, the deployed version, and whether the deployment is current. | - **`CHANGELOG.md` is now machine-parseable** (2026-07-29). `Get-ChangelogData` failed on this file because `[Unreleased]` had no link reference and the two release headings used an em dash instead of the Keep a Changelog `- ` separator. Sampler''s `Create_Changelog_Release_Output` and `Create_ChangeLog_GitHub_PR` tasks both depend on that parse, so the release pipeline could not have run. Fixed all three, and a new QA test pins the parse. ### Added - **A canonical GitHub Actions template for Sampler repositories** (2026-07-29). [`Skills/sampler-framework/references/ci-cd-pipelines.md`](Skills/sampler-framework/references/ci-cd-pipelines.md) advertised "Azure Pipelines and GitHub Actions templates" but only ever contained the Azure Pipelines one, so every Actions pipeline was written from scratch and drifted — which is exactly how this repository''s own `ci.yml` diverged from its siblings. The reference now carries the full `.github/workflows/ci.yml` template, a second-PowerShell-edition matrix variant, and an Azure Pipelines to GitHub Actions translation table covering the constructs with no direct equivalent: `##vso[task.setvariable]` becomes `$GITHUB_OUTPUT` plus job `outputs`, `##vso[build.updatebuildnumber]` has no equivalent at all, `pwsh: true|false` becomes a `defaults.run` shell because a step''s `shell` key accepts no context, and the org guard becomes `github.repository_owner`. [`Instructions/sampler.instructions.md`](Instructions/sampler.instructions.md) gained a CI/CD Rules section and now applies to `azure-pipelines.yml` and `.github/workflows/*.yml`, so the template and its non-negotiables load automatically whenever a Sampler pipeline is edited. - **The CI workflow pins the current GitHub Actions majors** (2026-07-29). Every job warned that `actions/checkout@v4`, `upload-artifact@v4`, and `download-artifact@v4` target the deprecated Node 20 runtime. Bumped to `checkout@v7`, `upload-artifact@v7`, and `download-artifact@v8` — the three actions do not share a major number, and the release where each stopped defaulting to Node 20 differs (`checkout` v5, `upload-artifact` v6, `download-artifact` v7), so a uniform bump to any single number would have left two of them deprecated. The documented breaking changes do not apply here: `checkout@v7` only restricts fork checkouts under `pull_request_target` and `workflow_run`, and `download-artifact@v5` only changed the output path for downloads by artifact ID, not by name. The skill template carries the same pins plus a per-action version table. - **GitHub Actions CI** (2026-07-29). New [`.github/workflows/ci.yml`](.github/workflows/ci.yml) — the repository had no CI at all. It follows the same build/test/deploy shape as the other Sampler repositories so one pipeline can be reasoned about everywhere: a `Package Module` job computes the version with GitVersion, exports every GitVersion property as a step output, stamps `FullSemVer` into the job summary, and uploads `output/` as the build artifact; the downstream job names carry that version, which is the closest GitHub Actions gets to Azure DevOps'' run renaming. `Test` reuses the artifact on Linux, macOS, Windows PowerShell 7, and Windows PowerShell 5.1, with the non-Windows legs restricted to `-PesterTag @(''Unit'',''QA'')` because the repository also tests Windows-only Customizations. `Deploy Module` publishes the GitHub release and the Gallery package from `main` or a `v*` tag, is fenced to the upstream owner, and needs the `GitHubToken` and `GalleryApiToken` repository secrets. Pushes that only touch `CHANGELOG.md` are ignored so the release commit does not retrigger the pipeline. - **A module test suite** (2026-07-29). [`tests/QA/module.tests.ps1`](tests/QA/module.tests.ps1) enforces the changelog parse, the exported command surface, the presence and non-emptiness of all six shipped customization directories inside the built module, a unit test per exported command, zero PSScriptAnalyzer findings per command, and complete comment-based help including a documented example and every parameter. [`tests/Unit/`](tests/Unit/) covers the three public commands and the two load-bearing private helpers (`ConvertFrom-Jsonc`, `Get-CopilotAtelierPath`) against a sandboxed profile, including the legacy-location cleanup, the keybinding merge, the discovery links, and the version-comparison paths. - **A README Quick Start** (2026-07-29). Installation previously sat 150 lines into the README, behind the whole skill catalogue, so a first-time reader met the inventory before the two commands that get them running. The new Quick Start leads with prerequisites, `Install-Module` plus `Install-CopilotAtelier`, the restart, and `Update-CopilotAtelier`, and states plainly that the Gallery package is not published yet. The Gallery section gained the day-two loop it was missing: the useful switches, a `Get-Help` pointer, sample `Get-CopilotAtelierVersion` output with what `IsCurrent : False` means, and what a second machine still has to do for itself. ### Fixed - **The GitVersion step destroyed the evidence of its own failure** (2026-07-29). `Calculate ModuleVersion (GitVersion)` piped `dotnet-gitversion` straight into `ConvertFrom-Json`. GitVersion writes its diagnostic log to standard output, not standard error, so when it misbehaves the pipe swallows the message and the step reports `Conversion from JSON failed with error: Unexpected character encountered while parsing value: M` instead of the reason. That is exactly what run 30462902820 reported after `v2.0.0` was tagged, which is why the cause is still unknown: GitVersion 5.12.0 installed, ran, and wrote something beginning with `M` that nobody can see. The step now captures the output, checks the exit code and that the payload starts with `{`, prints the raw output between markers before failing, and echoes the resolved `dotnet-gitversion` path. It also **prepends** rather than appends `~/.dotnet/tools` to `PATH`, so a GitVersion already present on the runner image cannot shadow the pinned 5.x, and clears `$PSNativeCommandUseErrorActionPreference` so GitHub''s `$ErrorActionPreference = ''Stop''` cannot throw before the output is shown. - **A tag build could not always compute a version** (2026-07-29). A tag push checks out `refs/tags/<tag>` with a detached HEAD, so GitVersion takes its branch name from `GITHUB_REF` and works on a synthetic `tags/v2.0.0` branch. Nothing in [`GitVersion.yml`](GitVersion.yml) matched it, so every tag build logged `No branch configuration found for branch tags/v2.0.0, falling back to default configuration` and then tried to inherit the increment from a parent branch. That lookup is not guaranteed to succeed: when it finds no `main` or `develop` branch it throws `Gitversion could not determine which branch to treat as the development branch (default is ''develop'') nor release-able branch (default is ''main'' or ''master'')` and exits 1, taking the release build with it. Reproduced with GitVersion 5.12 against a detached tag checkout. `GitVersion.yml` now carries a `release-tag` branch entry matching `^tags?[-/]` with no label and no increment, because on a tag build the tag *is* the version, so the inheritance lookup is never reached. Verified `FullSemVer 2.0.0` on a tag build with and without ' } } } |