AzureDevOpsDscNative

1.3.0-preview2

A fork of the DSC Community AzureDevOpsDsc module with native DSC v3 support: every resource is discoverable and invokable by dsc.exe via the Microsoft.Adapter/PowerShell adapter, using generated adapted resource manifests, without requiring a wrapper resource.

Minimum PowerShell version

7.0

This is a prerelease version of AzureDevOpsDscNative.

Installation Options

Copy and Paste the following command to install this package using PowerShellGet More Info

Install-Module -Name AzureDevOpsDscNative -AllowPrerelease

Copy and Paste the following command to install this package using Microsoft.PowerShell.PSResourceGet More Info

Install-PSResource -Name AzureDevOpsDscNative -Prerelease

You can deploy this package directly to Azure Automation. Note that deploying packages with dependencies will deploy all the dependencies to Azure Automation. Learn More

Manually download the .nupkg file to your system's default download location. Note that the file won't be unpacked, and won't include any dependencies. Learn More

Owners

Copyright

Copyright the DSC Community contributors and ZanattaMichael. All rights reserved.

Package Details

Author(s)

  • ZanattaMichael

Tags

DesiredStateConfiguration DSC DSCResourceKit DSCResource DSCv3 AzureDevOps

DSCResources

AzDoGroupPermission AzDoOrganizationGroup AzDoProject AzDoProjectServices AzDoProjectGroup AzDoGroupMember AzDoGitRepository AzDoGitPermission AzDoAreaPermission AzDoIterationPermission AzDoWIPTags AzDoAreaNodes AzDoIterationNodes AzDoBranchPolicy AzDoVariableGroup AzDoServiceConnection AzDoPipelineEnvironment AzDoAgentPool AzDoAgentQueue AzDoTeam AzDoTeamMember AzDoPipeline AzDoPipelinePermission AzDoEnvironmentApproval AzDoVariableGroupPermission AzDoServiceConnectionPermission AzDoAgentPoolPermission AzDoSecurityNamespacePermission AzDoArtifactFeed AzDoArtifactFeedPermission AzDoDeploymentGroup AzDoTaskGroup AzDoOrganizationSettings AzDoExtension AzDoAuditStream AzDoProjectPermission AzDoEnvironmentPermission AzDoWiki AzDoNotificationSubscription AzDoRepositorySettings AzDoCheckConfiguration AzDoTeamSettings AzDoArtifactFeedSettings AzDoArtifactFeedView AzDoProcess AzDoProcessPermission AzDoUserEntitlement AzDoServiceHook AzDoPipelineSettings AzDoQueryFolder AzDoWorkItemQuery AzDoQueryPermission AzDoWIPTagHygiene AzDoSecureFile AzDoSecureFilePermission AzDoPipelineFolder AzDoPipelineFolderPermission AzDoGroupEntitlement AzDoServicePrincipalEntitlement AzDoPicklist AzDoProcessWorkItemType AzDoProcessField AzDoProcessState AzDoProcessRule AzDoProcessBehavior AzDoPipelineAuthorization AzDoEnvironmentKubernetesResource AzDoEnvironmentVMResource AzDoDeploymentGroupTarget AzDoReleaseFolder AzDoReleaseFolderPermission AzDoReleaseDefinitionPermission AzDoTestVariable AzDoTestConfiguration AzDoTestPlan AzDoTestSuite AzDoBuildRetentionSettings AzDoWikiPage AzDoTaggingPermission AzDoAnalyticsPermission AzDoAnalyticsViewsPermission AzDoDashboard AzDoOrganizationPermission AzDoTaskGroupPermission

Dependencies

This module has no dependencies.

Release Notes

## [1.3.0-preview2] - 2026-10-21

### Changed

- Build
 - `azure-pipelines.yml` brought in line with the GitHub workflows so it runs
   on current Microsoft-hosted agents: full-history checkout for GitVersion,
   GitVersion.Tool 5.12.0 run with `DOTNET_ROLL_FORWARD=Major` (hosted images
   no longer ship .NET 6/7), unit tests run under Pester 5.7.1 as in
   `unit-tests.yml` instead of the Pester 4 `build.ps1 -tasks test` path,
   HQRM reported but non-gating, and the retired Codecov bash uploader and
   `PublishCodeCoverageResults@1` removed. The Deploy stage no longer requires a
   `dsccommunity` organization; it runs only on a `v*` tag with the pipeline
   variable `PublishRelease` set to `true`.
 - The integration workflows now cope with more than one runner carrying the
   `AZDO-AGENT` label. The v2 and v3 live-organization jobs share one
   concurrency group, so they no longer run against the organization at the same
   time and delete each other's test objects in their pre-run teardown.
 - The integration workflows no longer move module copies out of, and back
   into, the runner's standard module folders around each run - a failed move
   there stranded copies in `RUNNER_TEMP`, which the runner empties between
   jobs. They load the module only from their workspace build and now fail,
   naming each one, if a copy is installed in a standard module folder.
   `tests/Integration/README.md` lists what an `AZDO-AGENT` machine needs.
 - `scripts/redeploy-module.ps1` no longer copies the build into
   `Documents\PowerShell\Modules`. It puts `output\builtModule` at the front of
   `PSModulePath` for the current session and warns about any copy in a
   standard module folder.
- AzureDevOpsDscNative
 - `AzDoProject.ProcessTemplate` no longer restricts a project to the four
   system processes (`Agile`, `Scrum`, `CMMI`, `Basic`) via `ValidateSet` -
   any process name known to the organization, including an inherited
   process, is accepted and resolved against the `LiveProcesses` cache,
   falling back to a live lookup. `Set` can now change a project's process: `Get-AzDoProject`
   compares the project's current process against the desired one and, when
   they differ, resolves both to their system-process ancestor
   (`Get-AzDoProcessFamilyRootId`) to decide whether Azure DevOps will permit
   the migration. A compatible change (moving between a system process and
   one of its inherited children, or between two inherited children of the
   same parent) is applied via the new `projectprocessmigration` endpoint
   (`Move-DevOpsProjectProcess`); an incompatible one - crossing unrelated
   process families - is refused with a clear error in both `Get` and `Set`,
   since `Get`'s `Error` status still routes to `Set` and the refusal has to
   be repeated there to hold. Previously, `ProcessTemplate` was listed in
   `GetDscResourcePropertyNamesWithNoSetSupport()` and `Update-DevOpsProject`
   took a `ProcessTemplateId` parameter it never referenced, so a process
   change on an existing project was always a silent no-op ([issue #75](https://github.com/ZanattaMichael/AzureDevOpsDsc/issues/75)).

- Performance
 - `Set()` now runs the resource's `Get` function once instead of twice:
   `SetToDesiredState()` reads the current state and passes it to a new
   `GetDscRequiredAction([Hashtable])` overload rather than reading it again.
 - The fixed 2-second sleep after every `Set()` is gone. `GetPostSetWaitTimeMs()`
   now defaults to `0`; a resource whose API needs time before a write is
   readable overrides it.
 - Caches are loaded on first use. `Construct()` no longer initializes every
   cache type (with `-Debug` forced on) each time a resource is instantiated;
   `Get-CacheObject` already imports a cache when it is first read. A missing
   cache file is now reported as verbose output rather than a warning, since
   it is the normal state for a cache nothing has written yet.
 - Cache lookups no longer copy or scan the whole cache:
   - `Get-CacheObject` returns the live cache list instead of letting
     PowerShell unroll it into a copy on every read. An empty cache comes back
     as an empty list rather than `$null`, and a cache stored as an array is
     normalized to a `List[CacheItem]` once.
   - `Add-CacheItem` and `Get-CacheItem` find a key through a new
     case-insensitive key index (`Get-CacheKeyIndex`) instead of a
     `Where-Object` scan, so filling a cache is linear rather than quadratic.
     The index is rebuilt whenever the cache list is replaced or its count
     changes, and a cache holding a duplicate key falls back to scanning.
   - `Add-CacheItem` replaces an existing key in place instead of copying the
     cache through `Remove-CacheItem`.
   - `Find-Identity` filters the group, user and service-principal caches with
     `.Where()` instead of copying each one per ACE.
   - `CacheItem` stamps its creation time with `[datetime]::Now` rather than
     a `Get-Date` call.

- Documentation
 - `docs/ResourceRoadmap.md` gains §12, the resources a code review found
   missing that neither the roadmap nor an open issue tracked: permission
   resources for the `Collection`, `MetaTask`, `ServiceHooks`, `AuditLog`,
   `EventSubscription` and `VersionControlItems` namespaces and for deployment
   groups and project agent queues; `AzDoWorkItemTemplate` and
   `AzDoTaskboardColumn`; `AzDoAgent`, agent pool maintenance and per-pipeline
   settings on `AzDoPipeline`; `AzDoTestResultRetentionSettings` and
   organization-wide feed permissions; and project properties and notification
   delivery settings. It also records what was checked and found already
   covered or not buildable, and a suggested order. §2, §8 and §9 point to it.
 - `docs/ResourceRoadmap.md` gains §13 for open issues #66 (Copilot code
   review) and #67 (GitHub Advanced Security), which the roadmap did not
   mention. It lists the proposed resources and the questions each issue
   must settle first, and gives an order. §8 and §9 point to it.

- Tests
 - The integration tests for `AzDoDashboard`, `AzDoOrganizationPermission` and
   `AzDoTaskGroupPermission` now read the live state back from the REST API
   after each `Set`, instead of relying only on the resource's own `Test`:
   - `AzDoDashboard`: the written description and refresh interval, no
     duplicate on a repeated `Set`, a widget added outside DSC surviving an
     update, drift made outside DSC being detected and fixed, and a team and
     a project dashboard with the same name being kept apart.
   - `AzDoOrganizationPermission`: the exact allow and deny bits, and every
     other entry on the organization root compared mask for mask against a
     snapshot taken before any write - after a `Set`, a second group's `Set`,
     a repeated `Set` and `Absent`. Also outside drift, permissions named by
     display name, and `Absent` removing only its own group's entry.
   - `AzDoTaskGroupPermission`: the same live-ACL checks on the project-level
     token, several identities in one configuration, changing a permission
     from `Deny` to `Allow`, turning inheritance off and back on, and a
     project that does not exist.

### Fixed

- Integration tests
 - `AzDoQueryPermission` and `AzDoWorkItemQuery` create their query folder
   through the new `Invoke-TestQueryFolderSet`. It retries the
   `TF401256: You do not have Write permissions for query Shared Queries` 403
   that a project returns for a few seconds after it reaches `wellFormed`.
   `Invoke-AzDevOpsApiRestMethod` no longer retries a 403, and that retry
   used to hide the delay.
 - `AzDoReleaseDefinitionPermission` calls `Enable-TestClassicPipeline` before
   creating its classic release definition, and skips when an organization
   policy forbids classic pipelines, as `AzDoTaskGroup` and
   `AzDoDeploymentGroup` already do.
 - `AzDoPicklist` polls for up to 30 seconds for the removed picklist to
   drop out of the picklist list. The list could still return it for a moment
   after a successful DELETE.
 - `Get-MIToken` requests its token with `-NoAuthentication`, which
   `Invoke-APIRestMethod` now honours. It used to build an Authorization
   header from `$Global:DSCAZDO_AuthenticationToken`, so after a test whose
   token request failed had left that global null, the post-run teardown
   threw before cleaning up or reporting the test results.
- AzureDevOpsDscNative
 - Reloading a cache no longer writes the whole cache to the output stream
   ([issue #55](https://github.com/ZanattaMichael/AzureDevOpsDsc/issues/55)).
   `Import-CacheObject` returns the collection it imported, and
   `Initialize-CacheObject`, `Refresh-CacheObject` and `Refresh-AzDoCache`
   called it for its side effect without discarding that value. Every `New-`
   and `Set-` function that ends by refreshing its cache printed the cache as
   a `Key`/`Value` table during `Invoke-DscResource`.
 - `Get-AzDoProjectServices` reports `NotFound` for a project that does not
   exist, rather than failing with `TF200016`. Its live fallback lookup now
   goes through `Resolve-AzDoProject`, which treats a 404 as no project.
 - `Invoke-AzDevOpsApiRestMethod -AzureArcAuthentication` retries a 408, 429
   or 5xx from the Azure Arc token endpoint like any other request. It used to
   hand every error straight back to `Get-AzManagedIdentityToken`, which
   only needs the 401 challenge unchanged, so a throttled token request failed
   the resource being constructed. It showed up as a 429 failing
   `[AzDoProject]::Export()` and `[AzDoGitRepository]::Export()`.
 - `Invoke-AzDevOpsApiRestMethod` no longer throws "Unable to find type
   [APIRateLimit]" on a 429 or a response carrying rate-limit headers. T

FileList

Version History

Version Downloads Last updated
1.3.0-preview2 (current version) 4 10/21/2026
1.3.0-preview1 6 10/18/2026
1.2.0 2,413 10/4/2026
1.2.0-preview2 7 10/4/2026
1.2.0-preview1 8 10/3/2026
1.1.0 1,671 9/23/2026
1.1.0-preview2 4 9/18/2026
1.0.0 2,608 9/4/2026
1.0.0-preview6 7 9/4/2026
1.0.0-preview5 5 8/27/2026
1.0.0-preview4 5 8/19/2026
1.0.0-preview02 5 8/18/2026
Show more