Feature/654 add and use general matrix#860
Conversation
| workflow_call: | ||
| inputs: | ||
| matrix_keys: | ||
| description: "Space-separated BaseConfig keys to include in the generated matrix output" |
There was a problem hiding this comment.
Should check if space separated is secure, reasonable
There was a problem hiding this comment.
Why not a JSON string (which then must be an array)?
|
|
||
| @pytest.fixture | ||
| def config(tmp_path) -> BaseConfig: | ||
| class Config(BaseConfig): |
There was a problem hiding this comment.
@tomuben and @tkilias
We should discuss if this is an ok pattern for the ITDE.
So the two options I see are:
- As built in, one can extend the BaseConfig with additional fields. These should be typed & pydantic can validate the input before other operations are executed. I think that's a nice feature.
- We allow BaseConfig to have extra fields which are not checked by pydantic. The benefit would be that you do not have to inherit and extend the BaseConfig.
| @@ -1,40 +0,0 @@ | |||
| (( workflow_header )) | |||
There was a problem hiding this comment.
Similar to how we have released slow-checks.yml from PTB control, I though we could remove these template ymls. If a project cannot immediately migrate, they can retain these files. We will keep the nox sessions until 2026-09-15, so there isn't a major change. Does that sound alright or do we need to not do (or a major release)?
| """ | ||
| Return the config keys that are valid for matrix generation. | ||
|
|
||
| Includes both declared fields and computed fields. |
There was a problem hiding this comment.
I don't understand the difference and intention of distinguishing "declared" vs. "computed" fields.
Could we (if this distinction is important) maybe add some explanation and/or example to the documentation?
There was a problem hiding this comment.
Thanks, I added more context in the docstring.
| return parser.parse_args(session.posargs).keys | ||
|
|
||
|
|
||
| def _dump_matrix(config: BaseConfig, keys: Iterable[str]) -> dict[str, Any]: |
There was a problem hiding this comment.
I am a bit confused by the variety of functions and names.
There is _dump...(), _print_...(), and generate_...().
Could we maybe
- Reduce this to a single term, e.g. generate (which is my favorite)
- If some of these functions are somewhat deprecated, old, outdated, or to be removed in near future, then maybe add a prefix or suffix like
old_or_deprecated, etc.?
There was a problem hiding this comment.
Additionally, it seems, the file is (still) called _ci.yml but all functions in it only seem to deal with matrixes. Maybe _build_matrix.py could be a better name?
Hence, we could maybe also simplify the names of the functions inside it my removing redundant pre- or suffixes which could also give us more freedom in other naming issues, e.g. when distinguishing current/new/future variants from old/deprecated/outdated ones?
There was a problem hiding this comment.
Good point with the name. To match the other ones, I've shifted it to _matrix.py. At this time, I wouldn't do other refactorings on this higher file level, as I feel they're out of scope with this issue.
Ok, I've move deprecated to be at the front of the function, but it was in the _print_deprecated_matrix and tried to align the names.
| matrix = _python_matrix(PROJECT_CONFIG) | ||
| matrix.update(_exasol_matrix(PROJECT_CONFIG)) | ||
| print(json.dumps(matrix)) | ||
| _print_deprecated_matrix( |
There was a problem hiding this comment.
Could we maybe in one place add an explanation about the semantics and meaning of the key_map attribute?
Currently, it maps strings (which a dash character) to other strings (with an underscore).
Why?
There was a problem hiding this comment.
Yes, I will add an explanation. The main purpose is to include in the deprecated method the shift you need to switch to the newer matrix generation.
I'm ok to remove that if you think it's too much.
|



relates to #654
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: