hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Lowe <jl...@oath.com.INVALID>
Subject Re: Same jenkins build running on 2 patches.
Date Fri, 01 Dec 2017 21:36:45 GMT
Is it possible to track the patch by JIRA attachment ID rather than assume
the most recent attachment is the right one?  I thought the admin precommit
build was kicking off the project-specific precommit build with an
attachment ID argument so the project precommit can be consistent with the
admin precommit build on what triggered the precommit process.  If the
patch is tracked by attachment ID then I think the build would remain
consistent even when users attach new patches in the middle of the
precommit process.

Jason


On Fri, Dec 1, 2017 at 2:43 PM, Allen Wittenauer <aw@effectivemachines.com>
wrote:

>
> > On Dec 1, 2017, at 12:18 PM, Rushabh Shah <rushabhs@oath.com> wrote:
> > Can someone explain me what happened ?
>
>         Yetus downloaded the patch to make sure it applied before
> bothering to do anything else to make sure it wasn’t going to burn cycles
> on the build boxes for no reason.  Docker mode was active so it then went
> to re-exec itself under Docker.  But it had to build the Docker image
> first. This can take anywhere from 9 minutes to 20 minutes, depending
> primarily on which branch’s Dockerfile was in use.  While this was going
> on, another two patches were uploaded.  Docker build finishes. When Yetus
> re-exec’ed itself under Docker, it re-grabs the patch (since the
> world—including Yetus itself!--may be different now that it is Docker).  In
> this case, it grabbed the last of the newly uploaded patches and attempted
> to churn it’s way through it.
>
>         a) Uploading two patches at once has never ever worked and will
> likely never be made to work. (There are lots of reasons for this.)
>
>         b) Before uploading a new patch, wait for the feedback or at least
> make sure the Jenkins job is actually past “Determining needed tests”
> before uploading a new one.  Just be aware that test output is going to get
> very hard to follow with all of the cross posting.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message