-
Notifications
You must be signed in to change notification settings - Fork 39
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
Additional package metadata #39
Additional package metadata #39
Conversation
@danbelcher-MSFT, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, I really like this change. I like the way that you abstracted out the logic. Just looks like some minor changes to make before we bring it in.
StoreBroker/Helpers.ps1
Outdated
@@ -813,3 +813,52 @@ function Resolve-UnverifiedPath | |||
return $resolvedPath.ProviderPath | |||
} | |||
} | |||
|
|||
function Remove-UnofficialSubmissionProperties |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the exception of Initialize-HelpersGlobalVariables
due to some of those globals being used within Helpers.ps1
itself, Helpers is really designed to be "commands that PowerShell doesn't natively have, but would be useful." This method should probably be moved into StoreIngestionApi.psm1 for sharing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved to StoreIngestionApi.psm1
# Now, we'll remove the appId property since it's not really valid in submission content. | ||
# We can safely call this method without validating that the property actually exists. | ||
$submission.PSObject.Properties.Remove('appId') | ||
# Remove properties that aren't valid in submission content. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Due to the very well named helper function here, this comment adds no value.
StoreBroker/StoreIngestionIapApi.ps1
Outdated
# Now, we'll remove the iapId property since it's not really valid in submission content. | ||
# We can safely call this method without validating that the property actually exists. | ||
$submission.PSObject.Properties.Remove('iapId') | ||
# Remove properties that aren't valid in submission content. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Due to the very well named helper function here, this comment adds no value.
StoreBroker/PackageTool.ps1
Outdated
) | ||
|
||
# String constants for UAP namespaces | ||
$script:uapNamespaces = @( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like this approach puts StoreBroker in a maintenance scenario where we'd have to keep the list up-to-date each time the Windows SDK introduces a new namespace. All of these namespaces have "Windows10" in them...can we trigger off that instead? Seems like a more future-proof approach.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with making this change, however, the reason we asked Store team for the set of namespaces to use was because you didn't want to do a generic search for "Windows10". Still prefer the search over the namespace set?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will change to the string search. Agreed that it is more future-proof.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed to use the string search instead of maintaining the namespace set.
@@ -24,6 +24,36 @@ $script:s_OutPath = "OutPath" | |||
$script:s_OutName = "OutName" | |||
$script:s_DisableAutoPackageNameFormatting = "DisableAutoPackageNameFormatting" | |||
|
|||
# String constants for application metadata | |||
$script:applicationMetadataProperties = @( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think i'd rather see this contained as a local var within New-ApplicationMetadataTable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed in a later comment. These properties need to be referenced elsewhere so it's better to keep as a script var.
|
||
# Grab an arbitrary one and use that version. | ||
$arch = $Metadata.innerPackages.Keys | Sort-Object | Select -First 1 | ||
$version = $Metadata.innerPackages.$arch.version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking maybe we should change to using the bundle version in this scenario. Can you confirm with Release that they would be ok with that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I asked Release team and they said they do not want that. They want to always use the appx version, acknowledging that inner appx packages might not necessarily have the same version. We will simply use the version of the last appx processed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alrighty. Sounds good. Just wanted to make sure we checked with them first.
StoreBroker/PackageTool.ps1
Outdated
$deviceFamilyCollection = @() | ||
foreach ($family in $Metadata.targetDeviceFamiliesEx) | ||
{ | ||
$index = $family.IndexOf($target) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this section could be simplified significantly to just do this:
$target -replace '^Windows.', ''
(that says, if the string starts with "Windows.", replace that with nothing. Then return the resulting string regardless.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great tip, thanks!
StoreBroker/PackageTool.ps1
Outdated
$formattedBundleTags = @($Metadata.name, $version, $architectureTag) | ||
if ($deviceFamilyCollection.Count -gt 0) | ||
{ | ||
$formattedBundleTags = @(($deviceFamilyCollection | Sort-Object) -join '.') + $formattedBundleTags |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like this line would read easier as:
$formattedBundleTags += ($deviceFamilyCollection | Sort-Object) -join '.')
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, the code you suggested would add the deviceFamilyCollection to the end of the name, whereas my code is explicitly adding it as the beginning. The current implementation follows the structure requested by Release team. Should I ask them if they'd be okay with this change? Or would you rather keep as is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Keep as is. You're totally right. Misread the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed to keep as is.
StoreBroker/PackageTool.ps1
Outdated
} | ||
} | ||
|
||
$metadata.name = Get-FormattedFilename -Metadata $metadata |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm confused that the inner methods are calculating $metadata.name
, but then you're replacing it here. Should they be storing their property somewhere else? Maybe use a different property name here like formattedFileName
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see the confusion. I agree with the suggestion to change this property to 'formattedFileName'.
StoreBroker/Helpers.ps1
Outdated
@@ -813,3 +813,52 @@ function Resolve-UnverifiedPath | |||
return $resolvedPath.ProviderPath | |||
} | |||
} | |||
|
|||
function Remove-UnofficialSubmissionProperties |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice abstraction
Do a rebase to flatten your change out to a single change, and update the version in the psd1 (increment the minor version ( |
… the New-SubmissionPackage command. New metadata is added to each object in 'applicationPackages'. The new fields are: -version -architecture -targetPlatform -languages -capabilities -targetDeviceFamilies -targetDeviceFamiliesEx -minOSVersion -innerPackages These properties are removed during a submission because they are re-calculated by the Store. Resolves #16
This change adds additional package metadata to the output .JSON from the New-SubmissionPackage command.
New metadata is added to each object in 'applicationPackages'. The new fields are:
-version
-architecture
-targetPlatform
-languages
-capabilities
-targetDeviceFamilies
-targetDeviceFamiliesEx
-minOSVersion
-innerPackages
These properties are removed during a submission because they are re-calculated by the Store.
Resolves #16