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

76 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:
workflow_dispatch:
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
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: [20.x]
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
steps:
- name: Checkout current branch
uses: actions/checkout@v4
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
with:
path: current
- name: Checkout main branch
uses: actions/checkout@v4
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
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 }}
chore(deps): update actions/setup-node action to v4 (#5891) [![Mend Renovate](https://app.renovatebot.com/images/banner.svg)](https://renovatebot.com) This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [actions/setup-node](https://togithub.com/actions/setup-node) | action | major | `v3` -> `v4` | --- ### Release Notes <details> <summary>actions/setup-node (actions/setup-node)</summary> ### [`v4`](https://togithub.com/actions/setup-node/compare/v3...v4) [Compare Source](https://togithub.com/actions/setup-node/compare/v3...v4) </details> --- ### Configuration 📅 **Schedule**: Branch creation - "after 7pm every weekday,before 5am every weekday" in timezone Europe/Madrid, Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View repository job log [here](https://developer.mend.io/github/Unleash/unleash). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4xMjcuMCIsInVwZGF0ZWRJblZlciI6IjM3LjEyNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiJ9--> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
2024-01-17 08:56:41 +01:00
uses: actions/setup-node@v4
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
with:
node-version: 20.x
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
cache: 'yarn'
cache-dependency-path: |
current/yarn.lock
main/yarn.lock
- name: Enable corepack
run: corepack enable
- 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 &> /dev/null && $YARN_1 build:backend --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 &> /dev/null && $YARN_2 build:backend --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