[WIP] ci: notify reviewers/maintainers for specific subsystems#7
Closed
jforissier wants to merge 10 commits intomasterfrom
Closed
[WIP] ci: notify reviewers/maintainers for specific subsystems#7jforissier wants to merge 10 commits intomasterfrom
jforissier wants to merge 10 commits intomasterfrom
Conversation
541088a to
73f274b
Compare
dcf447a to
dcc9a48
Compare
dcc9a48 to
4e51bea
Compare
9d0284c to
826e168
Compare
f58522b to
88aff83
Compare
|
Notifying maintainers/reviewers: @jforissier |
e1fa0ad to
732aa20
Compare
Split the QEMUv8 jobs so that each jobs runs a single "make check" command. This allows to make the job names more descriptive, and potentially benefit more from multiple parallel jobs. Signed-off-by: Jerome Forissier <[email protected]> Acked-by: Jens Wiklander <[email protected]>
Instead of running the base CI image (jforissier/optee_os_ci:qemu_check) and pulling the whole OP-TEE source tree (manifest.git) and toolchains in each check job, do it once per target platform (QEMUv7, QEMuv8, and QEMUv8 on arm64) and save the image as a "job artifact". Each check job then loads the image it needs and proceeds with the check command. In addition to saving bandwidth on the external network, this has the advantage of making the jobs easier to reproduce and investigate in case of failure since it is easy to download the artifact from the CI page, load it into Docker, and run the same make check command. There is a small penalty on execution time for saving and restoring the image, but it's only a few minutes at most. Signed-off-by: Jerome Forissier <[email protected]> Acked-by: Jens Wiklander <[email protected]>
732aa20 to
644b547
Compare
Since same file is used for both i.MX8ULP and i.MX9X platforms, renaming it to more accurate name. Signed-off-by: Sahil Malhotra <[email protected]> Acked-by: Jens Wiklander <[email protected]>
Add MU driver support for imx95 Signed-off-by: Sahil Malhotra <[email protected]> Acked-by: Jens Wiklander <[email protected]>
Add MU Base address and MU size for imx95 Signed-off-by: Sahil Malhotra <[email protected]> Acked-by: Jens Wiklander <[email protected]>
Enable both MU and ELE driver for imx95 Signed-off-by: Sahil Malhotra <[email protected]> Acked-by: Jens Wiklander <[email protected]>
Enable support of getting HUK and RNG from ELE on imx95 Signed-off-by: Sahil Malhotra <[email protected]> Acked-by: Jens Wiklander <[email protected]>
There has been an addition of PQC related fields in Get Info Command response for i.MX95. Signed-off-by: Sahil Malhotra <[email protected]> Acked-by: Jens Wiklander <[email protected]>
ELE firmware has been divided into 2 firmwares for i.MX8ULP and i.MX95: Primary and secondary firmware. SAB init command is in Secondary firmware, which will be loaded when rootfs comes up, so this command is not available when OP-TEE is initializing. Moreover, we are not using any ELE command which is available in secondary firmware, So removing sab_init() function. Will add it when it will be used in driver. Signed-off-by: Sahil Malhotra <[email protected]> Acked-by: Jens Wiklander <[email protected]>
dc4a73b to
d4e4594
Compare
Introduce a new Python script: notify_maintainers.py and run it in CI
as part of a new job. When invoked in the context of a pull request
against the OP-TEE OS official project, it invokes get_maintainer.py
to find out the GitHub handles of the people to whom the change in the
PR is relevant. It then posts a comment so that these people may be
notified via email. People are mentioned only once per PR (they
normally receive subsequent messages automatically). The PR author,
assignees and requested reviewers (if any) are skipped since they are
already notified, as well as the default maintainers ("THE REST") who
are assumed to receive all PRs. The format of the comment is:
github-actions (bot) commented ...
FYI <handle1> <handle2>...
Note: Subsystem/platform maintainers who have their GitHub handle in
MAINTAINERS and who already "watch" the project will receive two emails
upon creation of a PR that touches their area of expertise: one when
the PR is created, and one shortly after when the script runs and the
GitHub bot tags them in a comment. Hopefully it is only a minor
inconvenience.
Note 2: The script was written with the help of generative AI. It was
reviewed, tested and modified by me.
Signed-off-by: Jerome Forissier <[email protected]>
Acked-by: Jens Wiklander <[email protected]>
Acked-by: Sumit Garg <[email protected]>
Reviewed-by: Rouven Czerwinski <[email protected]>
d4e4594 to
b4a39af
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Introduce a new Python script called notify_maintainers.py and run it in CI. What it does is simple: when invoked in CI and in the context of a pull request, it uses get_maintainer.py to find out the GitHub handles of all the persons who may be concerned by the changes made in the PR and posts a comment so that these persons may be notified via email. People are tagged only once per PR (they normally receive subsequent messages automatically). PR author, assignees and requested reviewers (if any) are skipped, as well as the default maintainers ("THE REST").
FIXME: People who have their GitHub handle in the MAINTAINERS file and who are already subscribed to receive PR notifications will most likely receive two emails upon creation of a PR that touches their area of expertise -- one when the PR is created, and one shortly after when the script runs and the GitHub bot tags them in a comment. This need to be checked.