You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add Workflows for generating reference results (#410)
* add machine info to reference results
* rename script to unify naming
* add workflows
* make autopep happy and trigger wf once :)
* made wf callable
* remove push trigger
* added some switch case to check for the different names until changes propagate
* Fix non terminating timeouts (#421)
Co-authored-by: Valentin Seitz <valentin.seitz@tum.de>
* Systests/move to commits (#422)
* remove non working gha cache stuff
* Move to only commits in the dockerfile
---------
Co-authored-by: Valentin Seitz <valentin.seitz@tum.de>
* adopt new naming schema
* filter lscpu to hide vulnerabilities
* move to consistent naming schema
* Adding reference results from precice-tests vm
* Make autopep8
* make paths a bit nicer and easier to understand
* Update tools/tests/README.md
Co-authored-by: Gerasimos Chourdakis <chourdak@in.tum.de>
* Update tools/tests/README.md
Co-authored-by: Gerasimos Chourdakis <chourdak@in.tum.de>
* introduce variable instead of magic number 10
* added comment on very long rm instructions
---------
Co-authored-by: Valentin Seitz <valentin.seitz@tum.de>
Co-authored-by: preCICE Tests VM <tests@precice.org>
Co-authored-by: Gerasimos Chourdakis <chourdak@in.tum.de>
where the `*_REF`can also be specific Git commits.
44
+
where the `*_REF`should be a specific [commit-ish](https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefcommit-ishacommit-ishalsocommittish).
In the summary, we can find the results and more logs as a build artifact. This includes two interesting files: `stdout.log` and `stderr.log`. These include all Docker build steps and the simulation output, as well as the exact git clone command.
79
+
The easiest way to debug a systemtest run is first to have a look at the output written into the action on GitHub.
80
+
If this does not provide enough hints, the next step is to download the generated `runs` artifact. Note that by default this will only be generated if the systemtests fail.
81
+
Inside the archive, a test-specific subfolder like `flow-over-heated-plate_fluid-openfoam-solid-fenics_2023-11-19-211723` contains two log files: a `stderr.log` and `stdout.log`. This can be a starting point for a further investigation.
91
82
92
83
## Adding new tests
93
84
@@ -138,7 +129,7 @@ Metadata and workflow/script files:
138
129
- ...
139
130
-`metadata.yml`: describes each case directory (which participant, which component, which script to run, ...)
140
131
-`tools/tests/`
141
-
-`component-templates/`: jinja2 templates for Docker Compose services, specifying cache system
132
+
-`component-templates/`: jinja2 templates for Docker Compose services for the components
142
133
-`calculix-adapter.yaml`
143
134
-`fenics-adapter.yaml`
144
135
-`openfoam-adapter.yaml`
@@ -149,7 +140,7 @@ Metadata and workflow/script files:
149
140
-`docker-compose.field_compare.template.yaml`: Describes how to compare results with fieldcompare (Docker Compose service template)
150
141
-`components.yaml`: Declares the available components and their parameters/options
151
142
-`reference_results.metadata.template`: Template for reporting the versions used to generate the reference results
152
-
-`reference_versions.yaml`: Versions of components to use for generating the reference results
143
+
-`reference_versions.yaml`: List of arguments to use for generating the reference results
153
144
-`tests.yaml`: Declares the available tests, grouped in test suites
154
145
155
146
User-facing tools:
@@ -160,7 +151,7 @@ User-facing tools:
160
151
-`print_metadata.py`: Prints the metadata of each tutorial that contains a `metadata.yaml` file.
161
152
-`print_case_combinations.py`: Prints all possible combinations of tutorial cases, using the `metadata.yaml` files.
162
153
-`build_docker_images.py`: Build the Docker images for each test
163
-
-`generate_reference_data.py`: Executes the system tests with the versions defined in `reference_versions.yaml` and generates the reference data archives, with the names described in `tests.yaml`.
154
+
-`generate_reference_results.py`: Executes the system tests with the versions defined in `reference_versions.yaml` and generates the reference data archives, with the names described in `tests.yaml`. (should only be used by the CI Pipeline)
164
155
165
156
Implementation scripts:
166
157
@@ -226,7 +217,7 @@ The components mentioned in the Metadata are defined in the central `components.
build_arguments: # these things mean something to the docker-service
220
+
build_arguments:
230
221
PRECICE_REF:
231
222
description: Version of preCICE to use
232
223
default: "main"
@@ -247,15 +238,15 @@ openfoam-adapter:
247
238
248
239
This `openfoam-adapter` component has the following attributes:
249
240
250
-
- `repository`: URL to the Git project (without the `.git` extension), used to fetch the component
241
+
- `repository`: URL to the Git projects
251
242
- `template`: A template for a Docker Compose service of this component
252
243
- `build_arguments`: Arguments passed to the Docker Compose service (arbitrary)
253
244
254
245
#### Naming schema for build_arguments
255
246
256
247
Since the docker containers are still a bit mixed in terms of capabilities and support for different build_argument combinations the following rules apply:
257
248
258
-
- A build_argument ending in **_REF** means that it refers to a git reference (like a branch or commit) beeing used to build the image.
249
+
- A build_argument ending in **_REF** means that it refers to a git commit-ish (like a tag or commit) beeing used to build the image. Its important to not use branch names here as we heavily rely on dockers build cache to speedup things. But since the input variable to the docker builder will not change, we might have wrong cache hits.
259
250
- All other build_arguments are free of rules and up to the container maintainer.
260
251
261
252
### Component templates
@@ -313,8 +304,19 @@ This defines two test suites, namely `openfoam_adapter_pr` and `openfoam_adapter
313
304
314
305
### Generate Reference Results
315
306
307
+
#### via GitHub workflow (recommended)
308
+
309
+
The preferred way of adding reference results is via the manual triggerable `Generate reference results (manual)` workflow. This takes two inputs:
310
+
311
+
- `from_ref`: branch where the new test configuration (e.g added tests, new reference_versions.yaml) is
312
+
- `commit_msg`: commit message for adding the reference results into the branch
313
+
314
+
The workflow will checkout the `from_ref`, take the status of the systemtests of that branch and execute `python generate_reference_results.py`, upload the LFS objects into the self-hosted LFS server and add a commit with `commit_msg` onto the `from_ref` branch.
315
+
316
+
#### manually
317
+
316
318
In order to generate the reference results edit the `reference_versions.yaml` to match the required `build_arguments` otherwise passed via the cli.
317
-
Executing `generate_reference_data.py` will then generate a the following files:
319
+
Executing `generate_reference_results.py` will then generate the following files:
318
320
319
321
- all distinct `.tar.gz` defined in the `tests.yaml`
320
322
- a `reference_results.md` in the tutorial folder describing the arguments used and a sha-1 hash of the `tar.gz` archive.
0 commit comments