Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

3774 new binaries introduced into VMR #4395

Closed
Winniexu01 opened this issue May 11, 2024 · 7 comments · Fixed by dotnet/sdk#40844
Closed

3774 new binaries introduced into VMR #4395

Winniexu01 opened this issue May 11, 2024 · 7 comments · Fixed by dotnet/sdk#40844
Assignees
Labels
ops-monitor Issues created/handled by the source build monitor role

Comments

@Winniexu01
Copy link

main build: https://dev.azure.com/dnceng/internal/_build/results?buildId=2449450&view=logs&j=fa5c2909-0e29-5671-d5eb-16d6c40e0c4a&t=2a0bd486-3f67-5c59-da0c-b84d88848a4b

New binaries:
  src/sdk/.dotnet/dotnet
  src/sdk/.dotnet/host/**
  src/sdk/.dotnet/packs/**
  src/sdk/.dotnet/sdk/**
  src/sdk/.dotnet/shared/**
  src/sdk/.dotnet/templates/**
  artifacts/bin/**
  artifacts/obj/**

More information:
NewBinaries.txt
allowed-sb-binaries.txt
allowed-vmr-binaries.txt

@Winniexu01 Winniexu01 added the ops-monitor Issues created/handled by the source build monitor role label May 11, 2024
@mthalman
Copy link
Member

@ellahathaway - PTAL. These binaries don't exist in the repo.

@ViktorHofer
Copy link
Member

Potentially regressed with dotnet/sdk@d5cb00f?

@ellahathaway
Copy link
Member

The BinaryToolKit binaries make sense. I'll add those to the ignore file.

As far as the rest of the binaries, it looks like the Initialize Tooling step of Tag & Scan installs dotnet into src/sdk in order to use darc: Adding to current process PATH: /mnt/vss/_work/1/s/src/sdk/.dotnet To fix that, I'll make the ignored .dotnet/ be **/.dotnet/.

@akoeplinger
Copy link
Member

@ellahathaway alternatively we could use the root dir as the working directory and pass --tool-manifest src/sdk/.config/dotnet-tools.json to dotnet tool restore

@ellahathaway
Copy link
Member

ellahathaway commented May 13, 2024

alternatively we could use the root dir as the working directory and pass --tool-manifest src/sdk/.config/dotnet-tools.json to dotnet tool restore

This is a much better alternative. Thanks for pointing this out! I'll update the PR accordingly.

Edit: Tried to configure this locally, and I can't seem to get darc installed correctly. After setting up vmr/.dotnet, I ran .dotnet/dotnet tool restore --tool-manifest src/sdk/.config/dotnet-tools.json which succeeded. However, .dotnet/dotnet darc returns:

Could not execute because the specified command or file was not found.
Possible reasons for this include:
  * You misspelled a built-in dotnet command.
  * You intended to execute a .NET program, but dotnet-darc does not exist.
  * You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on the PATH.

@akoeplinger
Copy link
Member

@ellahathaway hm interesting, the --tool-manifest option looks a bit pointless then :)
You can make it work if you run the commands in the src/sdk directory but with the dotnet from the root:

source eng/common/tools.sh
InitializeDotNetCli true

cd src/sdk
../../.dotnet/dotnet tool restore
../../.dotnet/dotnet darc

@ellahathaway
Copy link
Member

You can make it work if you run the commands in the src/sdk directory but with the dotnet from the root

This worked locally for me. Thanks for your help!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ops-monitor Issues created/handled by the source build monitor role
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

5 participants