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

Additional package metadata #39

Merged
merged 1 commit into from
Mar 23, 2017
Merged

Additional package metadata #39

merged 1 commit into from
Mar 23, 2017

Conversation

danbelcher-MSFT
Copy link
Contributor

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

@msftclas
Copy link

@danbelcher-MSFT,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

Copy link
Member

@HowardWolosky HowardWolosky left a 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.

@@ -813,3 +813,52 @@ function Resolve-UnverifiedPath
return $resolvedPath.ProviderPath
}
}

function Remove-UnofficialSubmissionProperties
Copy link
Member

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.

Copy link
Contributor Author

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.
Copy link
Member

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.

# 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.
Copy link
Member

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.

)

# String constants for UAP namespaces
$script:uapNamespaces = @(
Copy link
Member

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.

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'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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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 = @(
Copy link
Member

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

Copy link
Contributor Author

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
Copy link
Member

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?

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 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.

Copy link
Member

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.

$deviceFamilyCollection = @()
foreach ($family in $Metadata.targetDeviceFamiliesEx)
{
$index = $family.IndexOf($target)
Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Great tip, thanks!

$formattedBundleTags = @($Metadata.name, $version, $architectureTag)
if ($deviceFamilyCollection.Count -gt 0)
{
$formattedBundleTags = @(($deviceFamilyCollection | Sort-Object) -join '.') + $formattedBundleTags
Copy link
Member

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 '.')

Copy link
Contributor Author

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?

Copy link
Member

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.

Copy link
Contributor Author

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.

}
}

$metadata.name = Get-FormattedFilename -Metadata $metadata
Copy link
Member

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?

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 see the confusion. I agree with the suggestion to change this property to 'formattedFileName'.

@@ -813,3 +813,52 @@ function Resolve-UnverifiedPath
return $resolvedPath.ProviderPath
}
}

function Remove-UnofficialSubmissionProperties
Copy link
Member

Choose a reason for hiding this comment

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

Nice abstraction

@HowardWolosky
Copy link
Member

Do a rebase to flatten your change out to a single change, and update the version in the psd1 (increment the minor version (major.minor.patch) and reset patch to 0).

… 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
@danbelcher-MSFT danbelcher-MSFT merged commit 391954b into microsoft:master Mar 23, 2017
@danbelcher-MSFT danbelcher-MSFT deleted the forked/AdditionalPackageMetadata branch January 30, 2018 01:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants