Thanks Larry! Yes, these are integration tests (and not Unit Tests), should have mentioned that earlier.
I can def. check the time, it shouldn't be much but i'll check the numbers and report back here. I did not think of Opt-Out but there is a "Squash and merge" option in Github that developers have, where they can merge even when the checks have failed or are in process. I think we can use this option and keep the plumbing around tests simple, just my thoughts! [image: image.png] On Wed, Nov 19, 2025 at 12:22 PM larry mccay <[email protected]> wrote: > This sounds great, @Sandeep More <[email protected]>! > I assume these are more like integration tests rather than our current unit > test focus? > > I will be interested in seeing how much time this would add to the PR > review process and ability to get simple fixes in. > Would we be able to opt-out of such tests for one-liner type fixes in order > to not be blocked? > > We can consider those sorts of things once we have an idea of the stability > of these tests and effects on timeliness. > > On Wed, Nov 19, 2025 at 12:03 PM Sandeep Moré <[email protected]> > wrote: > > > Hello, > > I have been thinking of including docker based CI tests for Knox. The > idea > > is when someone opens up a PR we would kick these tests off and push the > > results on the PR and depending on the results block/gate the merge. > > > > This ensures that features are well tested and gives us as developers > more > > confidence in merging pull requests. > > > > Currently, I have a POC that I am working on that I am planning to > submit a > > PR for. Trying to get a vibe check from the community and opinions and > > objections if any. > > > > This would be a continuous process, as in, we will need to add tests for > > features we build, this is something projects like Apache Trino [1] do > > currently and have had success with. > > > > Thanks, > > Sandeep > > > > > > > > [1] https://github.com/trinodb/trino/ > > >
