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

Remove dotnet-format from dotnet-tools #30317

Merged
1 commit merged into from
Feb 20, 2021
Merged

Conversation

Tratcher
Copy link
Member

Restore.cmd is failing because it can't find this tool on our feeds. The version it's looking for isn't even on nuget.org. https://www.nuget.org/packages/dotnet-format/

We're not using this tool right now so I'm removing it.

@Tratcher Tratcher requested a review from a team February 20, 2021 00:46
@Tratcher Tratcher self-assigned this Feb 20, 2021
@ghost ghost added the area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework label Feb 20, 2021
Copy link
Member

@dougbu dougbu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fine to remove because @SteveSandersonMS removed the pre-commit hook using dotnet-format.

Need for this cleanup is a bit odd however. The package must exist somewhere or our CI builds would have failed. I see Tool 'dotnet-format' (version '5.0.210401') was restored. Available commands: dotnet-format at https://dev.azure.com/dnceng/public/_build/results?buildId=1003771&view=logs&j=efda9e5f-cf98-536e-4181-9b6c13ac35b3&t=de5280bb-c511-517b-1959-798dcf9a84da&l=50 for example. (CodeCheck.ps1 executes restore.cmd)

So, go ahead but I'd love to know what leads to the errors you saw.

@Tratcher
Copy link
Member Author

Tratcher commented Feb 20, 2021

False alarm. I figured out that my global nuget.config had one of our feeds listed under disabledPackageSources. aspnetcore's nuget.config clears the global state for packageSources, but not for disabledPackageSources. Should we clear that too?

@ghost
Copy link

ghost commented Feb 20, 2021

Hello @Tratcher!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

Do note that I've been instructed to only help merge pull requests of this repository that have been opened for at least 60 minutes, a condition that will be fulfilled in about 41 minutes. No worries though, I will be back when the time is right! 😉

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

@dougbu
Copy link
Member

dougbu commented Feb 20, 2021

FYI this isn't really about ./restore.cmd in particular. The Arcade SDK executes dotnet tool restore in the repo root directory (which picks up the config file changed here) as part of every Restore build. So, pretty much every use of our build.* scripts (even with /t:noop) will restore the listed tools.

Separately, the specified dotnet-format version is in the dotnet-tools feed. That works fine because that feed is in our NuGet.config file and automatically used by dotnet tool restore. Still don't get why you were hitting errors @Tratcher

@dougbu
Copy link
Member

dougbu commented Feb 20, 2021

Oops, missed your "False alarm" @Tratcher 😺

aspnetcore's nuget.config clears the global state for packageSources, but not for disabledPackageSources. Should we clear that too?

I doubt it would hurt but defer to @MattGal because he has done recent work on Maestro++'s automatic NuGet.config changes when we need to reference (but disable by default) internal / infernal feeds. @MattGal any objections to changing from <disabledPackageSources /> (our current state in 'main') to

<disabledPackageSources><clear /></disabledPackageSources>

@ghost ghost merged commit fd0d314 into dotnet:main Feb 20, 2021
@MattGal
Copy link
Member

MattGal commented Feb 22, 2021

@dougbu no objection here. Newly added ones from later automation should be added beneath the last clear found, so barring a bug that shouldn't cause trouble.

@ghost
Copy link

ghost commented Feb 22, 2021

Hi @MattGal. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.

@Tratcher Tratcher deleted the tratcher/unformat branch February 22, 2021 17:14
@dougbu
Copy link
Member

dougbu commented Feb 22, 2021

@Pilchie what do you think about making similar changes in our Maestro++ servicing branches i.e. 3.1 / 6.4 and 5.0❔ Feels to me like straightforward goodness but I'd appreciate your take.

@Pilchie
Copy link
Member

Pilchie commented Feb 22, 2021

Seems reasonable to me.

@dougbu
Copy link
Member

dougbu commented Feb 23, 2021

This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants