No, this isn't the kind of thing that should require a vote (unless someone
really wants a vote).
On Thu, Jun 7, 2018 at 9:29 AM Udi Meiri wrote:
> Would I need a vote on installing this plugin, or can I just open a ticket
> to infra?
>
> On Wed, Jun 6, 2018, 16:18 Robert Bradshaw wrote:
>
>>
I don't see any downside to enabling this plugin; we previously
filed BEAM-4400 [1] for this work. I believe the next steps would be
working with Infra on enabling it.
[1] https://issues.apache.org/jira/browse/BEAM-4400
On Thu, Jun 7, 2018 at 9:29 AM Udi Meiri wrote:
> Would I need a vote on
Would I need a vote on installing this plugin, or can I just open a ticket
to infra?
On Wed, Jun 6, 2018, 16:18 Robert Bradshaw wrote:
> Even if it's not perfect, seems like it'd surely be a net win (and
> probably a large one). Also, the build cache should look back at more than
> just the
Even if it's not perfect, seems like it'd surely be a net win (and probably
a large one). Also, the build cache should look back at more than just the
single previous build, so if any previous jobs (up to the cache size limit)
built/tested artifacts unchanged by the current PR, the results would
To follow up on the Jenkins Job Cacher Plugin:
Using a Jenkins plugin to save and reuse the Gradle cache for successive
precommit jobs.
The problem with this approach is that the precommit runs that a Jenkins
server runs are unrelated.
Say you have 2 PRs, A and B, and the precommit job for B
I've been having a separate discussion on the proposal doc, which is ready
for another round of reviews.
Change summary:
- Changed fast requirement to be < 30 minutes and simplify the check as an
aggregate for each precommit job type.
- Updated slowness notification methods to include automated
With regard to the Job Cacher Plugin: I think it is an infra ticket to
install? And I guess we need it longer term when we move to containerized
builds anyhow? One thing I've experienced with the Travis-CI cache is that
the time spent uploading & downloading the remote cache - in that case of
all
I second Robert idea of ‘inteligently’ running only the affected tests,
probably
there is no need to run Java for a go fix (and eventually if any issue it
can be
catched in postcommit), same for a dev who just fixed something in KafkaIO
and has
to wait for other IO tests to pass. I suppose that
What we can do here is estimate how much effort we want to put in and set
remote target.
Such as:
Third quarter 2018 -- 1hr SLO
Forth quarter 2018 -- 30min SLO,
etc.
Combined with policy for newly added tests, this can give us some goal to
aim for.
--Mikhail
Have feedback
Thanks for the proposal, I left comments in the doc. Overall I think it's a
great idea.
I've seen other projects with much faster pre-commits, and it requires
strict guidelines on unit test design and keeping tests isolated in-memory
as much as possible. That's not currently the case in Java; we
Good proposal. I think it should be considered in tandem with the "No
commit on red post-commit" proposal and could be far more ambitious than 2
hours. For example, something in the <15-20 mins range, say, would be much
less of an inconvenience to the development effort. Go takes ~3 mins, which
re: intelligently skipping tests for code that doesn't change (i.e. Java
tests on Python PR): this should be possible. We already have build-caching
enabled in Gradle, but I believe it is local to the git workspace and
doesn't persist between Jenkins runs.
With a quick search, I see there is a
Now that were using gradle, perhaps we could be more intelligent
about only running the affected tests? E.g. when you touch Python (or
Go) you shouldnt need to run the Java precommit at all, which
would reduce the latency for those PRs and also the time spent in
queue. Presumably this could even
I like the idea. I think it is a good time for the project to start
tracking this and keeping it usable.
Certainly 2 hours is more than enough, is that not so? The Java precommit
seems to take <=40 minutes while Python takes ~20 and Go is so fast it
doesn't matter. Do we have enough stragglers
HI,
I have a proposal to improve contributor experience by keeping precommit
times low.
I'm looking to get community consensus and approval about:
1. How long should precommits take. 2 hours @95th percentile over the past
4 weeks is the current proposal.
2. The process for dealing with slowness.
15 matches
Mail list logo
