ABP Framework version: v4.2.1
UI type: Angular
DB provider: EF Core
Tiered (MVC) or Identity Server Separated (Angular): separated Identity Servers
Exception message and stack trace:
dotnet restore shell: /usr/bin/bash -e env: DOTNET_VERSION: 5.0.x AZURE_API_PACKAGE_PATH: . AZURE_API_NAME: one-village-api AZURE_IDENTITY_API_NAME: one-village-identity AZURE_PARENT_IDENTITY_API_NAME: one-village-parent-identity AZURE_PROVIDER_IDENTITY_API_NAME: one-village-provider-identity ASPNETCORE_ENVIRONMENT: Staging DOTNET_ROOT: /home/runner/.dotnet
Determining projects to restore...
Retrying 'FindPackagesByIdAsync' for source 'https://nuget.abp.io/OUR-GUID-HERE/v3/package/volo.abp.leptontheme.management.application/index.json'.
Response status code does not indicate success: 500 (Internal Server Error).
Retrying 'FindPackagesByIdAsync' for source 'https://nuget.abp.io/OUR-GUID-HERE/v3/package/volo.payment.domain/index.json'.
Response status code does not indicate success: 500 (Internal Server Error).
etc
- Steps to reproduce the issue:
We running the same command dotnet restore inside Github Actions (CI/CD pipeline). Sometimes it succeed, sometimes it fails (seems randomly). When it fails, we see error above.
There is no way for us to determine why it might fail to restore ABP Commercial pages.
We do have Feed configured in the NuGet.config file like this:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
<add key="BlazoriseMyGet" value="https://www.myget.org/F/blazorise/api/v3/index.json" />
<add key="ABP Commercial NuGet Source" value="https://nuget.abp.io/OUR-GUID-HERE/v3/index.json" />
</packageSources>
</configuration>
Again, we know it's not issue with that "OUR-GUID-HERE" value because sometimes it succeed and also because our developers use same GUID and it working in VS without any issues.
So I think the main question is why ABP.IO NuGet server reply with error 500 to such requests sometimes?
Also, note that we do set ASPNETCORE_ENVIRONMENT: Staging as I think it should be not set to Development to bypass license counter (as CI/CD is not a developer / license).
Please let us know what we are doing wrong. Currently, 1/2 of builds succeeds and we retry build if it fails few times for it to succeed etc.
P.S. let me know if you want me to send value of "OUR-GUID-HERE" because I am not sure if this Question is public or not
This is our Github Actions yml file content:
build_api:
runs-on: ubuntu-latest
steps:
- name: Check out Git repository
uses: actions/checkout@v2
- name: Setup .NET
uses: actions/setup-dotnet@v1
with:
dotnet-version: ${{ env.DOTNET_VERSION }}
- name: Install Node.js, NPM and Yarn
uses: actions/setup-node@v1
with:
node-version: 14.5
- name: Restore NuGet
run: |
cd api
dotnet restore
- name: Build and Publish API
run: |
cd api/src/OneVillage.HttpApi.Host
dotnet build --configuration Release --no-restore
dotnet publish -c Release -o '${{ env.AZURE_API_PACKAGE_PATH }}/package' --no-restore
and per initial description of issue, it fails in the step "Restore NuGet" where we call dotnet restore.
5 Answer(s)
-
0
Hi @ever
Could you share a time when you get 500 error ? We can investigate the logs on our side.
Thank you,
-
0
I can't tell exact times because I don't see that info in Github Actions executions... It happens 10 March 2021 and before, at least few times per day. Today we temporary fixed that issue by including NuGet packages folder in our Git repo, so restore process don't try to load them again from your APIs... So if you can just take a look into requests which error 500 on 10 March 2021 to something like https://nuget.abp.io/OUR-GUID-HERE/v3/package/volo.abp.leptontheme.management.application/index.json you will see it's our requests.... (let me know if I need to provide you our value for OUR-GUID-HERE)
-
0
I also notice that browser GET request to something like https://nuget.abp.io/76eb528e-8c3c-4379-9b6d-b5e7a6451e9e/v3/package/volo.abp.auditlogging.domain/index.json results in the same error 500 (I used some random GUID)... However, if I do same request with our real GUID value, it result in status 302 and redirect to https://nuget.abp.io/Error?httpStatusCode=404 page. So even from browser I can't make it work now with both real GUID and fake one...
-
0
Hi @ever,
Thank you for the detailed information. We will investigate this problem. The second one "Volo.Abp.AuditLogging.Domain" is not on our private NuGet but on nuget.org, see https://www.nuget.org/packages/Volo.Abp.AuditLogging.Domain/
As an alternative, you can use https://github.com/marketplace/actions/setup-nuget-exe-for-use-with-actions#caching, so your pipeline will not try to download same packages again every time.
-
0
This question has been automatically marked as stale because it has not had recent activity.
