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

Allow incremental servicing of packages and more packaging infra cleanup #46447

Merged
merged 4 commits into from
Dec 31, 2020

Conversation

ViktorHofer
Copy link
Member

@ViktorHofer ViktorHofer commented Dec 29, 2020

Requires dotnet/arcade#6728
Based on the discussion in #46180

This PR further cleans up the packaging infra and allows "incremental servicing" at project level instead of traversal level (as it was before for libraries). By default, nuget csprojs or pkgprojs will be built if the <GeneratePackage /> property is set to true.

The GeneratePackage property is currently conditioned as:

    <GeneratePackage Condition="(('$(PreReleaseVersionLabel)' != 'servicing' and
                                  '$(RepositoryName)' != 'runtimelab') or
                                 '$(BuildAllProjects)' != 'true')">true</GeneratePackage>

This means that during servicing or as part of runtimelab, root builds won't generate packages unless a project opts in via <GeneratePackage />. <BuildAllProjects /> identifies a builds as a root build (vs an individual project build: dotnet pack ...).

I wasn't sure how to condition runtimelab so I used the RepositoryName property for now.

@Dotnet-GitSync-Bot
Copy link
Collaborator

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

@ghost
Copy link

ghost commented Dec 29, 2020

Tagging subscribers to this area: @ViktorHofer
See info in area-owners.md if you want to be subscribed.

Issue Details

Requires dotnet/arcade#6728
Based on the discussion in #46180

This further clean-up allows "incremental servicing" at project level instead of traversal level as it was before for libraries. By default, none nuget csprojs or pkgprojs will be built if the <GeneratePackage /> property isn't set to true.

The GeneratePackage property is currently conditioned as:

    <GeneratePackage Condition="(('$(PreReleaseVersionLabel)' != 'servicing' and
                                  '$(RepositoryName)' != 'runtimelab') or
                                 '$(BuildAllProjects)' != 'true')">true</GeneratePackage>

I wasn't sure how to condition runtimelab so I used the RepositoryName property for now.

Author: ViktorHofer
Assignees: ViktorHofer
Labels:

area-Infrastructure

Milestone: -

@ViktorHofer ViktorHofer changed the title More packaging cleanup Allow incremental servicing of packages and more packaging infra cleanup Dec 29, 2020
Copy link
Contributor

@Anipik Anipik left a comment

Choose a reason for hiding this comment

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

Packing changes for the libraries looks good. I believe there are no functional change in coreclr related changes. its seem like just refactoring ?

@ViktorHofer
Copy link
Member Author

The change applies to all packages in the repo that use the nuget pack task or pkgprojs. It means that no packages will be generated in servicing by default unless we set the to true in their project file. I'm unsure which packages we always want to generate but I assume the sfx ones?

@ViktorHofer
Copy link
Member Author

Timeout is #46484

@ViktorHofer ViktorHofer merged commit 752c927 into dotnet:master Dec 31, 2020
@ViktorHofer ViktorHofer deleted the PackagingCleanup branch December 31, 2020 10:20
<!-- A package isn't generated (in traversal builds) if in servicing or in runtimelab. Intended to be overridden at project level. -->
<GeneratePackage Condition="'$(GeneratePackage)' == ''">true</GeneratePackage>
<GeneratePackage Condition="(('$(PreReleaseVersionLabel)' == 'servicing' or
'$(RepositoryName)' == 'runtimelab') and
Copy link
Member

Choose a reason for hiding this comment

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

How is the RepositoryName meant to be set in runtimelab?

@ghost ghost locked as resolved and limited conversation to collaborators Feb 3, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants