#### Details
1ES PT adds tags to pipeline runs using the access token provided by
ADO. In the case of pipeline runs against forked repos of a GitHub repo,
the access token does not have Edit build quality permissions and hence
cannot add tags. To unblock those pipelines, skipped tagging by using
the option SkipBuildTagsForGitHubPullRequests. This is similar change
which we did earlier for other pipelines like
https://github.com/microsoft/accessibility-insights-docs/pull/1921
Verified that the only change in the pipeline run is that it do not add
"1ES.PT.Unofficial" tag on the Run. In place of that it adds below
warning message.
##[warning]1ES PT Warning: Skipping build tags as this build is a pull
request form GitHub which does not have permissions to add tags.
##### Motivation
<!-- This can be as simple as "addresses issue #123" -->
##### Context
<!-- Are there any parts that you've intentionally left out-of-scope for
a later PR to handle? -->
<!-- Were there any alternative approaches you considered? What
tradeoffs did you consider? -->
#### Pull request checklist
<!-- If a checklist item is not applicable to this change, write "n/a"
in the checkbox -->
- [ ] Addresses an existing issue: #0000
- [ ] Ran `yarn fastpass`
- [ ] Added/updated relevant unit test(s) (and ran `yarn test`)
- [ ] Verified code coverage for the changes made. Check coverage report
at: `<rootDir>/test-results/unit/coverage`
- [ ] PR title *AND* final merge commit title both start with a semantic
tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`). See
`CONTRIBUTING.md`.
- [ ] (UI changes only) Added screenshots/GIFs to description above
- [ ] (UI changes only) Verified usability with NVDA/JAWS
#### Details
Migrated build-reliability and web-e2e-reliability to 1ES PT as per the
changes mentioned in the documentation link provided for the 1ES
pipeline migration.
##### Motivation
Pipeline migration to 1ES template. User stories - [User Story
2126535](https://dev.azure.com/mseng/1ES/_workitems/edit/2126535) and
[User Story
2126533](https://dev.azure.com/mseng/1ES/_workitems/edit/2126533)
##### Context
#### Pull request checklist
<!-- If a checklist item is not applicable to this change, write "n/a"
in the checkbox -->
- [x] Addresses an existing issue: [User Story
2126535](https://dev.azure.com/mseng/1ES/_workitems/edit/2126535) and
[User Story
2126533](https://dev.azure.com/mseng/1ES/_workitems/edit/2126533)
- [x] Ran `yarn fastpass`
- [na] Added/updated relevant unit test(s) (and ran `yarn test`)
- [na] Verified code coverage for the changes made. Check coverage
report at: `<rootDir>/test-results/unit/coverage`
- [x] PR title *AND* final merge commit title both start with a semantic
tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`). See
`CONTRIBUTING.md`.
- [na] (UI changes only) Added screenshots/GIFs to description above
- [na] (UI changes only) Verified usability with NVDA/JAWS
---------
Co-authored-by: Jeevani Chinthala <v-jeevanic@microsoft.com>
#### Details
Migrated Accessibility Insights Web CI and Accessibility Insights Web
Manual to 1ES PT as per the changes mentioned in the documentation link
provided for the 1ES pipeline migration.
We have three pipelines:
1.accessibility-insights-web CI: Non-Production tag --->
accessibility-insights
2. Accessibility Insights Web Manual: Non-Production tag --->
accessibility-insights-private
3. Accessibility Insights Web CI: Production tag --->
accessibility-insights-private
**Accessibility Insights Web CI:**
1.Added a new file build-webCI.yaml with Official template in it as this
pipeline has a production tag.
2.Created a new pipeline microsoft.accessibility-insights-web pointing
it to build-webCI.yaml for testing purpose.
3.The pipeline is successfully validated and able to run it
successfully.
https://dev.azure.com/accessibility-insights-private/Accessibility%20Insights%20(private)/_build/results?buildId=49589&view=results
**accessibility-insights-web CI:**
1.As this pipeline has Non-Production tag and it is situated in
accessibility-insights project in DevOps. This pipeline is originally
pointing to build.yaml, so made the template their Unofficial & made
other changes necessary to migrate the pipeline to 1ES.
2.Validation & run successful
https://dev.azure.com/accessibility-insights/accessibility-insights-web/_build/results?buildId=50974&view=results
**Accessibility Insights Web Manual:**
1.As this pipeline has Non-Production tag and it is situated in
accessibility-insights-private project in DevOps. This pipeline is
originally pointing to build.yaml, so made the template their Unofficial
& made other changes necessary to migrate the pipeline to 1ES.
2.Validation successful and the run is also successful. However, there
is a scenario where the pipeline fails at step linux run docker
entrypoint. After multiple re-runs it succeeds.
So here we are having bit of an issue where the pipeline sometimes runs
successfully and sometimes not. Even though the change made is exactly
similar to the other two pipelines and they are successful there.
Successful attempt:
https://dev.azure.com/accessibility-insights-private/Accessibility%20Insights%20(private)/_build/results?buildId=49538&view=results
Failed attempt:
https://dev.azure.com/accessibility-insights-private/Accessibility%20Insights%20(private)/_build/results?buildId=49583&view=results
NOTE: microsoft.accessibility-insights-web(1) was a pipeline created for
testing purpose and then it is deleted as it was no longer required.
Thus that check is failing, as this pipeline no longer exists.
##### Motivation
Pipeline migration to 1ES template. User stories -
[User Story
2126537](https://dev.azure.com/mseng/1ES/_workitems/edit/2126537) ,
[User Story
2126529](https://dev.azure.com/mseng/1ES/_workitems/edit/2126529) and
[User Story
2126531](https://dev.azure.com/mseng/1ES/_workitems/edit/2126531)
##### Context
** For Accessibility Insights Web CI:**
Once this PR change is approved, the plan is to point the existing
pipeline "Accessibility Insights Web CI" (with Production tag) to
build-webCI.yaml instead of build.yaml.
Also delete the pipeline created for testing purpose i.e.
microsoft.accessibility-insights-web
#### Pull request checklist
<!-- If a checklist item is not applicable to this change, write "n/a"
in the checkbox -->
- [x] Addresses an existing issue: [User Story
2126537](https://dev.azure.com/mseng/1ES/_workitems/edit/2126537) ,
[User Story
2126529](https://dev.azure.com/mseng/1ES/_workitems/edit/2126529) and
[User Story
2126531](https://dev.azure.com/mseng/1ES/_workitems/edit/2126531)
- [x] Ran `yarn fastpass`
- [n/a ] Added/updated relevant unit test(s) (and ran `yarn test`)
- [n/a ] Verified code coverage for the changes made. Check coverage
report at: `<rootDir>/test-results/unit/coverage`
- [x] PR title *AND* final merge commit title both start with a semantic
tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`). See
`CONTRIBUTING.md`.
- [n/a] (UI changes only) Added screenshots/GIFs to description above
- [n/a ] (UI changes only) Verified usability with NVDA/JAWS
#### Details
Migrated Pipeline Accessibility Insights Web SDT - CI to 1ES with the
help of migration tool.
Migrated Pipeline is tested successfully and checked the artifacts. It
looks good.
##### Motivation
Associated User Story : 2126528
migration of pipeline
https://dev.azure.com/accessibility-insights-private/Accessibility%20Insights%20(private)/_build/results?buildId=49447&view=results
##### Context
Raised Support post with 1ES team on how to use dynamic tsa.config in
source sdl stage. We will raise separate PR, if any better approach or
solution is provided.
<!-- Were there any alternative approaches you considered? What
tradeoffs did you consider? -->
#### Pull request checklist
<!-- If a checklist item is not applicable to this change, write "n/a"
in the checkbox -->
- [na] Addresses an existing issue: #0000
- [x] Ran `yarn fastpass`
- [na] Added/updated relevant unit test(s) (and ran `yarn test`)
- [na] Verified code coverage for the changes made. Check coverage
report at: `<rootDir>/test-results/unit/coverage`
- [x] PR title *AND* final merge commit title both start with a semantic
tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`). See
`CONTRIBUTING.md`.
- [ ] (UI changes only) Added screenshots/GIFs to description above
- [ ] (UI changes only) Verified usability with NVDA/JAWS
#### Details
Migrated publish accessibility-insights-report to npm to 1ES templates.
Tested the updated pipeline and it running as expected and have verified
the artifacts generated with old run. I failed npm published task
intentionally in test run as I do not want publish package from my
feature branch.
I also updated build-package-ui.yaml because it is also referring the
same template which is referred by build-package-report.yaml
##### Motivation
[User Story
2126539](https://dev.azure.com/mseng/1ES/_workitems/edit/2126539): [Web]
Migrate "publish accessibility-insights-report to npm" to 1ES PT
##### Context
<!-- Are there any parts that you've intentionally left out-of-scope for
a later PR to handle? -->
<!-- Were there any alternative approaches you considered? What
tradeoffs did you consider? -->
#### Pull request checklist
<!-- If a checklist item is not applicable to this change, write "n/a"
in the checkbox -->
- [na] Addresses an existing issue: #0000
- [x] Ran `yarn fastpass`
- [na ] Added/updated relevant unit test(s) (and ran `yarn test`)
- [na] Verified code coverage for the changes made. Check coverage
report at: `<rootDir>/test-results/unit/coverage`
- [x] PR title *AND* final merge commit title both start with a semantic
tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`). See
`CONTRIBUTING.md`.
- [na] (UI changes only) Added screenshots/GIFs to description above
- [na] (UI changes only) Verified usability with NVDA/JAWS
#### Details
A recent change (probably #6980) caused the reliability tests to fail
completely on Windows and Mac systems. The error was as follows:
```
╔═════════════════════════════════════════════════════════════════════════╗
║ Looks like Playwright Test or Playwright was just installed or updated. ║
║ Please run the following command to download new browsers: ║
║ ║
║ yarn playwright install ║
║ ║
║ <3 Playwright Team ║
╚═════════════════════════════════════════════════════════════════════════╝
```
This change simply adds `yarn playwright install` to the script after
building the code but before starting the e2e tests.
Validation build is at
https://dev.azure.com/accessibility-insights/accessibility-insights-web/_build/results?buildId=49229&view=results.
It's still not completely successful (we don't really expect it to be),
but it's at least running the test and no longer producing the error
about installing playwright
##### Motivation
Broken tests are bad
##### Context
<!-- Are there any parts that you've intentionally left out-of-scope for
a later PR to handle? -->
<!-- Were there any alternative approaches you considered? What
tradeoffs did you consider? -->
#### Pull request checklist
<!-- If a checklist item is not applicable to this change, write "n/a"
in the checkbox -->
- [n/a] Addresses an existing issue: #0000
- [x] Ran `yarn fastpass`
- [n/a] Added/updated relevant unit test(s) (and ran `yarn test`)
- [n/a] Verified code coverage for the changes made. Check coverage
report at: `<rootDir>/test-results/unit/coverage`
- [x] PR title *AND* final merge commit title both start with a semantic
tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`). See
`CONTRIBUTING.md`.
- [n/a] (UI changes only) Added screenshots/GIFs to description above
- [n/a] (UI changes only) Verified usability with NVDA/JAWS
#### Details
Deprecating Android support will touch hundreds of files, so we're
breaking it up into more manageable units. This PR removes the files to
build and configure mock-adb. Later PR's will remove the .NET build
tools and the code that was added to enable e2e tests to force the code
to start the session with an empty setup store.
##### Motivation
Android deprecation feature
##### Context
<!-- Are there any parts that you've intentionally left out-of-scope for
a later PR to handle? -->
<!-- Were there any alternative approaches you considered? What
tradeoffs did you consider? -->
#### Pull request checklist
<!-- If a checklist item is not applicable to this change, write "n/a"
in the checkbox -->
- [n/a] Addresses an existing issue (part of Android deprecation
feature)
- [x] Ran `yarn fastpass`
- [x] Added/updated relevant unit test(s) (and ran `yarn test`)
- [x] Verified code coverage for the changes made. Check coverage report
at: `<rootDir>/test-results/unit/coverage`
- [x] PR title *AND* final merge commit title both start with a semantic
tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`). See
`CONTRIBUTING.md`.
- [n/a] (UI changes only) Added screenshots/GIFs to description above
- [n/a] (UI changes only) Verified usability with NVDA/JAWS
#### Details
Deprecating Android support will touch hundreds of files, so we're
breaking it up into more manageable units. This PR removes the files
associated with running the Unified pipelines (which have already been
disabled), as well as one test that only ran in the pipeline context.
##### Motivation
Android deprecation feature
##### Context
<!-- Are there any parts that you've intentionally left out-of-scope for
a later PR to handle? -->
<!-- Were there any alternative approaches you considered? What
tradeoffs did you consider? -->
#### Pull request checklist
<!-- If a checklist item is not applicable to this change, write "n/a"
in the checkbox -->
- [n/a] Addresses an existing issue (part of Android deprecation
feature)
- [x] Ran `yarn fastpass`
- [x] Added/updated relevant unit test(s) (and ran `yarn test`)
- [x] Verified code coverage for the changes made. Check coverage report
at: `<rootDir>/test-results/unit/coverage`
- [x] PR title *AND* final merge commit title both start with a semantic
tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`). See
`CONTRIBUTING.md`.
- [n/a] (UI changes only) Added screenshots/GIFs to description above
- [n/a] (UI changes only) Verified usability with NVDA/JAWS
#### Details
Migrates the repo's package manager from yarn v1 to yarn v3 (in
non-zero-installs configuration)
Some of this was mechanical based on [Yarn's migration
guide](https://yarnpkg.com/getting-started/migration). Beyond the steps
there, this PR:
* Updates assorted CI pipelines/workflows and dev docs to adapt to minor
syntax updates
* Updates CI workflow's caching strategy to use
`actions/setup-node@v3`'s built-in support for yarn berry friendly
caching instead of implementing our own with `actions/cache@v3`
* Updates license-check-and-add and prettier configs to exclude `.yarn/`
* Updates e2e `Dockerfile` to account for new changes
* Drops Lerna dependency in favor of plain Yarn workspaces, similar to
service and action
##### Motivation
* Simplifies some common dev commands. In particular, the command to
update report package snapshots changes from `yarn test:report:e2e -- --
-- -u` to just `yarn test:report:e2e -u`
* Consistency with other repos
* Allows for versioned resolutions (similar to
https://github.com/microsoft/accessibility-insights-action/pull/1596) -
I left modifying existing resolutions out of scope since this PR was
already pretty large without them, will cover them in a different PR
* Removes a dependency (Lerna)
##### Context
Similar PRs in other repos:
* https://github.com/microsoft/accessibility-insights-service/pull/2210
* https://github.com/microsoft/accessibility-insights-action/pull/1559
* https://github.com/microsoft/accessibility-insights-action/pull/1596
* https://github.com/microsoft/axe-sarif-converter/pull/935
* https://github.com/microsoft/accessibility-insights-docs/pull/1577
#### Pull request checklist
<!-- If a checklist item is not applicable to this change, write "n/a"
in the checkbox -->
- [n/a] Addresses an existing issue: #0000
- [x] Ran `yarn fastpass`
- [n/a] Added/updated relevant unit test(s) (and ran `yarn test`)
- [n/a] Verified code coverage for the changes made. Check coverage
report at: `<rootDir>/test-results/unit/coverage`
- [x] PR title *AND* final merge commit title both start with a semantic
tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`). See
`CONTRIBUTING.md`.
- [n/a] (UI changes only) Added screenshots/GIFs to description above
- [n/a] (UI changes only) Verified usability with NVDA/JAWS
#### Details
Increases the web e2e test timeout from 15 minutes to 20 minutes.
##### Motivation
Tests were often timing out resulting in errors.
##### Context
Note: this doesn't fix the flakiness of our tests but does seem to
reduce a lot (over 50%) of the failures we're seeing recently. After
running 6 web-e2e-reliability runs (9 were run but there were 3 that
were affected by an unrelated issue) there was a marked improvement in
number of failures (and none due to timing out the task). I saw 12/90
(15 test tasks in each run) failed tasks vs. 27/90 compared to the last
6 runs in main.
#### Pull request checklist
<!-- If a checklist item is not applicable to this change, write "n/a"
in the checkbox -->
- [ ] Addresses an existing issue: #0000
- [ ] Ran `yarn fastpass`
- [ ] Added/updated relevant unit test(s) (and ran `yarn test`)
- [ ] Verified code coverage for the changes made. Check coverage report
at: `<rootDir>/test-results/unit/coverage`
- [ ] PR title *AND* final merge commit title both start with a semantic
tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`). See
`CONTRIBUTING.md`.
- [ ] (UI changes only) Added screenshots/GIFs to description above
- [ ] (UI changes only) Verified usability with NVDA/JAWS
#### Details
This PR implements a workaround for an issue currently impacting the
NOTICE generation task we use in release builds where it's missing some
components that we depend on with the following warning:
```
##[warning]Components missing from notice, add manually (4):
See: https://docs.opensource.microsoft.com/content/using/required-notice-template.html
Not harvested in ClearlyDefined (4):
npm/npmjs/-/appium-adb/9.10.23
npm/npmjs/@appium/types/0.8.3
npm/npmjs/@appium/support/3.1.3
npm/npmjs/@appium/tsconfig/0.2.3
```
To work around this, this PR checks in a manually updated version of
`NOTICE.html` at `/src/NOTICE.html` and disables the build tasks that
would normally overwrite that with a generated file in release builds.
To generate the manually updated file, I started from the generated
version of the file and added entries for the four missing packages at
the end of the big list in the HTML file, matching the formatting of the
other generated entries and using data from the respective packages'
`package.json` and `LICENSE` files.
##### Motivation
Unblock release of web@2.37.2
##### Context
This is a quick workaround to unblock the release. We'll want to follow
up with a separate PR that reverts this one and replaces it with some
mechanism for either "making that NOTICE generation warning a build
break" and/or "automating a script to do these manual additions"
#### Pull request checklist
<!-- If a checklist item is not applicable to this change, write "n/a"
in the checkbox -->
- [n/a] Addresses an existing issue: #0000
- [x] Ran `yarn fastpass`
- [n/a] Added/updated relevant unit test(s) (and ran `yarn test`)
- [n/a] Verified code coverage for the changes made. Check coverage
report at: `<rootDir>/test-results/unit/coverage`
- [x] PR title *AND* final merge commit title both start with a semantic
tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`). See
`CONTRIBUTING.md`.
- [n/a] (UI changes only) Added screenshots/GIFs to description above
- [n/a] (UI changes only) Verified usability with NVDA/JAWS
#### Details
Fixing the wrong Electron build id was making the Canary Unified
pipeline fail.
##### Motivation
Fix Canary Unified Pipeline runs.
##### Context
Error introduced in #6243, failed pipeline example:
https://dev.azure.com/accessibility-insights-private/Accessibility%20Insights%20(private)/_build/results?buildId=40498&view=results
#### Pull request checklist
<!-- If a checklist item is not applicable to this change, write "n/a"
in the checkbox -->
- [ ] Addresses an existing issue: #0000
- [ ] Ran `yarn null:autoadd`
- [x] Ran `yarn fastpass`
- [x] Added/updated relevant unit test(s) (and ran `yarn test`)
- [ ] Verified code coverage for the changes made. Check coverage report
at: `<rootDir>/test-results/unit/coverage`
- [x] PR title *AND* final merge commit title both start with a semantic
tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`). See
`CONTRIBUTING.md`.
- [n/a] (UI changes only) Added screenshots/GIFs to description above
- [n/a] (UI changes only) Verified usability with NVDA/JAWS
Co-authored-by: Tania Martinez Villagomez <taniamar@microsoft.com>
#### Details
Upgrade electron to version +22
##### Motivation
Only the three most recent major versions of Electron are supported. We
are currently on 19.1.3and the latest version is 22.0.0 so we need to
update.
#### Pull request checklist
<!-- If a checklist item is not applicable to this change, write "n/a"
in the checkbox -->
- [n/a] Addresses an existing issue: #0000
- [x] Ran `yarn null:autoadd`
- [x] Ran `yarn fastpass`
- [n/a] Added/updated relevant unit test(s) (and ran `yarn test`)
- [ ] Verified code coverage for the changes made. Check coverage report
at: `<rootDir>/test-results/unit/coverage`
- [x] PR title *AND* final merge commit title both start with a semantic
tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`). See
`CONTRIBUTING.md`.
- [n/a] (UI changes only) Added screenshots/GIFs to description above
- [n/a] (UI changes only) Verified usability with NVDA/JAWS
Co-authored-by: Tania Martinez Villagomez <taniamar@microsoft.com>
#### Details
This PR **removes all Manifest v2 support** from web's
build/test/release steps - after this PR, the web product will always
build for manifest v3 by default, without using mv3-specific build
targets.
After this PR:
* `yarn build`, `yarn build:production`, `yarn test:e2e`, etc will use
mv3
* `yarn build:web:mv3`, `yarn test:e2e:mv3`, etc are removed
* mv3-specific CI steps are removed
* the default CI steps for build/e2e tests/etc use MV3 by default
* `background.html`, `background-init.ts`, and the esbuild/webpack steps
to build `background.bundle.js` are all removed
* Grunt steps and e2e setup that previously handled mv2 vs mv3
differences are simplified to assume mv3-only (in particular, a lot of
dynamic manifest generation has been moved out of grunt and into static
`manifest.json` content)
* assessment schema validation previously used a dynamic validation
function in mv2 and a static validation function in mv3; it now always
uses a static validation function
* renamed `docs/mv3-architecture.md` to just `docs/architecture.md`
##### Motivation
Completes our MV3 release
##### Context
* This PR drops support for the "InsiderMV3" channel, but we will still
be doing one final release to that channel. We'll handle that by
manually kicking off a release based on [a separate branch that no-ops
that
channel](https://github.com/microsoft/accessibility-insights-web/compare/main...sfoslund:accessibility-insights-web:Mv3EOLExt?expand=1)
* The `LoadAssessmentDataSchemaProvider` is no longer referenced except
via the assessment validator package; it'd be better to move it out to
`/packages/validator`, but this PR is already overlarge and that would
require more changes than I wanted to include
* As part of this PR, I audited a diff of `background-init.ts` and
`service-worker-init.ts` - I didn't find any additional components to
remove as part of that exercise
#### Special merge instructions
* Reminder to notify the team when merging this
#### Pull request checklist
<!-- If a checklist item is not applicable to this change, write "n/a"
in the checkbox -->
- [x] Addresses an existing issue: 2004997, 2004998
- [x] Ran `yarn null:autoadd`
- [x] Ran `yarn fastpass`
- [x] Added/updated relevant unit test(s) (and ran `yarn test`)
- [x] Verified code coverage for the changes made. Check coverage report
at: `<rootDir>/test-results/unit/coverage`
- [x] PR title *AND* final merge commit title both start with a semantic
tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`). See
`CONTRIBUTING.md`.
- [n/a] (UI changes only) Added screenshots/GIFs to description above
- [n/a] (UI changes only) Verified usability with NVDA/JAWS
#### Details
Bump electron version from 19.0.7 to 19.1.3.
Unified unsigned release pipeline test run:
https://dev.azure.com/accessibility-insights-private/Accessibility%20Insights%20(private)/_build/results?buildId=39898&view=results
##### Motivation
Security alert
#### Pull request checklist
<!-- If a checklist item is not applicable to this change, write "n/a"
in the checkbox -->
- [n/a] Addresses an existing issue: #0000
- [x] Ran `yarn null:autoadd`
- [x] Ran `yarn fastpass`
- [x] Added/updated relevant unit test(s) (and ran `yarn test`)
- [x] Verified code coverage for the changes made. Check coverage report
at: `<rootDir>/test-results/unit/coverage`
- [x] PR title *AND* final merge commit title both start with a semantic
tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`). See
`CONTRIBUTING.md`.
- [n/a] (UI changes only) Added screenshots/GIFs to description above
- [n/a] (UI changes only) Verified usability with NVDA/JAWS
#### Details
This PR updates each task in our `install-node-prerequisites.yml`
pipeline fragment to retry up to twice each, using the
recently-introduced
[`retryCountOnTaskFailure`](https://learn.microsoft.com/en-us/azure/devops/release-notes/2021/pipelines/sprint-195-update)
pipelines syntax. Failures in these tasks are overwhelmingly the result
of network connectivity flakiness, so this should help with a few
occasional failures that we see across all builds (eg, the failure in
this morning's unified "unsigned stage 1" pipeline)
##### Motivation
Avoid noise from flaky failures outside of our control that we'd
"resolve" by retrying anyway
##### Context
n/a
#### Pull request checklist
<!-- If a checklist item is not applicable to this change, write "n/a"
in the checkbox -->
- [n/a] Addresses an existing issue: #0000
- [n/a] Ran `yarn null:autoadd`
- [n/a] Ran `yarn fastpass`
- [n/a] Added/updated relevant unit test(s) (and ran `yarn test`)
- [n/a] Verified code coverage for the changes made. Check coverage
report at: `<rootDir>/test-results/unit/coverage`
- [x] PR title *AND* final merge commit title both start with a semantic
tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`). See
`CONTRIBUTING.md`.
- [n/a] (UI changes only) Added screenshots/GIFs to description above
- [n/a] (UI changes only) Verified usability with NVDA/JAWS
#### Details
Now that we have e2e tests running on the mv3 extension and passing
locally, adding those tests to CI runs.
##### Motivation
Feature work
##### Context
As we have only run mv3 e2e tests locally so far, we are not sure how
reliable they will be initially. We won't merge here until they are
reasonably reliable but even still it will probably be fair to merge
around any mv3 e2e CI failures for now.
#### Pull request checklist
<!-- If a checklist item is not applicable to this change, write "n/a"
in the checkbox -->
- [n/a] Addresses an existing issue: #0000
- [x] Ran `yarn null:autoadd`
- [x] Ran `yarn fastpass`
- [n/a] Added/updated relevant unit test(s) (and ran `yarn test`)
- [n/a] Verified code coverage for the changes made. Check coverage
report at: `<rootDir>/test-results/unit/coverage`
- [x] PR title *AND* final merge commit title both start with a semantic
tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`). See
`CONTRIBUTING.md`.
- [n/a] (UI changes only) Added screenshots/GIFs to description above
- [n/a] (UI changes only) Verified usability with NVDA/JAWS
#### Details
This PR migrates `mock-adb` from being a Node.js script packaged into an exe using `pkg` to being a .NET 6.0 console application built as a standalone exe.
##### Motivation
The main motivation is to improve the reliability of the unified tests by improving mock-adb performance. The .NET version is more than an order of magnitude faster than the Node.js version due to the high startup time involved to initialize the Node.js runtime, before our code starts running, and mock-adb is invoked tens of times per test for all unified tests of scenarios beyond the "device setup" flow.
##### Context
For internal folks, see the recording of our 7/7/22 engineering discussion for more context and team discussion. We considered and rejected a few other approaches, including:
* Rewrite in Rust/Go instead of .NET
* Move to a different repo as part of the rewrite
* Instead of rewriting, rearchitect some of the unified tests to avoid having to shell out to a separate `adb.exe` process so much
#### Pull request checklist
<!-- If a checklist item is not applicable to this change, write "n/a" in the checkbox -->
- [n/a] Addresses an existing issue: #0000
- [x] Ran `yarn fastpass`
- [no] Added/updated relevant unit test(s) (and ran `yarn test`)
- [x] Verified code coverage for the changes made. Check coverage report at: `<rootDir>/test-results/unit/coverage`
- [x] PR title *AND* final merge commit title both start with a semantic tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`). See `CONTRIBUTING.md`.
- [n/a] (UI changes only) Added screenshots/GIFs to description above
- [n/a] (UI changes only) Verified usability with NVDA/JAWS
* upgrade to electron 18.3.3 and update codec snapshot
* upgrade to 18.3.5 and update buildid
* update electron to 19.0.7
Co-authored-by: madalynrose <madparker@microsoft.com>
* updated snapshots
* update gruntfile to use esbuild for report package
* update build template
* update how scoped css anmes are generated to be deterministic + minor style changes in esbuild
* updated snapshots with names from deterministic generator
* lint fix + var to const change
* remove unnecessary hashPrefix line
* normalize path slashes
* replace to replaceAll
* feat(esbuild): use esbuild to build web extension
* undo typings change due to bad merge
* undo unnecessary changes to naming of details-view
* update build and add script options for type-checking
* update github ci build to type-check
* update timeout for type-checking to 3 minutes
* update when type-checking is run
* use type-checked build in ci
* change ordering for type-check
* devM3 renamed to dev-mv3
* adding type-check to fastpass
* update to use devDependencies instead
* use extension name function for css module/style paths
* updated to use json stringify for args.path in plugin
* rename type-check to type:check
* use console.error in esbuild when catching an error
* do not minify identifiers when bundling details view
* add stylesheet-init content to client-init
* added comment in building-web.md regarding tbuild
* use compile instead of renderSync + comment
* use dynamic imports for client-init that only import when we have not previously initialized the target page
* added a way to use react-devtools like webpack
* remove stylesheet-init since it's no longer required
* fix issue with react-devtools build
* add comment adding references for style plugin
* remove references to stylesheet-init
* embed styles in map files as well
* update report package e2e tests (new line characters) as a result of embedded style change
* smaller paths for css-modules in style plugin
* use iife for extension format; fixes axe minification issue
* errors exit appropriately and specifically mention map files in embed styles
* fix lint issue
#### Details
This PR bumps our default/recommended build environment to Node 16.
There aren't any real breaking changes affecting us here, except that our unit tests appear to be much slower (timing out after 10m instead of taking 6-7m in Node 14). We could work around this by just sharding the unit tests like we do for e2e tests already, but it's not ideal; besides "still being slower for local development", it also breaks code coverage reporting (unless we add some new job to merge the results before publishing coverage).
The most relevant looking Jest/Node/V8 issues seem to be covered in the discussion of https://github.com/facebook/jest/issues/11956 - it would be good to experiment with some of the options on that thread to see if we can get the unit test time back down without needing to shard them. Some options to explore:
* Test Node 16.10.0 vs 16.11.0 (we wouldn't want to pin to 16.10.0, but it would be good to try it out to verify that the slowness really is caused by the V8 update in question on that issue)
* Try out the assorted node/v8 command line argument combinations suggested by that thread
Alternatively, we could explore more generic ways of making the tests faster; I think https://github.com/nicolo-ribaudo/jest-light-runner would be promising to look into.
##### Motivation
Keep dependencies up to date; 16 has been an LTS release for several months now.
Also, `accessibility-insights-service` updated to Node 16 yesterday, and we want to ensure that the packages we publish for it to consume are tested in the same environment.
##### Context
n/a
#### Pull request checklist
<!-- If a checklist item is not applicable to this change, write "n/a" in the checkbox -->
- [n/a] Addresses an existing issue: #0000
- [x] Ran `yarn fastpass`
- [ ] Added/updated relevant unit test(s) (and ran `yarn test`)
- [n/a] Verified code coverage for the changes made. Check coverage report at: `<rootDir>/test-results/unit/coverage`
- [x] PR title *AND* final merge commit title both start with a semantic tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`). See `CONTRIBUTING.md`.
- [n/a] (UI changes only) Added screenshots/GIFs to description above
- [n/a] (UI changes only) Verified usability with NVDA/JAWS
Signs and then sends our unified bits to ESRP for notarization. Also includes changes that may potentially resolve auto-update issues on Mac (produce both dmg + zip for electron-builder).
#### Details
This PR bumps the version of Node we use in CI builds on both GitHub Actions and Azure DevOps to the latest v14 (`14.19.0`).
This is primarily in the hopes of resolving an issue we've seen in a few recent PR builds for dependabot PRs where builds fail in webpack with an error that looks like this:
```
Running "concurrent:webpack-all" (concurrent) task
Running "exec:webpack-prod" (exec) task
>> internal/child_process/serialization.js:70
>> yield deserializer.readValue();
>> ^
>>
>> Error: Unable to deserialize cloned data.
>> at parseChannelMessages (internal/child_process/serialization.js:70:26)
>> at parseChannelMessages.next (<anonymous>)
>> at Pipe.channel.onread (internal/child_process.js:599:18)
>> Exited with code: 1.
>> Error executing child process: Error: Process exited with code 1.
```
This symptom is similar to the one resolved by https://github.com/nodejs/node/pull/38728, which is included in 14.17.4
##### Motivation
* Keep deps up to date
* Attempt to avoid an error blocking PR builds (#5134, #5135, #5136)
##### Context
n/a
#### Pull request checklist
<!-- If a checklist item is not applicable to this change, write "n/a" in the checkbox -->
- [n/a] Addresses an existing issue: #0000
- [x] Ran `yarn fastpass`
- [n/a] Added/updated relevant unit test(s) (and ran `yarn test`)
- [n/a] Verified code coverage for the changes made. Check coverage report at: `<rootDir>/test-results/unit/coverage`
- [x] PR title *AND* final merge commit title both start with a semantic tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`). See `CONTRIBUTING.md`.
- [n/a] (UI changes only) Added screenshots/GIFs to description above
- [n/a] (UI changes only) Verified usability with NVDA/JAWS
Details
This PR undoes the linux signing change from #4167 with slight organizational changes.
Motivation
We found some issues with the ClearSign signed AppImage in release validation. This unblocks release.
Context
Further investigation is required to determine if we can use ClearSign signing in the future.
I verified an AppImage from the signed build locally.
Details
A previous PR (#4160) removed the use of sign-release-package.yaml. Now that the build process has settled, this PR brings it back with a few fewer steps. This time, the Linux signed build uses sign-release-package.yaml, too!
Motivation
Consolidate redundant build steps into a template.
Details
Now that we are signing all Windows files, we are ready to run the Codesign Validation task on them.
Motivation
Validates that our EXEs and DLLs are signed.
Details
The unified pack command in the unsigned build currently has a condition to not run on Windows. The condition should have included succeeded(), as well. This PR corrects that.
Motivation
If a previous build step fails, pack:unified:all shouldn't run.
Details
Currently, our unsigned release build builds the unified product, packs it into installers, and publishes those as artifacts. The signed build then picks up those installer artifacts and signs them. This PR relocates the packing step for Windows only to the signed build. Now, the unsigned build builds the unified product and publishes the unpacked builds as artifacts for Windows. The signed build picks up those packed and unpacked artifacts, packs the Windows artifacts into installers, and signs them. There is no net effect on the unsigned + signed build combination.
Motivation
We currently only sign the packed installers. Now that we want to sign the contents of those installers for Windows, we will need to sign the unpacked builds, pack them, and then sign the packed installers.
Context
This PR follows up #4138. The next PR will actually add signing of the unpacked files, which will occur between the artifact download task and the packing task in the signed build.
A previous PR, #4143, would have moved all platforms' packing to the signed build. Since then, we have determined that only Windows will need to be signed in unpacked form.
Details
Currently, our build-unified-<channel> grunt commands build the unified product and then run electron-builder to create packed installers. This PR creates a new pack-unified-<channel> grunt command and shifts responsibility as follows:
build-unified-<channel> builds the unified product and runs electron-builder to prepare the unpacked files in the drop folder
pack-unified-<channel> runs electron-builder to pack the unpacked files from the drop folder into installers
With this PR, running build-unified-<channel> and then pack-unified-<channel> is equivalent to running the previous build-unified-<channel> command. As such, there is no net impact on our unsigned build pipeline.
Motivation
We currently only sign the packed installers. Now that we want to sign the contents of those installers, we need the ability to create the installers without running a fresh build and remaking their contents.
Context
A follow up PR will leverage this PR and update our unsigned and signed build pipelines to sign the desired files.
I considered leaving the grunt task as-is and instead signing the electron files directly (in node_modules). This would not work because electron-builder tweaks the electron executable, which would break its signature.
Vikash Yadav
Chirag Sharma
Prachi Naigaonkar
Dave Tryon
Dan Bjorge
Wahaj
ThanyaLeif
Sarah Oslund
Dan Bjorge
Madalyn
SB
Karan
John Alkire
Rob Gallo