Skip to content

Convert the artifacts folder layout to match Arcade #6850

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

Merged
merged 4 commits into from
Jan 18, 2019

Conversation

natemcmaster
Copy link
Contributor

@natemcmaster natemcmaster commented Jan 18, 2019

Changes:

  • IsProductPackage => IsShippingPackage
  • artifacts/$config/packages => artifacts/packages/$config
  • packages/product => packages/Shipping
  • packages/internal => packages/NonShipping
  • Renamed MSBuild properties used for output folders
  • Update build tools to use 2 spaces in global.json

Mark the following packages as shipping. They are listed in artifacts.props, but are missing the right setting in .csproj

This repo will be converting soon to use Arcade. This updates the layout the artifacts folder, and uses Arcade property names

Changes:
* IsProductPackage => IsShippingPackage
* artifacts/$config/packages => artifacts/packages/$config
* packages/product => packages/Shipping
* packages/internal => packages/NonShipping
* Renamed MSBuild properties used for output folders
* Update build tools to use 2 spaces in global.json

This repo will be converting soon to use Arcade. This updates the layout the artifacts folder, and uses Arcade property names
@natemcmaster
Copy link
Contributor Author

cc @tmat @markwilkie

@Tratcher Tratcher removed their request for review January 18, 2019 19:01
@natemcmaster natemcmaster requested a review from pranavkm January 18, 2019 19:03
@Eilon Eilon added the area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework label Jan 18, 2019
@natemcmaster natemcmaster requested review from dougbu and removed request for jkotalik, SteveSandersonMS and pranavkm January 18, 2019 19:48
<ProductPackageOutputPath>$(ArtifactsDir)$(Configuration)\packages\product\</ProductPackageOutputPath>
<InternalPackageOutputPath>$(ArtifactsDir)$(Configuration)\packages\internal\</InternalPackageOutputPath>
<InstallersOutputPath>$(ArtifactsDir)$(Configuration)\installers\</InstallersOutputPath>
<ArtifactsShippingPackagesDir>$(ArtifactsDir)\packages\$(Configuration)\Shipping\</ArtifactsShippingPackagesDir>
Copy link
Member

Choose a reason for hiding this comment

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

Suggest moving these properties to one file and importing that from here, the root Directory.Build.props file and anywhere else they're needed e.g. the templating Directory.Build.props file

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This can happen once we implement #4257

Copy link
Member

@dougbu dougbu Jan 18, 2019

Choose a reason for hiding this comment

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

What's the connection? (These properties aren't framework-specific or conditional, $(ArtifactsDir) could be moved to the common .props file, and %(Configuration) is fine.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Once we do #4247, we will be able to build the shared framework without having to build, pack, and then restore against the packages we just made.

%(ArtifactsDir) could be moved to the common

It could be, but I'm trying to reduce the number of things imported into the KoreBuild context and push as much down into the project-context as possible.

By the way, variables use the $ sign - $(ArtifactsDir). Percent sign %( means batch an item group.

Copy link
Member

Choose a reason for hiding this comment

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

Got it. And, I apologize for my fumble with the %-sign. I'll edit my comment 😈

@@ -8,10 +8,10 @@
By default, all projects which produce packages are not intended to ship to NuGet.org as a product package.
Packages which are intended to ship to NuGet.org must opt-in by setting this to true in the project file.
-->
<IsProductPackage Condition=" '$(IsProductPackage)' == '' ">false</IsProductPackage>
<IsShippingPackage Condition=" '$(IsShippingPackage)' == '' ">false</IsShippingPackage>
Copy link
Member

Choose a reason for hiding this comment

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

Suggest moving these properties to one file and importing that from here, the root Directory.Build.targets file and anywhere else they're needed

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yup, that will happen as a part of #4246.

Copy link
Member

Choose a reason for hiding this comment

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

What's the connection?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

src/Templating/ still builds as if it was a git submodule in its own repo. This file doesn't import the parent Directory.Build.targets file.

Copy link
Member

Choose a reason for hiding this comment

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

I understand that. But, it could import a new centralized file that's used elsewhere. Then again, I get that the .targets duplication is only between two files and that'll go away when Templating does import the root Directory.Build.targets file

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I tried doing that a while ago, but it made things more complicated. There are too many assumptions in both src/Templating/ and the repo-root D.B.targets which conflict. It was easier to keep these two projects in separate scopes with a little code duplication while we work on finishing up #4246.

@natemcmaster natemcmaster merged commit 922512a into dotnet:master Jan 18, 2019
@natemcmaster natemcmaster deleted the ship branch January 18, 2019 21:38
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.

4 participants