Skip to content

Feature/654 add and use general matrix#860

Open
ArBridgeman wants to merge 26 commits into
mainfrom
feature/654_add_and_use_general_matrix
Open

Feature/654 add and use general matrix#860
ArBridgeman wants to merge 26 commits into
mainfrom
feature/654_add_and_use_general_matrix

Conversation

@ArBridgeman

@ArBridgeman ArBridgeman commented Jun 9, 2026

Copy link
Copy Markdown
Collaborator

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:

  • the title of the Pull Request?
  • the title of the corresponding issue?
  • there are no other open Pull Requests for the same update/change?
  • that the issue which this Pull Request fixes ("Fixes...") is mentioned?

When Changes Were Made

Did you:

  • update the changelog?
  • update the cookiecutter-template?
  • update the implementation?
  • check coverage and add tests: unit tests and, if relevant, integration tests?
  • update the User Guide & other documentation?
  • resolve any failing CI criteria (incl. Sonar quality gate)?

When Preparing a Release

Have you:

  • thought about version number (major, minor, patch)?
  • checked Exasol packages for updates and resolved open vulnerabilities, if easily possible?

@ArBridgeman ArBridgeman marked this pull request as draft June 9, 2026 12:32
Comment thread .github/workflows/matrix.yml Outdated
workflow_call:
inputs:
matrix_keys:
description: "Space-separated BaseConfig keys to include in the generated matrix output"

@ArBridgeman ArBridgeman Jun 9, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should check if space separated is secure, reasonable

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not a JSON string (which then must be an array)?


@pytest.fixture
def config(tmp_path) -> BaseConfig:
class Config(BaseConfig):

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tomuben and @tkilias
We should discuss if this is an ok pattern for the ITDE.

So the two options I see are:

  1. 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.
  2. 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 ))

@ArBridgeman ArBridgeman Jun 9, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)?

@ArBridgeman ArBridgeman marked this pull request as ready for review June 11, 2026 11:46
Comment thread .github/workflows/matrix.yml
Comment thread .github/workflows/slow-checks.yml
Comment thread doc/changes/unreleased.md Outdated
Comment thread doc/changes/unreleased.md Outdated
Comment thread doc/changes/unreleased.md Outdated
Comment thread doc/user_guide/features/github_workflows/workflow_variables.rst Outdated
Comment thread exasol/toolbox/nox/_ci.py Outdated
"""
Return the config keys that are valid for matrix generation.

Includes both declared fields and computed fields.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I added more context in the docstring.

Comment thread exasol/toolbox/nox/_matrix.py Outdated
Comment thread exasol/toolbox/nox/_ci.py Outdated
return parser.parse_args(session.posargs).keys


def _dump_matrix(config: BaseConfig, keys: Iterable[str]) -> dict[str, Any]:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread exasol/toolbox/nox/_ci.py Outdated
matrix = _python_matrix(PROJECT_CONFIG)
matrix.update(_exasol_matrix(PROJECT_CONFIG))
print(json.dumps(matrix))
_print_deprecated_matrix(

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@ArBridgeman ArBridgeman Jun 12, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@sonarqubecloud

Copy link
Copy Markdown

@ArBridgeman ArBridgeman requested review from ckunki and tomuben June 12, 2026 10:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants