Feature/825 split up workflows unit tests and periodic runs#826
Feature/825 split up workflows unit tests and periodic runs#826ArBridgeman wants to merge 11 commits intomainfrom
Conversation
|
83e2a12 to
6193139
Compare
| @@ -0,0 +1,26 @@ | |||
| name: Fast-Tests-Extension | |||
There was a problem hiding this comment.
Is there no template for this workflow by intention?
Why?
There was a problem hiding this comment.
Ah! I think I understood:
- default workflow (generated from template) is
fast-tests.yml - The yaml renderer has been enhanced to allow
(%ifsections - Such a section includes a call to an individual workflow file if such exists.
There was a problem hiding this comment.
Maybe add a comment to this file?
Or user guide?
| @@ -0,0 +1,37 @@ | |||
| name: Periodic-Validation | |||
|
|
||
| run-slow-checks: | ||
| name: Slow Checks | ||
| uses: ./.github/workflows/slow-checks.yml |
There was a problem hiding this comment.
Should we keep the name "slow-checks" or would "slow-tests" be better as pendant to "fast-tests"?
OK looking below, I think you already came to a conclusion here.
- run-fast-checks
- run-fast-tests
- run-slow-checks
| class WorkflowExtension(BaseModel): | ||
| """ | ||
| Used to define which workflow extensions are active. | ||
| The corresponding `*-extension.yml` must be defined in the project. |
There was a problem hiding this comment.
| The corresponding `*-extension.yml` must be defined in the project. | |
| The corresponding files `*-extension.yml` are optional | |
| but must be added in the individual projects. |
| The corresponding `*-extension.yml` must be defined in the project. | ||
| """ | ||
|
|
||
| fast_tests: bool = Field( |
There was a problem hiding this comment.
Couldn't the renderer look for the files and include them if they exist?
In this case we wouldn't need an additional configuration in the noxconfig.
There could also be options when calling nox session workflow:generate, e.g. --fast-tests-extension and --slow-checks-extension to generate an initial empty skeleton.
|
|
||
| - name: Run Integration Tests | ||
| id: run-integration-tests | ||
| run: poetry run -- nox -s test:integration -- --coverage --db-version ${{ matrix.exasol-version }} |
There was a problem hiding this comment.
Having this by default is a problem, because for most projects that would cause most slow tests to run sequentially. I think the good thing is that the slow-tests don't need to implement the merge-gate anymore. So, we could think about giving this as an example, but with the intention that this will be changed. And, for things like installing Python, creating matrix builds, or uploading coverage, we provide tools and jinja templates/macros.
| @@ -45,3 +45,10 @@ | |||
| name: coverage-python${{ matrix.python-version }}-exasol${{ matrix.exasol-version }}-slow | |||
There was a problem hiding this comment.
We could assume that slow-tests run coverage for a matrix or in sub-workflows, so we probably need a more robust way to define the name of the coverage file name. Maybe we should add the workflow name, if this is possible. And, if available, the matrix. This might need a jinja macro with parameters to achieve
| name: coverage-python${{ matrix.python-version }}-exasol${{ matrix.exasol-version }}-slow | ||
| path: .coverage | ||
| include-hidden-files: true | ||
| (% if workflow_extension.slow_checks %) |
There was a problem hiding this comment.
If we assume the Wild West in this file, we probably don't need this
| secrets: inherit | ||
| permissions: | ||
| contents: read | ||
|
|
There was a problem hiding this comment.
We probably need here an extension workflow call for approval-protected tests that are independent of the slow tests. For example, GPU or SaaS, we might want long-term to split up from the slow tests because they are not always needed for integration tests and they are even more expensive. For GPU tests, we already do this in some repos. An equivalent we probably need in the periodic validation. The idea is that the project can duplicate the structure for slow tests for their own manual approvals.
closes #825
Checklist
Note: If any of the items in the checklist are not relevant to your PR, just check the box.
For any Pull Request
Is the following correct:
When Changes Were Made
Did you:
When Preparing a Release
Have you: