microsoft
/
accessibility-insights-action
зеркало из https://github.com/microsoft/accessibility-insights-action.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
accessibility-insights-action/license-check-and-add-confi...

41 строка
931 B
JSON
Исходник Обычный вид История

adding copyright check, linting, prettier & build support (#1) * adding copyright check, linting, prettier & build support * adding support to run jest tests; adding watch support
2020-02-13 04:52:40 +03:00
{
chore: Adding codeowners, pull request template & update readme (#4) * adding code owners & pull request template * updating readme * adding copyright header * fix code formatting
2020-02-19 22:38:02 +03:00
"ignore": [
feat: stop ADO extension reliance on pipeline-installed Node and Yarn versions (by migrating to yarn v3) (#1559) #### Details *Leaving this as a draft pending feedback on design + testing as-deployed in a test extension* This PR migrates the repo to yarn v3, both for development of the extension and also for our customers. Notable impacts of this are: * A copy of yarn 3 is now checked into the repo * The same copy of yarn 3 is now bundled with the ADO extension and invoked directly. This means that users will no longer need to include any explicit `npm install -g yarn` step, and it insulates us from issues due to from differences in yarn versions based on customer environment. * Because of this above, it is easier to invoke our bundled yarn using the same node binary that our script runs within (the node 16 version guaranteed to exist on the agent regardless of user pipeline tasks). This means that users will no longer need to include any explicit `NodeTools@0` step, and it insulates us from issues due to differences in Node versions based on customer environment (I suspect this should fix #1551). * This has the very significant downside of relying on the agent node version to be recent enough to support our task. That's true today, but we've had issues with that in the past - agents didn't add node16 support for tasks until well after we were having trouble with the previously-supported version being EOL and unsupported by many of our dependencies * We get to drop our `lerna` dependency in favor of the yarn workspaces plugin, which substantially reduces our overall dependency tree size * Pre-empts the possibility of package-squatting attacks against workspace-internal packages ##### Motivation * Removes a few steps from onboarding * Prevents several classes of errors we've seen customers hit recently * Enables more precise yarn resolutions * Pre-empts package-squatting attacks ##### Context Reviewer note: Most of the individual changes are more or less mechanical and not super interesting. However, **these three files are substantive changes to the way the extension functions and need deeper review**: * `packages/ado-extension/prepare-package-dir.js` * `packages/ado-extension/src/install-runtime-dependencies.ts` * `packages/shared/build-runtime-package-metadata.js` Some reference material I used while putting together this PR: * [Service repo's yarn v3 migration PR for reference](https://github.com/microsoft/accessibility-insights-service/pull/2210) * [Yarn's v1 -> v2+ migration guide that I followed for the first few commits](https://yarnpkg.com/getting-started/migration) #### Pull request checklist <!-- If a checklist item is not applicable to this change, write "n/a" in the checkbox --> - [x] Addresses an existing issue: Fixes #1109 and maybe also #1551 - [n/a] Added relevant unit test for your changes. (`yarn test`) - [n/a] Verified code coverage for the changes made. Check coverage report at: `<rootDir>/test-results/unit/coverage` - [x] Ran precheckin (`yarn precheckin`)
2023-03-01 17:18:21 +03:00
".dependabot",
chore: Adding codeowners, pull request template & update readme (#4) * adding code owners & pull request template * updating readme * adding copyright header * fix code formatting
2020-02-19 22:38:02 +03:00
".git",
Chore: Add issue templates to the Action repo (#1020) * Chore: Add issue templates to the Action repo In particular, dependabot requires these labels and we also use the labels to sort and triage bugs. * Update copyright check config to ignore the .github directory.
2022-01-27 02:45:52 +03:00
".github",
feat: stop ADO extension reliance on pipeline-installed Node and Yarn versions (by migrating to yarn v3) (#1559) #### Details *Leaving this as a draft pending feedback on design + testing as-deployed in a test extension* This PR migrates the repo to yarn v3, both for development of the extension and also for our customers. Notable impacts of this are: * A copy of yarn 3 is now checked into the repo * The same copy of yarn 3 is now bundled with the ADO extension and invoked directly. This means that users will no longer need to include any explicit `npm install -g yarn` step, and it insulates us from issues due to from differences in yarn versions based on customer environment. * Because of this above, it is easier to invoke our bundled yarn using the same node binary that our script runs within (the node 16 version guaranteed to exist on the agent regardless of user pipeline tasks). This means that users will no longer need to include any explicit `NodeTools@0` step, and it insulates us from issues due to differences in Node versions based on customer environment (I suspect this should fix #1551). * This has the very significant downside of relying on the agent node version to be recent enough to support our task. That's true today, but we've had issues with that in the past - agents didn't add node16 support for tasks until well after we were having trouble with the previously-supported version being EOL and unsupported by many of our dependencies * We get to drop our `lerna` dependency in favor of the yarn workspaces plugin, which substantially reduces our overall dependency tree size * Pre-empts the possibility of package-squatting attacks against workspace-internal packages ##### Motivation * Removes a few steps from onboarding * Prevents several classes of errors we've seen customers hit recently * Enables more precise yarn resolutions * Pre-empts package-squatting attacks ##### Context Reviewer note: Most of the individual changes are more or less mechanical and not super interesting. However, **these three files are substantive changes to the way the extension functions and need deeper review**: * `packages/ado-extension/prepare-package-dir.js` * `packages/ado-extension/src/install-runtime-dependencies.ts` * `packages/shared/build-runtime-package-metadata.js` Some reference material I used while putting together this PR: * [Service repo's yarn v3 migration PR for reference](https://github.com/microsoft/accessibility-insights-service/pull/2210) * [Yarn's v1 -> v2+ migration guide that I followed for the first few commits](https://yarnpkg.com/getting-started/migration) #### Pull request checklist <!-- If a checklist item is not applicable to this change, write "n/a" in the checkbox --> - [x] Addresses an existing issue: Fixes #1109 and maybe also #1551 - [n/a] Added relevant unit test for your changes. (`yarn test`) - [n/a] Verified code coverage for the changes made. Check coverage report at: `<rootDir>/test-results/unit/coverage` - [x] Ran precheckin (`yarn precheckin`)
2023-03-01 17:18:21 +03:00
".yarn",
"**/.DS_Store",
chore: Adding codeowners, pull request template & update readme (#4) * adding code owners & pull request template * updating readme * adding copyright header * fix code formatting
2020-02-19 22:38:02 +03:00
"**/.gitattributes",
feat(pr-baseline-2): add a pipeline for ADO staging validation scenarios (#947) #### Details This PR adds partial automation for the e2e release validation scenarios for the ADO extension. Once this is merged, the intention is to update the `Verify ADO extension works when codebase is in GitHub` release validation scenario to read something like this: ``` ## ADO extension CI scenarios with GitHub repo - [ ] Find the `ado-extension-github-repo-staging-validation` CI build corresponding to this staging release from [the list of builds](https://example.com/link/to/definition). Paste a link to it here: <INSERT LINK> - For each of the test cases run by the build, verify that it succeeds or fails appropriately, that it produces a reasonable-looking report in its corresponding build artifact, that task log output looks reasonable, and that it produces the expected updated baseline file (if applicable). - [ ] [should succeed] case 1: siteDir, no baseline - [ ] [should succeed] case 2: url, no baseline - [ ] [should succeed] case 3: up-to-date baseline - [ ] [should fail] case 4: baseline missing failures - [ ] [should fail] case 5: baseline with resolved failures - [ ] [should fail] case 6: new baseline file - [ ] [should fail] case 7: failOnAccessibilityError ## ADO extension PR scenarios with GitHub repo - [ ] Create a new draft PR in the `microsoft/accessibility-insights-action` repo which makes a no-op change to `/dev/README.md` - [ ] This should trigger an `ado-extension-github-repo-staging-validation` PR build. Paste a link to the PR build here: <INSERT LINK> - For each of the test cases run by the build, verify that it succeeds or fails appropriately, that it produces a reasonable-looking report in its corresponding build artifact, that task log output looks reasonable, and that it produces the expected updated baseline file (if applicable). - [ ] [should succeed] case 1: siteDir, no baseline - [ ] [should succeed] case 2: url, no baseline - [ ] [should succeed] case 3: up-to-date baseline - [ ] [should fail] case 4: baseline missing failures - [ ] [should fail] case 5: baseline with resolved failures - [ ] [should fail] case 6: new baseline file - [ ] [should fail] case 7: failOnAccessibilityError ``` ##### Motivation Make ADO release process more automated ##### 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: Fixes #0000 - [n/a] Added relevant unit test for your changes. (`yarn test`) - [n/a] Verified code coverage for the changes made. Check coverage report at: `<rootDir>/test-results/unit/coverage` - [x] Ran precheckin (`yarn precheckin`) - [x] (after PR created) The `Accessibility Checks (pull_request)` check should fail. All other checks should pass.
2021-11-22 22:55:45 +03:00
"**/*.baseline",
fix: escape special characters in markdown (#729)
2021-07-21 19:19:34 +03:00
"**/*.snap.md",
feat: stop ADO extension reliance on pipeline-installed Node and Yarn versions (by migrating to yarn v3) (#1559) #### Details *Leaving this as a draft pending feedback on design + testing as-deployed in a test extension* This PR migrates the repo to yarn v3, both for development of the extension and also for our customers. Notable impacts of this are: * A copy of yarn 3 is now checked into the repo * The same copy of yarn 3 is now bundled with the ADO extension and invoked directly. This means that users will no longer need to include any explicit `npm install -g yarn` step, and it insulates us from issues due to from differences in yarn versions based on customer environment. * Because of this above, it is easier to invoke our bundled yarn using the same node binary that our script runs within (the node 16 version guaranteed to exist on the agent regardless of user pipeline tasks). This means that users will no longer need to include any explicit `NodeTools@0` step, and it insulates us from issues due to differences in Node versions based on customer environment (I suspect this should fix #1551). * This has the very significant downside of relying on the agent node version to be recent enough to support our task. That's true today, but we've had issues with that in the past - agents didn't add node16 support for tasks until well after we were having trouble with the previously-supported version being EOL and unsupported by many of our dependencies * We get to drop our `lerna` dependency in favor of the yarn workspaces plugin, which substantially reduces our overall dependency tree size * Pre-empts the possibility of package-squatting attacks against workspace-internal packages ##### Motivation * Removes a few steps from onboarding * Prevents several classes of errors we've seen customers hit recently * Enables more precise yarn resolutions * Pre-empts package-squatting attacks ##### Context Reviewer note: Most of the individual changes are more or less mechanical and not super interesting. However, **these three files are substantive changes to the way the extension functions and need deeper review**: * `packages/ado-extension/prepare-package-dir.js` * `packages/ado-extension/src/install-runtime-dependencies.ts` * `packages/shared/build-runtime-package-metadata.js` Some reference material I used while putting together this PR: * [Service repo's yarn v3 migration PR for reference](https://github.com/microsoft/accessibility-insights-service/pull/2210) * [Yarn's v1 -> v2+ migration guide that I followed for the first few commits](https://yarnpkg.com/getting-started/migration) #### Pull request checklist <!-- If a checklist item is not applicable to this change, write "n/a" in the checkbox --> - [x] Addresses an existing issue: Fixes #1109 and maybe also #1551 - [n/a] Added relevant unit test for your changes. (`yarn test`) - [n/a] Verified code coverage for the changes made. Check coverage report at: `<rootDir>/test-results/unit/coverage` - [x] Ran precheckin (`yarn precheckin`)
2023-03-01 17:18:21 +03:00
"**/*.snap",
chore: small tweaks to the e2e test (#782)
2021-08-17 00:00:08 +03:00
"**/*.taskkey",
feat: stop ADO extension reliance on pipeline-installed Node and Yarn versions (by migrating to yarn v3) (#1559) #### Details *Leaving this as a draft pending feedback on design + testing as-deployed in a test extension* This PR migrates the repo to yarn v3, both for development of the extension and also for our customers. Notable impacts of this are: * A copy of yarn 3 is now checked into the repo * The same copy of yarn 3 is now bundled with the ADO extension and invoked directly. This means that users will no longer need to include any explicit `npm install -g yarn` step, and it insulates us from issues due to from differences in yarn versions based on customer environment. * Because of this above, it is easier to invoke our bundled yarn using the same node binary that our script runs within (the node 16 version guaranteed to exist on the agent regardless of user pipeline tasks). This means that users will no longer need to include any explicit `NodeTools@0` step, and it insulates us from issues due to differences in Node versions based on customer environment (I suspect this should fix #1551). * This has the very significant downside of relying on the agent node version to be recent enough to support our task. That's true today, but we've had issues with that in the past - agents didn't add node16 support for tasks until well after we were having trouble with the previously-supported version being EOL and unsupported by many of our dependencies * We get to drop our `lerna` dependency in favor of the yarn workspaces plugin, which substantially reduces our overall dependency tree size * Pre-empts the possibility of package-squatting attacks against workspace-internal packages ##### Motivation * Removes a few steps from onboarding * Prevents several classes of errors we've seen customers hit recently * Enables more precise yarn resolutions * Pre-empts package-squatting attacks ##### Context Reviewer note: Most of the individual changes are more or less mechanical and not super interesting. However, **these three files are substantive changes to the way the extension functions and need deeper review**: * `packages/ado-extension/prepare-package-dir.js` * `packages/ado-extension/src/install-runtime-dependencies.ts` * `packages/shared/build-runtime-package-metadata.js` Some reference material I used while putting together this PR: * [Service repo's yarn v3 migration PR for reference](https://github.com/microsoft/accessibility-insights-service/pull/2210) * [Yarn's v1 -> v2+ migration guide that I followed for the first few commits](https://yarnpkg.com/getting-started/migration) #### Pull request checklist <!-- If a checklist item is not applicable to this change, write "n/a" in the checkbox --> - [x] Addresses an existing issue: Fixes #1109 and maybe also #1551 - [n/a] Added relevant unit test for your changes. (`yarn test`) - [n/a] Verified code coverage for the changes made. Check coverage report at: `<rootDir>/test-results/unit/coverage` - [x] Ran precheckin (`yarn precheckin`)
2023-03-01 17:18:21 +03:00
"**/CODEOWNERS",
"**/dist",
"**/node_modules",
"**/test-results",
"**/yarn.lock",
"cred-scan-suppressions.json",
feat(onboard-1es-pt): Onboard to 1ES Pipeline Templates (#1610) #### Details Onboards the CI/build pipeline to 1ES Pipeline Templates. - I was unable to onboard the pipeline to use the SDL TSA option. TSA v2 requires that a configuration file. In v1, the pipeline passes inputs and stored the values as pipeline variables. While the pipeline can generate the TSA configuration file on the pipeline, I was not successful is getting the SDL TSA task access to the file as the file is created in a separate job and stage. - As a result, the pipeline will keep the "SDT" job. Whenever there's a solution with 1ES PT (for example, accept inputs), then we could likely remove the SDT entirely as all tasks are handled by 1ES PT SDL analysis. - This PR does update the SDT tasks to the latest version. - Example build where TSA is successful (otherwise the task runs only merge happens on main branch): https://dev.azure.com/accessibility-insights-private/Accessibility%20Insights%20(private)/_build/results?buildId=43592&view=results - Creates a suppression file to skip CodeQL errors related to `yarn-3.5.0.cjs`. Reference: https://eng.ms/docs/cloud-ai-platform/devdiv/one-engineering-system-1es/1es-docs/1es-pipeline-templates/features/sdlanalysis/baselines#azure-devops-based-builds - Adds an inline comment to suppress (what appears to be) a false-positive warning on a markdown/escape function. - I found that running windows and linux yielded the same build time, so I defaulted to Windows given that the steps are platform agnostic and 1ES PT on Windows has more analysis tools at this time. - Build performance: - 1ES PT runs in approximately 10-11 minutes - Previous pipeline ran in approximately 7-9 minutes ##### Motivation https://dev.azure.com/mseng/1ES/_workitems/edit/2033962 ##### 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 --> - [x] Addresses an existing issue: Fixes #0000 - [x] Added relevant unit test for your changes. (`yarn test`) - [x] Verified code coverage for the changes made. Check coverage report at: `<rootDir>/test-results/unit/coverage` - [x] Ran precheckin (`yarn precheckin`)
2023-03-31 21:40:28 +03:00
"package.json",
"guardian"
chore: Adding codeowners, pull request template & update readme (#4) * adding code owners & pull request template * updating readme * adding copyright header * fix code formatting
2020-02-19 22:38:02 +03:00
],
adding copyright check, linting, prettier & build support (#1) * adding copyright check, linting, prettier & build support * adding support to run jest tests; adding watch support
2020-02-13 04:52:40 +03:00
"license": "./copyright-header.txt",
"licenseFormats": {
"yaml|npmrc|yml|ps1|gitignore|dockerignore|prettierignore|yarnrc|nsh|sh": {
"eachLine": {
"prepend": "# "
}
},
"ts|tsx|d.ts|js|scss|css": {
"eachLine": {
"prepend": "// "
}
},
"md": {
"prepend": "<!--",
"append": "-->"
}
},
"trailingWhitespace": "TRIM"
}