Azure Artifacts

Azure Artifacts provides developers with a centralized solution for managing dependencies. It allows for seamless publishing of packages to feeds, facilitating easy sharing within teams, across organizations, or even publicly on the internet. Developers can also consume packages from feeds and public registries like NuGet.org or npmjs.com. Azure Artifacts supports multiple package types, including NuGet, npm, Python, Maven, Cargo, and Universal Packages.

Creating a Feed in Azure Artifacts

1. Sign in to your Azure DevOps organization and navigate to your project.

2. Go to the Artifacts section and select Create Feed.

3. Enter a descriptive name for your feed in the Name field.

3.1 Choose the appropriate Visibility option to determine who can access the packages within the feed.

3.2 To include packages from public sources, check the box under Upstream sources.

3.3 Specify the Scope of the feed, either at the project level or the organization level.

4.?click?Create?to finalize the process once all settings are configured.

Viewing Organization Billing in Azure DevOps

1. Sign in to your Azure DevOps organization.

2. Click on the gear icon to access Organization settings.

3. Select Billing from the menu.

4. Review your Artifacts tier and usage limits.

Publishing a Package to an Azure Artifacts Feed

Azure Artifacts allows developers to manage all their dependencies through a single feed efficiently. These feeds act as organizational repositories, enabling you to store, manage, and share packages within your team, across organizations, or even publicly on the internet. Azure Artifacts feeds support various package types, including NuGet, npm, Python, Maven, Cargo, and Universal Packages.

Creating a Feed in Azure Artifacts

1. Sign in to your Azure DevOps organization and navigate to your project.

2. Go to Artifacts and click Create Feed.

3. Enter a descriptive Name for your feed and choose the Visibility setting to determine who can view the packages. Specify the Scope of your feed, and if you wish to include packages from public sources, check the Upstream sources option.

4. Once all settings are configured, click Create to finalize the setup.

Connecting to a Feed

1. Go to Artifacts and choose your feed from the dropdown menu.

2. Click Connect to feed and select dotnet under the NuGet section.

3. Follow the instructions in the Project Setup section to configure your nuget.config file. The structure of your file should resemble the following:

Project-scoped feed:        

XML:

<?xml version="1.0" encoding="utf-8"?>

<configuration>

<packageSources>

<clear />

<add key="<FEED_NAME>" value="https://pkgs.dev.azure.com/<ORGANIZATION_NAME>/<PROJECT_NAME>/_packaging/<FEED_NAME>/nuget/v3/index.json" />

</packageSources>

</configuration>

Organization-Scoped Feed:        

<?xml version="1.0" encoding="utf-8"?>

<configuration>

<packageSources>

<clear />

<add key="<FEED_NAME>" value="https://pkgs.dev.azure.com/<ORGANIZATION_NAME>/_packaging/<FEED_NAME>/nuget/v3/index.json" />

</packageSources>

</configuration>

Publishing Packages

To publish your package, navigate to your project directory and run the following command. An API key is required, but when publishing to an Azure Artifacts feed, you can use any string value for it.

dotnet nuget push --source <FEED_NAME> --api-key az <PACKAGE_PATH>

Monitoring Artifacts Storage Consumption

Azure Artifacts uses a consumption-based billing model for all supported package types, including NuGet, npm, Python, Maven, and Universal packages. The free-tier plan offers two Gibibytes (GiB) of storage for your packages. If you exceed this limit, you can either upgrade to a paid plan or delete some of your existing artifacts to free up space.

Organization-Level Storage        

The organization-level view gives you a summary of your total storage usage, including a breakdown by artifact type and project.

1. Sign in to your Azure DevOps organization.

2. Click on the gear icon to access Organization settings, then select Storage from the left-hand navigation pane.

3. You can view a summary of your total storage, along with detailed breakdowns by artifact type and by project within your organization.

4. Click View storage breakdown in the Storage by Type section to see the total storage used for packages in your organization-scoped feeds.

Project-Level Storage        

The project-level view offers a summary of your total storage usage, including a breakdown by artifact type.

1. Sign in to your Azure DevOps organization and navigate to your project.

2. Click on the gear icon to access Project settings, then select Storage from the left-hand navigation pane.

3. You can view a summary of your total storage and see how it is consumed by artifact type for your project.

4. Click View storage breakdown in the Storage by Type section to see the total storage used for packages in your project-scoped feeds.

Searching for Packages

1. Sign in to your project at [https://dev.azure.com/{Your_Organization}/{Your_Project}](https://dev.azure.com/{Your_Organization}/{Your_Project}).

2. Type the package name into the search box.

3. Use the dropdown menus to refine your search by feeds, views, or package types.

By default, you can search across all feeds in the organization, regardless of the project you're in.

The Views filter appears only when you select a specific feed from the Feeds filter. It allows you to display packages from a particular view.

Use the Type filter to select the package type you wish to search for, such as NuGet packages.

Searching with the REST API

You can use the Azure DevOps REST API to search for packages within a specific organization.

Command: POST https://almsearch.dev.azure.com/ORGANIZATION_NAME/_apis/search/packagesearchresults?api-version=7.0

Request:

{

"$orderBy": null,

"$top": 100,

"$skip": 0,

"searchText": "react-calendar",

"filters": {

"ProtocolType": "Npm"

} }

Sharing Your Artifacts with Package Badges

With Azure Artifacts, you can share your packages anywhere an image can be displayed using package badges. Embed these badges directly into your project's home page or any Markdown file, allowing customers to easily find and download your packages.

Enabling Package Sharing

1. Go to Artifacts and select your feed from the dropdown menu.

2. Click the gear icon to access the Feed settings.

2. Find the Package sharing section and check the box to Enable package badges.

Creating a Package Badge

Once package sharing is enabled, you can create a badge for any package in your feed, though only for the latest version of each package.

1. Go to your feed and select the desired package.

2. Click Create badge.

2. Select a Feed view for your package badge. If you're using release views, select the view that contains the packages you want to share.

What Are Azure Artifacts Feeds?

Azure Artifacts feeds are organizational tools designed for storing, managing, and sharing packages while controlling access. They are versatile and can hold various package types, such as npm, NuGet, Maven, and Python packages, all within a single feed.

Project-Scoped vs. Organization-Scoped Feeds        

• Organization-Scoped Feeds: These feeds are accessible from any project within the organization and can be viewed by all projects in the organization.
• Project-Scoped Feeds: These feeds are restricted to the hosting project and can only be viewed within that project.

Note that organization-scoped feeds cannot be converted to project-scoped feeds. Additionally, only project-scoped feeds can be designated as public. For a detailed comparison between feed scopes, refer to the Feeds scope documentation.

Creating a New Feed

To create a new project-scoped or organization-scoped feed, follow these steps:

1. Sign in to your Azure DevOps organization and navigate to your project.

2. Go to Artifacts and click Create Feed.

3. Enter a descriptive Name for your feed and set its Visibility (who can access the feed).

4. Define the Scope of your feed. If you want to include packages from public sources, check the Upstream sources option.

5. Click Create to finalize the setup.

Creating a Public Feed

Public feeds are project-scoped feeds within a public project. To create a new public feed, follow these steps:

1. Navigate to your Azure DevOps project and ensure that it is set to Public. Go to Artifacts and click Create Feed.

2, Enter a Name for your feed, and then select Project for the feed's scope. Select Create when you're done.

Deleting a Feed

1. Go to your Azure DevOps project and select Artifacts.

2. Choose your feed from the dropdown menu.

3. Click the gear icon to access the feed’s settings.

4. Select Delete feed and then click Delete again to confirm.

Restore deleted feeds

If you accidentally delete a feed, Azure Artifacts offers a 30-day window to restore it to its original state. After this period, the feed will be permanently deleted. During the recovery window, the feed's name remains reserved, packages are unavailable for download, and write access is suspended.

To access feeds pending permanent deletion, navigate to the feed picker dropdown menu and select the Deleted Feeds tab.

1. Navigate to your Azure DevOps project, and then select Artifacts.
2. Select the feed picker dropdown menu, and then select the Deleted Feeds tab.

3. Select the feed you want to restore, and then select Feed Settings. Select Restore Feed when you're ready.

Permanently Deleting a Feed

A feed marked for deletion will continue to occupy storage until the 30-day retention period expires. To permanently delete a feed before this period ends, follow these steps:

1. Navigate to your Azure DevOps project and select Artifacts.

2. Click the feed picker dropdown menu and go to the Deleted Feeds tab.

3. Choose the feed you wish to permanently delete and select Feed Settings.

4. Click Permanently Delete Feed, and then confirm by selecting Delete.

What Are Feed Views?

Feed views allow developers to share specific subsets of package versions with their users. They are often used to distribute package versions that have been tested and validated, while keeping packages that are still in development or don't meet certain quality standards private.

Default Views        

Each Artifacts feed includes three default views: @local, @prerelease, and @release. You can rename or delete the @prerelease and @release views as needed. The @local view is the default and is commonly used for upstream sources.

The @local view includes all packages published directly to the feed and any packages retrieved from upstream sources.

Feed views are read-only, meaning that users can only access and use packages published to that view or saved from upstream sources. For more information on how available packages are constructed, see package graphs.

Releasing Packages with Feed Views

When releasing packages, it’s crucial to communicate three key aspects: the nature of the change, the associated risk, and the quality of the change.

Quality of the Change

The quality of a change is typically not fully known until the validation process is complete, which occurs after the change has been built and packaged. Due to this timing, it’s not practical to reflect the quality of the change in the numerical version number (e.g., 11.12.13). While there are workarounds for pre-validation, such as using the build’s DLLs before packaging and publishing to a "debug" or "CI" environment for validation, none can guarantee that the final package will meet the required quality standards.

You can use the @Release view to indicate the quality of your changes. By using the @Release view, you can share only those packages that have met your quality standards, ensuring that consumers see only the subset of package versions that have been tested, validated, and are ready for use.

Publishing Artifacts

You can publish your artifacts using one of the following methods:

• YAML
• Classic Editor
• Azure CLI

YAML : steps:

- publish: $(System.DefaultWorkingDirectory)/bin/WebApp

artifact: WebApp

Although specifying the artifact's name is optional, it is recommended to choose a name that accurately reflects the artifact's contents. If you plan to use the artifact on a different OS, ensure that all file paths are valid for the target environment. For instance, file names containing characters like \ or * may not download correctly on Windows.

You must provide the path of the file or folder you want to publish, which can be either an absolute or relative path to $(System.DefaultWorkingDirectory).

Keep in mind that packages in Azure Artifacts are immutable. Once a package is published, its version is permanently reserved. Rerunning failed jobs may fail if the package has already been published. To avoid errors related to existing packages, consider using Conditions to ensure that jobs only run if the previous job succeeded.

jobs:

- job: Job1

steps:

- script: echo Hello Job1!

- job: Job2

steps:

- script: echo Hello Job2!

dependsOn: Job1

Publishing Artifacts

Artifacts can be published at any stage of your pipeline. You can use either YAML or the classic Azure DevOps editor to publish your packages.

- powershell: gci env:* | sort-object name | Format-Table -AutoSize | Out-File $env:BUILD_ARTIFACTSTAGINGDIRECTORY/environment-variables.txt

- task: CopyFiles@2

inputs:

sourceFolder: '$(Build.SourcesDirectory)'

contents: '**/$(BuildConfiguration)/**/?(*.exe|*.dll|*.pdb)'

targetFolder: '$(Build.ArtifactStagingDirectory)'

- task: PublishBuildArtifacts@1

inputs:

pathToPublish: '$(Build.ArtifactStagingDirectory)'

artifactName: drop

• pathToPublish: the path of your artifact. This can be an absolute or a relative path. Wildcards aren't supported.
• artifactName: the name of your artifact.

Example: Using Multiple Tasks        

- powershell: gci env:* | sort-object name | Format-Table -AutoSize | Out-File $env:BUILD_ARTIFACTSTAGINGDIRECTORY/environment-variables.txt

- task: CopyFiles@2

inputs:

sourceFolder: '$(Build.SourcesDirectory)'

contents: '**/$(BuildConfiguration)/**/?(*.exe|*.dll|*.pdb)'

targetFolder: '$(Build.ArtifactStagingDirectory)'

- task: PublishBuildArtifacts@1

inputs:

pathToPublish: '$(Build.ArtifactStagingDirectory)'

artifactName: drop1

- task: PublishBuildArtifacts@1

inputs:

pathToPublish: '$(Build.ArtifactStagingDirectory)'

artifactName: drop2

• pathToPublish: the path of your artifact. This can be an absolute or a relative path. Wildcards aren't supported.
• artifactName: the name of your artifact.