Open BMurri opened 2 years ago
Turns out adding the UseDotNet@2
task to the pipeline causes the desired SDK to be used by both tasks, but it doesn't alter the fact that both invocations of the exact same task-name/version employ two different paths to the dotnet binary. It's completely unexpected that two subsequent invocations of the exact same task would result in different binaries being run.
Adding the UseDotNet@2
task did not resolve this issue for me. The DotNetCoreCLI@2 seems to always use an older version of the CLI. The project in question here was built with Azure Function Core Tools. The publish task works when run as a script, but fails when run using DotNetCoreCLI@2
yaml:
steps:
- task: UseDotNet@2
inputs:
version: '6.x'
- task: DotNetCoreCLI@2
inputs:
command: build
- script: |
dotnet publish
continueOnError: true
- task: DotNetCoreCLI@2
inputs:
command: publish
continueOnError: true
Start of logs for both the build and publish tasks using the DotNetCoreCLI@2 task:
==============================================================================
Task : .NET Core
Description : Build, test, package, or publish a dotnet application, or run a custom dotnet command
Version : 2.208.1
Author : Microsoft Corporation
Help : https://docs.microsoft.com/azure/devops/pipelines/tasks/build/dotnet-core-cli
==============================================================================
Info: .NET Core SDK/runtime 2.2 and 3.0 are now End of Life(EOL) and have been removed from all hosted agents. If you're using these SDK/runtimes on hosted agents, kindly upgrade to newer versions which are not EOL, or else use UseDotNet task to install the required version.
This issue is stale because it has been open for 180 days with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days
Commenting so this won't go state. I am encountering this as well.
In actions/runner-images#7218 it was discovered that the order of directories in PATH seems to change randomly with NO changes to any pipeline job anything. That issue was closed as a duplicate of another issue that doesn't appear to have anything to do with PATH, but that's a soapbox for another day.
I think it would be prudent to consider that PATH is suddenly changing between builds with no changes that should warrant any change to PATH. Furthermore, it appears that most of the pipeline components look for their binaries via PATH and never verify that the correct binary is actually invoked.
This issue is stale because it has been open for 180 days with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days
Commenting so this won't go state. This needs attention from someone in Azure.
This issue is stale because it has been open for 180 days with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days
Commenting again so this won't go stale.
On Fri, Mar 15, 2024, 9:06 p.m. github-actions[bot] < @.***> wrote:
This issue is stale because it has been open for 180 days with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days
— Reply to this email directly, view it on GitHub https://github.com/microsoft/azure-pipelines-tasks/issues/16683#issuecomment-2001343868, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASCFEUL2Z7W7RUH4K6K5VLYYOZMFAVCNFSM55K3TPUKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBQGEZTIMZYGY4A . You are receiving this because you commented.Message ID: @.***>
Commenting again so this won't go stale.
Required Information
Entering this information will route you directly to the right team and expedite traction.
Question, Bug, or Feature?
Type: Bug or Question
Enter Task Name: DotNetCoreCLI@2
Environment
Server - Azure Pipelines
#3.2.22214.5811
Agent - Hosted
Issue Description
Different instances of this task are running different versions of dotnet.exe, even though the settings are the same and only one SDK is expected for the entire pipeline.
All *proj files start out this same way:
Compare the task
dotnet build
anddotnet publish TesApi and TriggerService
yaml:
Beginning of log:
to
yaml:
Beginning of log:
Task logs
See above