CI, CD, Build Server Setup
This article explains some concepts and how to troubleshoot the most common errors related to setting up the Telerik NuGet packages for automated builds, CI and CD.
To successfully set up a CI/CD environment for ASP.NET Core apps, also refer to the article about Telerik license keys in CI/CD.
Sections in this article:
Basics
Often enough, you would want to set up Continuous Integration and/or Continuous Delivery (CI/CD) pipelines or builds for your project that uses the Telerik components. This is a valid scenario and the "one license per developer" license does not prevent you from doing so. The Telerik components are commercial software and as such can only be distributed through channels that are private and/or behind authentication.
There are a couple of common ways people implement CI/CD automated builds.
-
You can restore the Telerik NuGet packages by downloading them from the Telerik NuGet server using token-based authentication with a NuGet API key. This is the recommended secure approach for CI/CD environments. See more on setting up the Telerik Private NuGet feed.
-
Creating a local folder (for example, on a shared network drive or other suitable location accessible only by your builds and team) that holds the
.nupkgfiles we provide (you can download them from your telerik.com account, or from your local installation - both automated and from the zip archive).
You must protect your credentials and/or the Telerik packages and ensure they are used only by you and not by other developers, according to the license-per-developer policy. As long as your credentials are obfuscated/masked, they can be used by your colleagues (e.g. developers, QAs, designers, front-end devs, DBAs, etc.) for building and running a solution, provided they do not use the Telerik components to create functionality. Most importantly, you must ensure that such credentials or package sources are not available to the general public (for example, in public repositories).
Azure DevOps Pipelines
When using Azure pipelines, we encourage you to review the following resources on setting things up:
- Blog post: Azure DevOps and Telerik NuGet Packages
- Sample Repo and Video Tutorial: Telerik DevOpsExamples by Lance McCarthy
There are a couple of common questions and issues:
- Obtaining credentials—See the points above for either using your own credentials, or using a shared package source.
- Telerik feed not being found—The most common reason for a problem is that the path to the
NuGet.Configfile is wrong (it must, by default, be at the root level). - An
index.json not founderror can occur from many root causes. If you have successfully authenticated, this error usually means that the feed was not able to be searched or connected to. A common reason is an incorrect feed URL, such as including a trailing slash—Correct:https://nuget.telerik.com/v3/index.jsonand Incorrect:https://nuget.telerik.com/v3/index.json/.
A few things to double check to ensure correct setup:
-
The Service connection is using Basic Authentication and the URL is correct (
https://nuget.telerik.com/v3/index.jsonexactly, no trailing slash). -
That Service Connection is selected as the credentials source.
-
The credentials being used have a UI for ASP.NET Core license.
-
Ensure that you use
dotnet restoreand notnuget restorein your pipeline step.
GitHub Secrets
For GitHub Actions workflows, use NuGet API keys for secure authentication with the Telerik NuGet server. See Restoring NuGet Packages in Your CI Workflow for detailed instructions.
To set up API key authentication:
- Generate a NuGet API key from your Telerik account.
- Store it as a GitHub Actions Secret named
TELERIK_NUGET_KEY. - Use the API key in your workflow as shown in Restoring NuGet Packages in Your CI Workflow.
GitHub does not allow secrets to be used in workflows that have been triggered by a pull request event. In such a case, the runner will not be able to authenticate with the Telerik NuGet server and the job will expectedly fail.
Docker
When building or restoring ASP.NET Core apps in Docker, the crucial steps are:
- Have a
NuGet.Configfile in the project or solution folder. The file can define the Telerik NuGet feed, but without the credentials. - Copy the
NuGet.Configfile together with the.csprojfile(s) to the Docker image. - Add or update the Telerik NuGet feed with the stored Telerik NuGet credentials (secrets). When specifying the
NuGet.Configfile location, note that file names are case-sensitive on Unix systems. - Restore or build the app.
The following code is the build portion of a sample Dockerfile that builds a .NET 8 ASP.NET Core app. The dotnet restore command is executed from the src folder of the Docker image (where the NuGet.Config is copied), so that the NuGet.Config file can be used to restore all projects in the solution.
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
# Copy the project file to restore
COPY ["MyAspNetCoreApp/MyAspNetCoreApp.csproj", "MyAspNetCoreApp/"]
# Copy the NuGet.Config file without the Telerik credentials to /src
COPY ["NuGet.Config", "."]
# Update the Telerik NuGet source and add credentials from your secrets storage
RUN dotnet nuget update source "TelerikFeed" --username ... --password ... --configfile "./NuGet.Config" --store-password-in-clear-text
# Restore the NuGet packages for the ASP.NET Core app
RUN dotnet restore "./MyAspNetCoreApp/MyAspNetCoreApp.csproj"
# Copy the whole ASP.NET Core app
COPY . .
# Build the app
WORKDIR "/src/MyAspNetCoreApp"
RUN dotnet build "./MyAspNetCoreApp.csproj" -c Release -o /app/buildFurther Reading
You may find useful the following Microsoft articles on securing your NuGet feed setup and supply chain as general best practices:
- Lock down your dependencies using configurable trust policies - Blog Post
- How to Scan NuGet Packages for Security Vulnerabilities - Blog Post
- Best practices for a secure software supply chain - MSDN docs
Telerik provides signed NuGet packages that you can verify.