* Remove ARM64 from the package since Graphing mode does not support ARM64.
* Update build/pipelines/templates/package-appxbundle.yaml
Steph approves :)
Co-authored-by: Eric Wong <eriwong@microsoft.com>
There were two issues:
* The indentation for the PowerShell script task was off,
causing a parsing error
* The flighting task needed to be named so that the Aero
task would be able to reference its output variable.
Updating the release pipeline to use the newer StoreBroker v2 tasks
for automated deployment to the Store.
Must rev the version of the internals package in order to get the
latest version of the PDP files and config file.
* Added new dev app icons
* Removed VS added page include in calculator.vcsxproj.filters and increased the internal version number and the app version number
Calculator's build number in release builds follows the pattern 10.{YYMM}.{build}.0. We use the build number in lots of places, including the app binaries, the app package version, and the app bundle version. Before Calculator moved to GitHub, the app bundle version was generated using a date-based formula which produced versions like "2019.105.612.0". This means that the bundles generated from GitHub have a lower version than previous bundles. This appears to cause some issues during device reset.
This change sets the app bundle major version number to "2020" to ensure that newly-produced appxbundles have higher versions than legacy bundles. The remaining parts of the bundle version number will match the build number for easy reference.
Also updating the MakeAppx version used in bundle creation to 18362.
Fixes#462
- Add x64 and x86 UI tests to the release builds (internal builds for the store)
- UI tests now accept the target app ID as a parameter in the runsettings file
- Added the CalculatorUIFramework to handle the WinAppDriver logic.
- Added Standard Mode smoke tests and BVTs to the CalculatorUITests project.
- Removed old UI tests that did not use the CalculatorUIFramework
See also #353.
In the internal build environment, there's an auto-injected component governance task which needs to run once during the build. This task doesn't need to run during the unit test, package, and internal release jobs.
Update the localization build so that it sends strings to our internal localization system on a nightly basis and produces a patch file which we can use to check translations back into the repo.
Internally, a "component detection" task is automatically injected into builds to make sure we're not using any components with known security vulnerabilities. Because this task runs during the main app builds, it doesn't also need to run in the pipeline which hands off strings to the localization system.
* Move build jobs to the Hosted VS2017 pool instead of our internal pool
* Move the prepare-release-internalonly job from a team-specific pool to a shared pool with more capacity
* Remove symbol publishing from PR/CI builds since it's not necessary; do it only in release builds
