1
0
mirror of https://github.com/Unleash/unleash.git synced 2024-12-22 19:07:54 +01:00
unleash.unleash/.github/workflows/gradual-strict-null-checks.yml

73 lines
2.5 KiB
YAML
Raw Normal View History

chore: gradually reduce null-check errors (#3094) ## About the changes In order to move us towards enabling `strictNullChecks` we'd want to have a way of gradually enabling this without having to fix all errors at once, this will force us to start reducing the number of null check issues. This new workflow: 1. [Checks out the current branch and main into 2 different folders](https://github.com/Unleash/unleash/pull/3094/files#diff-068f2ace1d1d2e773fb5e4240c83ccab251556fd5524fe13847122878e40da3bR15-R23) 2. Uses the **same** script `gradual-strict-null-checks.sh` (from the current branch) [against each folder in parallel](https://github.com/Unleash/unleash/pull/3094/files#diff-068f2ace1d1d2e773fb5e4240c83ccab251556fd5524fe13847122878e40da3bR34-R38) to count the number of errors if `strictNullChecks` was enabled 3. If the number of potential errors in the current branch is higher than the number of potential errors in main [it fails](https://github.com/Unleash/unleash/pull/3094/files#diff-068f2ace1d1d2e773fb5e4240c83ccab251556fd5524fe13847122878e40da3bR41-R46) As an example, a [new issue was introduced in this PR](https://github.com/Unleash/unleash/pull/3094/commits/753f57223c2107278dd7ee387444847e5cc4496a) (and then [reverted](https://github.com/Unleash/unleash/pull/3094/commits/e4deb62965bdc12b22c2a78a85588b237943483a)), so we can test the build failure: https://github.com/Unleash/unleash/actions/runs/4163632636/jobs/7204268519#step:5:10 ## Discussion points This could be a non-mandatory check, just advising, or even adding a comment in the PR. It might be good to start with a non-strict check, but at the same time we can decide to make it non-strict if a problem appears In some situations, an additional null check error might require us to fix a bunch of them, increasing the time to deliver. In these cases we can suppress an individual line with `// @ts-ignore: Object is possibly 'null'.` although might defeat the purpose of this workflow
2023-02-14 15:52:21 +01:00
name: Lower null checks
on:
pull_request:
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
jobs:
build:
runs-on: ubuntu-latest
env:
MAIN_BRANCH: main
chore: gradually reduce null-check errors (#3094) ## About the changes In order to move us towards enabling `strictNullChecks` we'd want to have a way of gradually enabling this without having to fix all errors at once, this will force us to start reducing the number of null check issues. This new workflow: 1. [Checks out the current branch and main into 2 different folders](https://github.com/Unleash/unleash/pull/3094/files#diff-068f2ace1d1d2e773fb5e4240c83ccab251556fd5524fe13847122878e40da3bR15-R23) 2. Uses the **same** script `gradual-strict-null-checks.sh` (from the current branch) [against each folder in parallel](https://github.com/Unleash/unleash/pull/3094/files#diff-068f2ace1d1d2e773fb5e4240c83ccab251556fd5524fe13847122878e40da3bR34-R38) to count the number of errors if `strictNullChecks` was enabled 3. If the number of potential errors in the current branch is higher than the number of potential errors in main [it fails](https://github.com/Unleash/unleash/pull/3094/files#diff-068f2ace1d1d2e773fb5e4240c83ccab251556fd5524fe13847122878e40da3bR41-R46) As an example, a [new issue was introduced in this PR](https://github.com/Unleash/unleash/pull/3094/commits/753f57223c2107278dd7ee387444847e5cc4496a) (and then [reverted](https://github.com/Unleash/unleash/pull/3094/commits/e4deb62965bdc12b22c2a78a85588b237943483a)), so we can test the build failure: https://github.com/Unleash/unleash/actions/runs/4163632636/jobs/7204268519#step:5:10 ## Discussion points This could be a non-mandatory check, just advising, or even adding a comment in the PR. It might be good to start with a non-strict check, but at the same time we can decide to make it non-strict if a problem appears In some situations, an additional null check error might require us to fix a bunch of them, increasing the time to deliver. In these cases we can suppress an individual line with `// @ts-ignore: Object is possibly 'null'.` although might defeat the purpose of this workflow
2023-02-14 15:52:21 +01:00
strategy:
matrix:
node-version: [16.x]
steps:
- name: Checkout current branch
uses: actions/checkout@v3
with:
path: current
- name: Checkout main branch
uses: actions/checkout@v3
with:
ref: ${{ env.MAIN_BRANCH }}
chore: gradually reduce null-check errors (#3094) ## About the changes In order to move us towards enabling `strictNullChecks` we'd want to have a way of gradually enabling this without having to fix all errors at once, this will force us to start reducing the number of null check issues. This new workflow: 1. [Checks out the current branch and main into 2 different folders](https://github.com/Unleash/unleash/pull/3094/files#diff-068f2ace1d1d2e773fb5e4240c83ccab251556fd5524fe13847122878e40da3bR15-R23) 2. Uses the **same** script `gradual-strict-null-checks.sh` (from the current branch) [against each folder in parallel](https://github.com/Unleash/unleash/pull/3094/files#diff-068f2ace1d1d2e773fb5e4240c83ccab251556fd5524fe13847122878e40da3bR34-R38) to count the number of errors if `strictNullChecks` was enabled 3. If the number of potential errors in the current branch is higher than the number of potential errors in main [it fails](https://github.com/Unleash/unleash/pull/3094/files#diff-068f2ace1d1d2e773fb5e4240c83ccab251556fd5524fe13847122878e40da3bR41-R46) As an example, a [new issue was introduced in this PR](https://github.com/Unleash/unleash/pull/3094/commits/753f57223c2107278dd7ee387444847e5cc4496a) (and then [reverted](https://github.com/Unleash/unleash/pull/3094/commits/e4deb62965bdc12b22c2a78a85588b237943483a)), so we can test the build failure: https://github.com/Unleash/unleash/actions/runs/4163632636/jobs/7204268519#step:5:10 ## Discussion points This could be a non-mandatory check, just advising, or even adding a comment in the PR. It might be good to start with a non-strict check, but at the same time we can decide to make it non-strict if a problem appears In some situations, an additional null check error might require us to fix a bunch of them, increasing the time to deliver. In these cases we can suppress an individual line with `// @ts-ignore: Object is possibly 'null'.` although might defeat the purpose of this workflow
2023-02-14 15:52:21 +01:00
path: main
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v3
with:
node-version: ${{ matrix.node-version }}
cache: 'yarn'
cache-dependency-path: |
current/yarn.lock
main/yarn.lock
- name: Compare errors if enabling strictNullChecks
env:
URL: ${{ github.event.pull_request.comments_url }}
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
comment () {
curl -X POST $URL \
-H "Content-Type: application/json" \
-H "Authorization: token $GITHUB_TOKEN" \
--data "{ \"body\": \"${1}\" }"
}
YARN_1="yarn --mutex network --cwd ./current"
YARN_2="yarn --mutex network --cwd ./main"
$YARN_1 install --ignore-scripts &> /dev/null && $YARN_1 build --strictNullChecks true 2> .stderr-current > .out-current &
chore: gradually reduce null-check errors (#3094) ## About the changes In order to move us towards enabling `strictNullChecks` we'd want to have a way of gradually enabling this without having to fix all errors at once, this will force us to start reducing the number of null check issues. This new workflow: 1. [Checks out the current branch and main into 2 different folders](https://github.com/Unleash/unleash/pull/3094/files#diff-068f2ace1d1d2e773fb5e4240c83ccab251556fd5524fe13847122878e40da3bR15-R23) 2. Uses the **same** script `gradual-strict-null-checks.sh` (from the current branch) [against each folder in parallel](https://github.com/Unleash/unleash/pull/3094/files#diff-068f2ace1d1d2e773fb5e4240c83ccab251556fd5524fe13847122878e40da3bR34-R38) to count the number of errors if `strictNullChecks` was enabled 3. If the number of potential errors in the current branch is higher than the number of potential errors in main [it fails](https://github.com/Unleash/unleash/pull/3094/files#diff-068f2ace1d1d2e773fb5e4240c83ccab251556fd5524fe13847122878e40da3bR41-R46) As an example, a [new issue was introduced in this PR](https://github.com/Unleash/unleash/pull/3094/commits/753f57223c2107278dd7ee387444847e5cc4496a) (and then [reverted](https://github.com/Unleash/unleash/pull/3094/commits/e4deb62965bdc12b22c2a78a85588b237943483a)), so we can test the build failure: https://github.com/Unleash/unleash/actions/runs/4163632636/jobs/7204268519#step:5:10 ## Discussion points This could be a non-mandatory check, just advising, or even adding a comment in the PR. It might be good to start with a non-strict check, but at the same time we can decide to make it non-strict if a problem appears In some situations, an additional null check error might require us to fix a bunch of them, increasing the time to deliver. In these cases we can suppress an individual line with `// @ts-ignore: Object is possibly 'null'.` although might defeat the purpose of this workflow
2023-02-14 15:52:21 +01:00
pid1=$!
$YARN_2 install --ignore-scripts &> /dev/null && $YARN_2 build --strictNullChecks true 2> .stderr-main > .out-main &
chore: gradually reduce null-check errors (#3094) ## About the changes In order to move us towards enabling `strictNullChecks` we'd want to have a way of gradually enabling this without having to fix all errors at once, this will force us to start reducing the number of null check issues. This new workflow: 1. [Checks out the current branch and main into 2 different folders](https://github.com/Unleash/unleash/pull/3094/files#diff-068f2ace1d1d2e773fb5e4240c83ccab251556fd5524fe13847122878e40da3bR15-R23) 2. Uses the **same** script `gradual-strict-null-checks.sh` (from the current branch) [against each folder in parallel](https://github.com/Unleash/unleash/pull/3094/files#diff-068f2ace1d1d2e773fb5e4240c83ccab251556fd5524fe13847122878e40da3bR34-R38) to count the number of errors if `strictNullChecks` was enabled 3. If the number of potential errors in the current branch is higher than the number of potential errors in main [it fails](https://github.com/Unleash/unleash/pull/3094/files#diff-068f2ace1d1d2e773fb5e4240c83ccab251556fd5524fe13847122878e40da3bR41-R46) As an example, a [new issue was introduced in this PR](https://github.com/Unleash/unleash/pull/3094/commits/753f57223c2107278dd7ee387444847e5cc4496a) (and then [reverted](https://github.com/Unleash/unleash/pull/3094/commits/e4deb62965bdc12b22c2a78a85588b237943483a)), so we can test the build failure: https://github.com/Unleash/unleash/actions/runs/4163632636/jobs/7204268519#step:5:10 ## Discussion points This could be a non-mandatory check, just advising, or even adding a comment in the PR. It might be good to start with a non-strict check, but at the same time we can decide to make it non-strict if a problem appears In some situations, an additional null check error might require us to fix a bunch of them, increasing the time to deliver. In these cases we can suppress an individual line with `// @ts-ignore: Object is possibly 'null'.` although might defeat the purpose of this workflow
2023-02-14 15:52:21 +01:00
pid2=$!
# wait for the processes that are expected to fail
set +e
wait $pid1
wait $pid2
set -e
CURRENT=$(grep "Found [0-9]* errors" .out-current | sed 's/Found \(.*\) errors in .* files./\1/')
MAIN=$(grep "Found [0-9]* errors" .out-main | sed 's/Found \(.*\) errors in .* files./\1/')
chore: gradually reduce null-check errors (#3094) ## About the changes In order to move us towards enabling `strictNullChecks` we'd want to have a way of gradually enabling this without having to fix all errors at once, this will force us to start reducing the number of null check issues. This new workflow: 1. [Checks out the current branch and main into 2 different folders](https://github.com/Unleash/unleash/pull/3094/files#diff-068f2ace1d1d2e773fb5e4240c83ccab251556fd5524fe13847122878e40da3bR15-R23) 2. Uses the **same** script `gradual-strict-null-checks.sh` (from the current branch) [against each folder in parallel](https://github.com/Unleash/unleash/pull/3094/files#diff-068f2ace1d1d2e773fb5e4240c83ccab251556fd5524fe13847122878e40da3bR34-R38) to count the number of errors if `strictNullChecks` was enabled 3. If the number of potential errors in the current branch is higher than the number of potential errors in main [it fails](https://github.com/Unleash/unleash/pull/3094/files#diff-068f2ace1d1d2e773fb5e4240c83ccab251556fd5524fe13847122878e40da3bR41-R46) As an example, a [new issue was introduced in this PR](https://github.com/Unleash/unleash/pull/3094/commits/753f57223c2107278dd7ee387444847e5cc4496a) (and then [reverted](https://github.com/Unleash/unleash/pull/3094/commits/e4deb62965bdc12b22c2a78a85588b237943483a)), so we can test the build failure: https://github.com/Unleash/unleash/actions/runs/4163632636/jobs/7204268519#step:5:10 ## Discussion points This could be a non-mandatory check, just advising, or even adding a comment in the PR. It might be good to start with a non-strict check, but at the same time we can decide to make it non-strict if a problem appears In some situations, an additional null check error might require us to fix a bunch of them, increasing the time to deliver. In these cases we can suppress an individual line with `// @ts-ignore: Object is possibly 'null'.` although might defeat the purpose of this workflow
2023-02-14 15:52:21 +01:00
if [ $CURRENT -gt $MAIN ]; then
comment "After enabling [\`strictNullChecks\`](https://www.typescriptlang.org/tsconfig#strictNullChecks) this PR would be **increasing** the number of null check errors from ${MAIN} to ${CURRENT}. <br /> Make sure your branch is up-to-date with ${MAIN_BRANCH} and **check the diff in the console output** to pinpoint the offending files."
diff .out-current .out-main
chore: gradually reduce null-check errors (#3094) ## About the changes In order to move us towards enabling `strictNullChecks` we'd want to have a way of gradually enabling this without having to fix all errors at once, this will force us to start reducing the number of null check issues. This new workflow: 1. [Checks out the current branch and main into 2 different folders](https://github.com/Unleash/unleash/pull/3094/files#diff-068f2ace1d1d2e773fb5e4240c83ccab251556fd5524fe13847122878e40da3bR15-R23) 2. Uses the **same** script `gradual-strict-null-checks.sh` (from the current branch) [against each folder in parallel](https://github.com/Unleash/unleash/pull/3094/files#diff-068f2ace1d1d2e773fb5e4240c83ccab251556fd5524fe13847122878e40da3bR34-R38) to count the number of errors if `strictNullChecks` was enabled 3. If the number of potential errors in the current branch is higher than the number of potential errors in main [it fails](https://github.com/Unleash/unleash/pull/3094/files#diff-068f2ace1d1d2e773fb5e4240c83ccab251556fd5524fe13847122878e40da3bR41-R46) As an example, a [new issue was introduced in this PR](https://github.com/Unleash/unleash/pull/3094/commits/753f57223c2107278dd7ee387444847e5cc4496a) (and then [reverted](https://github.com/Unleash/unleash/pull/3094/commits/e4deb62965bdc12b22c2a78a85588b237943483a)), so we can test the build failure: https://github.com/Unleash/unleash/actions/runs/4163632636/jobs/7204268519#step:5:10 ## Discussion points This could be a non-mandatory check, just advising, or even adding a comment in the PR. It might be good to start with a non-strict check, but at the same time we can decide to make it non-strict if a problem appears In some situations, an additional null check error might require us to fix a bunch of them, increasing the time to deliver. In these cases we can suppress an individual line with `// @ts-ignore: Object is possibly 'null'.` although might defeat the purpose of this workflow
2023-02-14 15:52:21 +01:00
exit 1
else
echo "The PR has $CURRENT null check errors against $MAIN in main. You're good to go!"
fi