Skip to content

Assert source-built package-versions weren't restored by an earlier project #606

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

Closed
dagood opened this issue Jun 12, 2018 · 2 comments
Closed
Assignees
Labels
area-build Improvements in source-build's own build process

Comments

@dagood
Copy link
Member

dagood commented Jun 12, 2018

Catch this scenario and exit early:

  1. A dev attempts to upgrade CLI to the next version, e.g. 2.1.300-rc1 to 2.1.300.
  2. init-tools detects the runtime the new SDK is using, 2.1.0.
    • Before the upgrade, it would have detected, say, 2.1.0-rc1-12345.
  3. init-tools restores Microsoft.NETCore.App 2.1.0 from the NuGet Gallery.
  4. Core-Setup builds Microsoft.NETCore.App 2.1.0.
  5. CLI restores Microsoft.NETCore.App 2.1.0. It finds the NuGet Gallery one because the id + version already exists in packages/.
    • CLI is unable to get the source-built package. The important difference in this case is that the source-built package has the RID being source-built, e.g. centos.
  6. An error occurs in CLI because the NuGet Gallery package doesn't have the runtime being source-built.

The CLI error is difficult to investigate, since the cause is so far from the real problem. We can catch it after the Core-Setup build by looking at all the new packages in the blob feed and checking to see if any exist in packages/.

This kind of error isn't limited to tooling restore vs. a repo build--it could also happen between two source-built repos.

@dagood dagood added the area-build Improvements in source-build's own build process label Jun 12, 2018
@dagood
Copy link
Member Author

dagood commented Jul 2, 2018

We hit this again when trying to move from 2.1.300 => 2.1.301. (#623) The workaround is to make sure the tooling SDK contains a different runtime version than the one that Core-Setup is producing. (E.g. it's fine to upgrade to the N-1 version, but upgrading to N causes this issue.)

/cc @dseefeld

@dagood
Copy link
Member Author

dagood commented Jul 18, 2018

Making this assert as written would be good for diagnosing, but it's not compatible with the idea of the bootstrap flow where we expect some "circular" dependencies. E.g. Microsoft.NETCore.Platforms being required to build Platforms (#653 (comment)).

If the bootstrap flow is far enough away, this assert still seems worthwhile to me because it catches a pretty common issue and it wouldn't take much to implement. A basic idea is to verify after every build that all new source-built nupkgs aren't in the packages/ dir. (Or they match the nupkg in packages/ exactly, if there's a dependency within a single repo that gets resolved through packages.)

However, it might not be difficult to set up the bootstrap flow, either, and maybe we should just do that.

@dagood dagood closed this as completed Aug 29, 2018
@markwilkie markwilkie added this to the S141 Sept 3 - Sept 21 (9/3/2018) milestone Sep 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-build Improvements in source-build's own build process
Projects
None yet
Development

No branches or pull requests

3 participants