Skip to content

'Install MicroBuild plugin' step fails on Linux #15946

@radical

Description

@radical

If I use /eng/common/templates-official/jobs/jobs.yml@self with:

        parameters:
          enableMicrobuild: true
          enableMicrobuildForMacAndLinux: true
            
        pool:
              name: NetCore1ESPool-Internal
              image: 1es-mariner-2
              os: linux

.. then the installation fails in weird ways. I think it might be trying to install it is various ways and fails like apt, downloading the nuget, fails to install a usable dotnet. Is this expected to fail, or am I doing something wrong here?

Installing nuget.exe on linux linux
/bin/sudo apt -y install nuget
sudo: apt: command not found

...

The command could not be loaded, possibly because:
  * You intended to execute a .NET application:
      The application 'nuget' does not exist.
  * You intended to execute a .NET SDK command:
      A compatible .NET SDK was not found.

Requested SDK version: 10.0.100-preview.5.25277.114
global.json file: /mnt/vss/_work/1/s/global.json

Installed SDKs:

Install the [10.0.100-preview.5.25277.114] .NET SDK or update [/mnt/vss/_work/1/s/global.json] to match an installed SDK.

...

https://dev.azure.com/dnceng/internal/_build/results?buildId=2742883&view=logs&j=eb401065-014f-5a28-ce58-60c8842a1624&t=a94ff4a9-b7b2-591f-976b-0bb2e80d660b

This is with the repo containing https://github.com/dotnet/aspire/blob/1c1ced151d063e9e0ae242331db0f951b4ef769d/global.json

{
  "sdk": {
    "version": "10.0.100-preview.5.25277.114",
    "rollForward": "major",
    "allowPrerelease": true
  },
  "tools": {
    "dotnet": "10.0.100-preview.5.25277.114",
    "runtimes": {
      "dotnet/x64": [
        "$(DotNetRuntimePreviousVersionForTesting)",
        "$(DotNetRuntimeCurrentVersionForTesting)"
      ],
      "dotnet/arm64": [
        "$(DotNetRuntimePreviousVersionForTesting)",
        "$(DotNetRuntimeCurrentVersionForTesting)"
      ],
      "aspnetcore/x64": [
        "$(DotNetRuntimePreviousVersionForTesting)",
        "$(DotNetRuntimeCurrentVersionForTesting)"
      ],
      "aspnetcore/arm64": [
        "$(DotNetRuntimePreviousVersionForTesting)",
        "$(DotNetRuntimeCurrentVersionForTesting)"
      ]
    }
  },
  "msbuild-sdks": {
    "Microsoft.Build.NoTargets": "3.7.0",
    "Microsoft.Build.Traversal": "3.2.0",
    "Microsoft.DotNet.Arcade.Sdk": "10.0.0-beta.25351.1",
    "Microsoft.DotNet.Helix.Sdk": "10.0.0-beta.25351.1",
    "Microsoft.DotNet.SharedFramework.Sdk": "10.0.0-beta.25351.1"
  }
}

@akoeplinger said:

the apt step failing is harmless, it will fallback to using "dotnet". but it looks like it picks up the sdk from your global.json.
I think we haven't hit this because we've only really been using the mac/linux microbuild support in the VMR and our global.json there doesn't have an "sdk" entry

Issue based on a question asked in Teams.
cc @ellahathaway @joperezr

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions