Add basic support for white-listing tests to run on new PRs.#10
Add basic support for white-listing tests to run on new PRs.#10samoht wants to merge 3 commits intolinuxkit:masterfrom
Conversation
|
/cc @dave-tucker The workflow for testing stuff is very basic atm but it should be able to do the basic things needed, e.g. build/test will be done if someone on the whitelist opened the PR or if someone on the whitelist said "test me". The code compiles but is untested ... Before merging, a |
talex5
left a comment
talex5
left a comment
There was a problem hiding this comment.
I think the whitelist check should be a separate (non-cached) build step. This would avoid duplicating the check in build and test, and should make it rebuild exactly when needed.
src/PR_state.ml
Outdated
| let test_this c = | ||
| (* The user doing the comment is in the whitelist and he/she | ||
| says "test this" *) | ||
| in_whitelist (Comment.user c) && contains "test this" (Comment.body c) |
There was a problem hiding this comment.
Looks like Jenkins uses test this please - maybe that's less prone to mistakes? (e.g. Did you test this?)
src/linuxkit_build.ml
Outdated
| | Error e -> Utils.failf "Unexpected DB error: %a" DK.pp_error e | ||
|
|
||
| let branch _t { Key.src; target} = | ||
| let branch _t { Key.src; target; _} = |
There was a problem hiding this comment.
It doesn't make sense to ignore something that's in the key. If you want all PRs, branches and tags to rebuild whenever the whitelist changes, the (hash of) the whitelist needs to be in the branch name.
If you don't, then the whitelist should be in the context.
Most likely, checking whether someone is whitelisted has nothing to do with building LinuxKit and should be checked as a separate (non-cached) build step. Then, changing the whitelist will only rebuild PRs affected by the change.
src/linuxkit_build.ml
Outdated
| Result_cache.find t job_id key | ||
| Term.target target >>= fun target_v -> | ||
| let key = { Builder.Key. src; target; whitelist; } in | ||
| let context = { Builder.job_id; target = target_v } in |
There was a problem hiding this comment.
I don't think putting the target in the context makes sense either. Whether a PR is built does depend on the state of the PR, not just on the commit.
|
As suggested by @talex5, I've added the PR check as a separate pipeline step so it could be cached more easily. The current pipeline becomes:
|
samoht
force-pushed
the
whitelist
branch
3 times, most recently
from
80c13b3 to
41e6d9d
Compare
|
LGTM and a whitelist file now exists in this repo. Is this good to merge/test? |
|
It is using unreleased features in datakit-github, so I need to add a few pins in the Dockerfile (doing that now). But if you managed to get it compiled it should be good to test. |
Currently, the only working option is to say "ok to test" to allow a PR to be tested. Signed-off-by: Thomas Gazagnaire <thomas@gazagnaire.org>
Signed-off-by: Thomas Gazagnaire <thomas@gazagnaire.org>
|
I've just fixed the Dockerfile so you should be able to test it more easily. |
|
What's the current plan regarding LinuxKit CI? Should I close this PR? |
|
Hmm, we don't have a very determinate plan over CI at present... so maybe. |
4 participants
Currently, the only working option is to say "test this" to allow
a PR to be tested.
Signed-off-by: Thomas Gazagnaire thomas@gazagnaire.org