chore: migrate build from azure-pipelines to actions

[armano2]

This is POC of build migration from azure-pipelines to actions

---

From my research about github actions:

• higher concurrent job count (20)
• we can setup tasks/jobs for releases to npm and github packages from within github
• actions allow us to automate tagging/closing stale tickets, and setup automatic responses
• for branch in same repository as PR, it runs action only once for branch and shares it with PR
• in case of error in matrix step (by default) its stops all other steps from matrix, e.g.
  https://github.com/armano2/node-markdown-spellcheck/runs/364664300
• other big projects that migrated to actions:
  • typescript: https://github.com/microsoft/TypeScript/actions
  • eslint: https://github.com/eslint/eslint/actions
  • prettier: https://github.com/prettier/prettier/actions
  • babel: https://github.com/babel/babel/actions
  • jest: https://github.com/facebook/jest/actions
  • vscode: https://github.com/microsoft/vscode/actions
  • node: https://github.com/nodejs/node/actions

Examples

• Build: https://github.com/armano2/typescript-eslint/runs/363745143
• PR: https://github.com/armano2/typescript-eslint/pull/8/checks

External project test

• PR: https://github.com/armano2/node-markdown-spellcheck/pull/3

[bradzacher]

@JamesHenry was the one that set up all of the azure stuff. Would like his eyeball.

Also do you know how easy it is to setup actions for things like locking old, closed issues? I get annoyed when people necro old things, but have been too lazy to investigate a bot 😅

Also we have the typescript-eslint bot which posts on PRs whenever they are opened - would that be easy to migrate?

[armano2]

Also do you know how easy it is to setup actions for things like locking old, closed issues? I get annoyed when people necro old things, but have been too lazy to investigate a bot 😅

yea i could set this up to, but this can be done in separate PR

about our bot, there few actions that are already prepeared for this for example:
https://github.com/marketplace/actions/first-interaction or https://github.com/marketplace/actions/close-stale-issues

name: Greetings

on: [pull_request, issues]

jobs:
  greeting:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/first-interaction@v1
      with:
        repo-token: ${{ secrets.GITHUB_TOKEN }}
        issue-message: 'Message that will be displayed on users'' first issue'
        pr-message: 'Message that will be displayed on users'' first pr'

[JamesHenry]

Err...why? 😅 also we have a slack channel precisely to discuss things like this

[armano2]

@JamesHenry i added small description

[bradzacher]

one good reason to move to github actions is because it centralises the admin, which makes it a bit more transparent.
Otherwise I see it as "the same as azure pipelines".

Same for the bots, having them as actions would be a win for transparent and easy maintaining (eg I don't know where or how the PR message bot is implemented atm).

[codecov]

Codecov Report

Merging #1383 into master will increase coverage by 0.3%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master    #1383     +/-   ##
=========================================
+ Coverage   95.19%   95.49%   +0.3%     
=========================================
  Files         148      150      +2     
  Lines        6967     6639    -328     
  Branches     2007     1880    -127     
=========================================
- Hits         6632     6340    -292     
+ Misses        124      112     -12     
+ Partials      211      187     -24

Impacted Files	Coverage Δ
...pt-estree/src/ts-estree/estree-to-ts-node-types.ts	0% <0%> (-100%)	⬇️
...s/eslint-plugin/src/rules/interface-name-prefix.ts	83.33% <0%> (-16.67%)	⬇️
...-plugin/src/rules/no-unnecessary-type-assertion.ts	90.12% <0%> (-6.85%)	⬇️
packages/eslint-plugin/src/rules/unbound-method.ts	94.44% <0%> (-2.23%)	⬇️
...ackages/eslint-plugin/src/rules/no-implied-eval.ts	95.91% <0%> (-1.91%)	⬇️
packages/eslint-plugin/src/rules/typedef.ts	95.91% <0%> (-1.35%)	⬇️
...plugin/src/rules/explicit-module-boundary-types.ts	85.45% <0%> (-0.76%)	⬇️
...-plugin/src/rules/explicit-member-accessibility.ts	96.36% <0%> (-0.74%)	⬇️
...ackages/eslint-plugin/src/rules/member-ordering.ts	92.3% <0%> (-0.38%)	⬇️
...nt-plugin/src/rules/no-unused-vars-experimental.ts	91.39% <0%> (-0.1%)	⬇️
... and 41 more

[bradzacher]

I think this is a good idea. I'm happy to merge this as a trial at the very least.
We can run both azure and github actions for a period whilst we make a greater decision

[bradzacher]

Question - did we want to split all of this up to give us more granular status checks?
I know that a bit of a pain point for people is just seeing "primary validation" failed, and then having to dig into the logs to see which step failed.

I.e. one job for each of:

• type check
• format check
• lint
• spelling
• test + integration (+ coverage publish) test on latest node

[armano2]

you actually don't have to as actions are showing it in overview screen

example: https://github.com/armano2/test-eslint-monorpo/actions/runs/36409848

you can click on Check failure on line 1 in packages/a/src/index.js if file was modified it's going to show annotation within this file

[armano2]

as for codecov/codecov-action we should wait for codecov/codecov-action#53 to get merged first as it has same issue with PR ids as pipelines

for now we could just disable it or use bash uploader