if we disable caching, let it run for 1 build and enable it again, will
that effectively clear the .m2 cache?
On 23.05.2016 12:00, Robert Metzger wrote:
We could also try to disable the caching of the .m2 directory (I suspect
that it contains broken jar files). The problem is that it this will
We could also try to disable the caching of the .m2 directory (I suspect
that it contains broken jar files). The problem is that it this will make
the builds slower on travis because we need to download more.
On Mon, May 23, 2016 at 10:18 AM, Chesnay Schepler
wrote:
> If this doesn't work we ma
If this doesn't work we may want to think about disabling the
problematic profile temporarily.
On 23.05.2016 09:53, Ufuk Celebi wrote:
Caches have been cleared again (see
https://issues.apache.org/jira/browse/INFRA-11773) The first time did
not help. This second request was more an act of desp
Caches have been cleared again (see
https://issues.apache.org/jira/browse/INFRA-11773) The first time did
not help. This second request was more an act of desparation. :-(
Let's see what happens now.
On Wed, Apr 27, 2016 at 3:24 PM, Maximilian Michels wrote:
> +1 for making an effort to tackle t
+1 for making an effort to tackle test stability problems and
potential involved bugs.
On Wed, Apr 27, 2016 at 2:13 PM, Ufuk Celebi wrote:
> @Max: I think you wanted to look into whether we can use Apache's
> Jenkins server for our builds instead of Travis. Did you ever get
> around at looking in
Filed an issue with INFRA: https://issues.apache.org/jira/browse/INFRA-11773
@Robert: I agree, but still we see failing builds over and over again.
At best it is annoying, at worst it "hides" new bugs being introduced.
On Wed, Apr 27, 2016 at 2:41 PM, Till Rohrmann wrote:
> That is good to hear
That is good to hear that we can so easily solve most of the failing
builds. We should then iterate over the open test-stability issues to see
whether they are still valid after we've merged PR 1915.
On Wed, Apr 27, 2016 at 2:25 PM, Robert Metzger wrote:
> I'm not sure if the issues is as big as
I'm not sure if the issues is as big as it seems on a first sight.
The reason why all the builds of master are red on travis is that the cache
of the 5th build is invalid. We have to ask infra to delete the caches and
then they'll be green again.
On Wed, Apr 27, 2016 at 2:13 PM, Ufuk Celebi wrote
Along the lines of what Greg already mentioned, I would like to
re-iterate that Travis is often a problem too:
- long build times and we are reaching the time limit
- unreliable I/O
- unreliable resolving of build dependencies
@Max: I think you wanted to look into whether we can use Apache's
Jenki
We just issued a PR about this (FLINK-1827 - https://github.com/apache/
flink/pull/1915) that improves test stability (and allow to skip entirely
their compilation when it's not required) except for the ml library that
has still some one error to solve ( in the hadoop-1 build and in the
ml-library
We have also started running over Travis' 2 hour limit for the longest build.
Greg
> On Apr 27, 2016, at 7:53 AM, Ufuk Celebi wrote:
>
> Hi Till,
>
> thank you for bringing this up. We really need to fix this.
>
> Filing JIRAs with critical priority was how we tried to solve it in
> the past
Hi Till,
thank you for bringing this up. We really need to fix this.
Filing JIRAs with critical priority was how we tried to solve it in
the past, but obviously it did not work. There seems to be a mismatch
between assigned and actual priorities.
As a first step, I would volunteer to gather a li
Hi Flink community,
I just wanted to raise awareness that in the last 16 days there was just a
single Travis build of master which passed all tests. This indicates that
we have some serious problems with our test stability or even worse a
problem with the master itself. Having an unstable master m
13 matches
Mail list logo
