Andre I think that solution strikes the right balance without being a lot of
effort.
As mentioned Travis-ci's docs say that caching stuff like .m2 doesn't help but
in my experience you usually still get a little bump so it's worth it as long
as the ci isn't lying about the results. Removing ~/.
Aldrin,
While we may not get much granularity we can certainly hack our way by "rm
-rf ~/.m2/repository/whatever_we_want_to_delete" prior to calling maven ?
I appreciate caching is sometime a pain, but given our build currently
takes almost 40 minutes and travis-ci.org jobs will timeout at 50 min
In my experiencies, caching is always a source of trouble, specially when
is very long lived.
Might be nifi can analyse both scenarios, one with caching, might be 12h to
24h, where the project accept some degree of false positive, or my
prefered, without, testing all is going to take always some t
Awesome, thanks for fixing it up, Bryan.
I don't think we can get that kind of granularity with Travis,
unfortunately. However, the last time was because an artifact changed its
name (or more specifically, casing).
Not sure removing caching is the best option, but seems like the the
optimization
Thanks Aldrin, I pushed the commit.
As far as travis, I am not familiar with how it works, but can you
specify what to cache?
In this case we didn't need a completely clean .m2, we just needed a
clean .m2/org/apache/nifi.
On Sat, Mar 25, 2017 at 11:10 AM, Aldrin Piri wrote:
> Please just push t
Please just push to correct. Simple fixes are fine in my book.
Does it make sense to potentially scrap caching in Travis?
This is another time we have missed something like this that no caching
would have prevented. Additionally, given the large footprint of the
repository download it seems as th
Andre,
Thanks for bringing this up.
The standard prioritizers moved from the standard bundle to the
framework bundle, and sure enough the parent was still set as standard
bundle. We had never built with a clean repo and were getting lucky,
so I am glad you found this.
In
nifi-nar-bundles/nifi-f
dev,
Is anyone else having issues building master from "clean" (i.e. rm -rf
~/.m2/repositories/org/apache/nifi) after commit d90cf84 ?
My attempts to build currently yield:
$ mvn -T2.0C -DskipTests=true -Pdir-only clean install
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were
Maybe the feature is to allow the specification of one or more policies to
apply to flows
before they are deployed.
The system would provide a default policy for status quo ante.
You could provide a ‘NoAutoTerminationPolicy’.
This could be a component run by nar etc etc
On March 25, 2017 at 05:
Hi Russell,
what about checking the flow.xml prior to deploying it into production
use. Search for you particular processors and the
success
pattern.
One can integrate such QA checks into CI/CD pipeline as we do using Jenkins.
Hope that helps.
Michal
On Fri, Mar 24, 2017 at 10:50 PM, Russell Bate
10 matches
Mail list logo
