I agree with not randomizing CI runs. It's frustrating when CI failures
aren't reproducible. We could possibly have a base class for tests that
alters the JVM time zone and runs parameterized. Seems like some work, but
it would probably be worth it in the end.
On Tue, Mar 2, 2021 at 5:38 AM
Perhaps we can randomly pick a timezone from a smaller, predefined list?
That should make it more straightforward to check how the random zone was
picked on the CI.
The list could include UTC, along with one zone each from the
Northern/Southern/Eastern/Western hemispheres (including at least one
I would try to avoid randomness in any CI runs.
I might be able to accept it if it is very easy/straightforward to repro the
random generation.
Otherwise we might end up with randomly failing CI tests which we can not repro.
> On Mar 2, 2021, at 13:40, russell.spit...@gmail.com wrote:
>
> What
What if we had the Ci time zone be random?
Sent from my iPhone
> On Mar 2, 2021, at 5:54 AM, Peter Vary wrote:
>
> Maybe separating the unit tests for this would not worth the effort.
>
> I was thinking we should run the tests like this:
>
> diff --git a/build.gradle b/build.gradle
> index
Maybe separating the unit tests for this would not worth the effort.
I was thinking we should run the tests like this:
diff --git a/build.gradle b/build.gradle
index fd716e12..9b361ea7 100644
--- a/build.gradle
+++ b/build.gradle
@@ -133,6 +133,9 @@ subprojects {
}
test {
+if
In ORC, the timezone tests vary the default timezone through multiple
values using the Java APIs. (They do restore the initial value when the
test exits.) :)
.. Owen
On Mon, Mar 1, 2021 at 9:25 PM Edgar Rodriguez
wrote:
> Hi folks,
>
> Thanks Peter for the quick fix!
>
> I do think it'd be a
Hi folks,
Thanks Peter for the quick fix!
I do think it'd be a good idea to have this kind of coverage to some
extent. Usually, a workflow some users follow is to only run locally the
modules that they modify and rely on the CI to run the full check which
takes longer, which makes room for these
I'm not sure it would be worth separating out the timezone tests to do
this. I think we catch these problems pretty quickly with the number of
users building in different zones. Is this something we want to spend time
on?
On Mon, Mar 1, 2021 at 10:29 AM Russell Spitzer
wrote:
> In the Spark
In the Spark Cassandra Connector we had a similar issue, we would
specifically spawn test JVM's with different default local time zones to
make sure we handled these use cases, I also would make our test dates ones
on gregorian calendar boundaries so being an hour off with result in a
timestamp
Hi Team,
Last weekend I caused a little bit of stir by pushing changes which had a green
run on CI, but was failing locally if the default TZ was different than UTC.
Do we want to set the TZ of the CI tests to some random non-UTC TZ to catch
these errors?
Pros:
We can catch tests which are
10 matches
Mail list logo
