dotnet restore fails when fetching from telerik servers

[Thomas]

Hi,

We have a system with Github Actions where we build our project whilst adding the telerik nuget repository.

And then it fails with a 500 error, it works sometimes, but not always.

    steps:
    - name: Checkout ${{ github.GITHUB_REF }}
      uses: actions/checkout@v2

    - name: Setup .NET Core
       uses: actions/setup-dotnet@v1
       with:
        dotnet-version: "5.0.x"
        
    - name: Setup Node.js environment
       uses: actions/setup-node@v2.1.2

    - name: Register Nuget Packages
       env: # Or as an environment variable
        telerik_username: ${{ secrets.telerik_username }}
        telerik_password: ${{ secrets.telerik_password }}
       run: dotnet nuget add source https://nuget.telerik.com/nuget --name telerik.com --username "$telerik_username" --store-password-in-clear-text --password "$telerik_password"

    - name: Install dependencies
       run: dotnet restore Project

2021-05-25T09:07:14.2001354Z   Retrying 'FindPackagesByIdAsyncCore' for source 'https://nuget.telerik.com/nuget/FindPackagesById()?id='Telerik.UI.for.AspNet.Core'&semVerLevel=2.0.0'.
2021-05-25T09:07:14.2008435Z   Response status code does not indicate success: 500 (Internal Server Error).
2021-05-25T09:07:14.2014387Z   Retrying 'FindPackagesByIdAsyncCore' for source 'https://nuget.telerik.com/nuget/FindPackagesById()?id='Telerik.UI.for.AspNet.Core'&semVerLevel=2.0.0'.
2021-05-25T09:07:14.2036427Z   Response status code does not indicate success: 500 (Internal Server Error).
2021-05-25T09:07:14.2081008Z /home/runner/.dotnet/sdk/5.0.203/NuGet.targets(131,5): error : Failed to retrieve information about 'Telerik.UI.for.AspNet.Core' from remote source 'https://nuget.telerik.com/nuget/FindPackagesById()?id='Telerik.UI.for.AspNet.Core'&semVerLevel=2.0.0'. [/home/runner/work/(project...)]

[Alexander]

Hi Marius,

Could you please confirm that you have included the Telerik.UI.for.AspNet.Core.nupkg and NuGet.config to your source and they will be available for restoration during Jenkins builds while developing the project on developers' machines. For example:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="NuGet" value="https://api.nuget.org/v3/index.json" />
    <add key="Telerik" value="https://nuget.telerik.com/nuget" />
  </packageSources>
  <packageSourceCredentials>
    <Telerik>
      <add key="Username" value="%TELERIK_USERNAME%" />
      <add key="ClearTextPassword" value="%TELERIK_PASSWORD%" />
    </Telerik>
  </packageSourceCredentials>
  <packageRestore>
    <add key="enabled" value="True" />
    <add key="automatic" value="True" />
  </packageRestore>
  <activePackageSource>
    <add key="All" value="(Aggregate source)" />
  </activePackageSource>
</configuration>

As long as you set the environment variables before the package restore/build, then NuGet will use it. You can find more info about how Nuget performs a restore here:

https://learn.microsoft.com/en-us/nuget/consume-packages/package-restore

For Jenkins, I was unable to find any clear-cut answers other than "just set the environment variable or dynamically add the package source (with credentials) that you can try as well:

https://stackoverflow.com/questions/25140081/make-jenkins-aware-of-custom-nuget-package-source

Unfortunately, Jenkins support is outside what we can assist with. If you continue to have issues with private package sources., I recommend contacting the Jenkins support channels/forums and asking about "How to Restore Packages in .NET Core from Private NuGet Feeds".

[Tsvetomir]

Hi, Thomas, 

In general, the only reason that I could think of causing the restore to fail is that the authentication for the Telerik UI private NuGet feed to fail.

Is it possible for you to remove the Telerik UI NuGet reference and add it once again? Ensure that the account's username that is in use has a valid license assigned. You could set up the NuGet via any of the following options:

https://docs.telerik.com/aspnet-core/installation/nuget-install#setup-with-nuget-cli

Could you share more details on how sometimes the restore fails? Are there specific steps that can be followed to reproduce the issue consistently? 

 

Regards,
Tsvetomir
Progress Telerik

[Thomas]

Hi, i am not sure but according to how our CI is setup, the nuget configuration always gets reconfigured each time a new change has happened to the master branch or pull request.

This restore fails sometimes, as in it does succeed on most of the runs, but recently has seen that it started to fail more often now. So i doubt it is the authentication, since then it wouldve return a 401 Logon Failed. But instead it just returns 500 Internal Server error.

[Aleksandar]

What is weird for me is the sporadic behavior of the failures. We have a section on CI/CD and build server configuration, but from what I can see you have followed the requirements. I will also assume the setup is correct and you have followed the guidelines we have here or here. You mention the job is running each time a change happens to the master branch or on pull request. One thing that makes me wonder is, if the failing jobs are not the once triggered from a pull request? As noted in the article, GitHub does not allow secrets to be used in workflows that have been triggered by a pull request event. Is it possible this was. Can you check if that is the case?

[Thomas]

According to the documentation that is linked in the article https://docs.github.com/en/actions/reference/events-that-trigger-workflows, github page does not say anything about that pull request is not allowed to use secrets, but forked repositories are disallowed, and all our pull requests are internal and within the repository.

https://docs.github.com/en/actions/reference/events-that-trigger-workflows#pull-request-events-for-forked-repositories

"With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository. The permissions for the GITHUB_TOKEN in forked repositories is read-only. For more information, see (link in article-link)"

[Aleksandar]

You are indeed correct - forked repositories are disallowed an we shall look into updating the statement in the documentation. That said we tested the provided steps on a build using GitHub Actions, but failed to reproduce the behavior. Setting up the feed with credentials, restoring the packages and building the application is successful both on commits to the master branch and on pull requests. We used the following configuration:

- name: Register Nuget Packages
run: dotnet nuget add source https://nuget.telerik.com/nuget --name telerik.com --username "$TELERIK_USERNAME" --store-password-in-clear-text --password "$TELERIK_PASSWORD"
env: # Or as an environment variable
TELERIK_USERNAME: ${{ secrets.MyTelerikAccountUsername }}
TELERIK_PASSWORD: ${{ secrets.MyTelerikAccountPassword }}

- name: Restore NuGet Packages
run: dotnet restore TelerikNugetRestore/TelerikNugetRestore/TelerikNugetRestore.csproj

- name: BuildProj
run: dotnet build TelerikNugetRestore/TelerikNugetRestore/TelerikNugetRestore.csproj

Can you share any further details on the issue? Any additional or more extensive log from when the error occurs? If you have any sensitive information you do not want to share in the forums you can open a support case, referencing this thread. We can later update the answer, once a resolution is available, on what has been causing the issue.

[jake]

Thanks for your sharing,That's pretty cool.

[steven littleford]

@Aleksandar - was there any further resolution to this issue?

I've got the same problem - intermittent failures with a 500 internal server error. It generally takes us 1-2 times restarting the workflow to get it to finish successfully, but its taken us up to 10 retrys before it works:

Response status code does not indicate success: 500 (Internal Server Error).

911Retrying 'FindPackagesByIdAsyncCore' for source 'https://nuget.telerik.com/nuget/FindPackagesById()?id='Telerik.Documents.Fixed'&semVerLevel=2.0.0'.

912Response status code does not indicate success: 500 (Internal Server Error).

 

Given that it occasionally works, it makes it hard to believe its a problem with the configuration on our side. This does sort of kill our CI/CD pipeline though if someone needs to go in and retry the build on a failure.

[Tsvetomir]

What I believe Aleksandar meant was that we were going to update the documentation stating the limitation with the forked repositories. However, regarding the failing fetch, I suspect that he has not managed to replicate the issue, therefore, no further actions were required. 

Could you try updating the credentials as he has shared and try to restore the NuGet packages once again?

[Marius]

Hi,

Is there any resolution for this issue?

I've got the same (intermittent) problem from a Jenkins pipeline.

[Marius]

Hi Alexander,

It seems that adding the NuGet.config file to the solution directory resolved the problem.

Thanks.