Skip to content

clarify CI workflow docs #221

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Oct 15, 2021
Merged

clarify CI workflow docs #221

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
53 changes: 37 additions & 16 deletions website/docs/ci_workflow.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,28 +31,12 @@ cancellation, test, and ModuleCheck jobs run in parallel on three different runn
"optimistic" workflow, in that it assumes that the `modulecheck` task will not generate changes
which would trigger a restart.

The reason for "cancel previous CI run" having its own runner is nuanced, and doesn't apply to all
platforms. It does apply to GitHub Actions. In situations where the number of available runners is
limited, jobs can get queued. This is especially true if committing changes from ModuleCheck, as
this will double the number of jobs being queued.

In these cases, it's important that stale runs get cancelled as soon as possible, and so it's
important that the job which cancels the stale jobs is never stuck in a queue. Ideally, the
cancellation job would be running on a different class of runners which does not get used for other
tasks. That way, there can be a queue for tasks like unit tests, modulecheck, or lint, but there
will always be a runner available for automatically cancelling stale jobs.

```mermaid
flowchart TB
Start(CI Start):::good --> mGraph
Start --> tGraph
Start --> cGraph

subgraph cGraph [runner 3]
direction TB
Cancel(Cancel previous CI run):::code
end

subgraph mGraph [runner 1]
direction TB
ModuleCheck(./gradlew moduleCheck):::code --> ChangesModuleCheck
Expand All @@ -65,7 +49,13 @@ flowchart TB
Tests(./gradlew test):::code --> EndTests("#10003;"):::good
end

subgraph cGraph [runner 3]
direction TB
Cancel(Cancel previous CI run):::code
end

style tGraph fill:#EEE,stroke:#000
style cGraph fill:#EEE,stroke:#000
style mGraph fill:#EEE,stroke:#000

classDef good fill:#0B0,stroke:#000
Expand All @@ -92,6 +82,17 @@ on:

jobs:

cancel-stale-jobs:
name: Cancel stale jobs
runs-on: ubuntu-latest

steps:
# cancel previous jobs
- name: Cancel Previous Runs
uses: styfle/cancel-workflow-action@0.9.0
env:
GITHUB_TOKEN: '${{ secrets.GITHUB_TOKEN }}'

ModuleCheck:
name: ModuleCheck
runs-on: ubuntu-latest
Expand Down Expand Up @@ -121,4 +122,24 @@ jobs:
with:
commit_message: Apply ModuleCheck changes
commit_options: '--no-verify --signoff'

tests:
name: Unit tests
runs-on: ubuntu-latest

steps:
- uses: actions/checkout@v2
with:
ref: ${{ github.event.pull_request.head.ref }}
token: ${{ secrets.GITHUB_TOKEN }}
fetch-depth: 0

- name: Set up JDK
uses : actions/setup-java@v2
with :
distribution : 'temurin'
java-version : '14'

- name: all tests
run: ./gradlew test --no-daemon
```
53 changes: 37 additions & 16 deletions website/versioned_docs/version-0.11.2/ci_workflow.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,28 +31,12 @@ cancellation, test, and ModuleCheck jobs run in parallel on three different runn
"optimistic" workflow, in that it assumes that the `modulecheck` task will not generate changes
which would trigger a restart.

The reason for "cancel previous CI run" having its own runner is nuanced, and doesn't apply to all
platforms. It does apply to GitHub Actions. In situations where the number of available runners is
limited, jobs can get queued. This is especially true if committing changes from ModuleCheck, as
this will double the number of jobs being queued.

In these cases, it's important that stale runs get cancelled as soon as possible, and so it's
important that the job which cancels the stale jobs is never stuck in a queue. Ideally, the
cancellation job would be running on a different class of runners which does not get used for other
tasks. That way, there can be a queue for tasks like unit tests, modulecheck, or lint, but there
will always be a runner available for automatically cancelling stale jobs.

```mermaid
flowchart TB
Start(CI Start):::good --> mGraph
Start --> tGraph
Start --> cGraph

subgraph cGraph [runner 3]
direction TB
Cancel(Cancel previous CI run):::code
end

subgraph mGraph [runner 1]
direction TB
ModuleCheck(./gradlew moduleCheck):::code --> ChangesModuleCheck
Expand All @@ -65,7 +49,13 @@ flowchart TB
Tests(./gradlew test):::code --> EndTests("#10003;"):::good
end

subgraph cGraph [runner 3]
direction TB
Cancel(Cancel previous CI run):::code
end

style tGraph fill:#EEE,stroke:#000
style cGraph fill:#EEE,stroke:#000
style mGraph fill:#EEE,stroke:#000

classDef good fill:#0B0,stroke:#000
Expand All @@ -92,6 +82,17 @@ on:

jobs:

cancel-stale-jobs:
name: Cancel stale jobs
runs-on: ubuntu-latest

steps:
# cancel previous jobs
- name: Cancel Previous Runs
uses: styfle/cancel-workflow-action@0.9.0
env:
GITHUB_TOKEN: '${{ secrets.GITHUB_TOKEN }}'

ModuleCheck:
name: ModuleCheck
runs-on: ubuntu-latest
Expand Down Expand Up @@ -121,4 +122,24 @@ jobs:
with:
commit_message: Apply ModuleCheck changes
commit_options: '--no-verify --signoff'

tests:
name: Unit tests
runs-on: ubuntu-latest

steps:
- uses: actions/checkout@v2
with:
ref: ${{ github.event.pull_request.head.ref }}
token: ${{ secrets.GITHUB_TOKEN }}
fetch-depth: 0

- name: Set up JDK
uses : actions/setup-java@v2
with :
distribution : 'temurin'
java-version : '14'

- name: all tests
run: ./gradlew test --no-daemon
```