Above that, though, in the acquisition of the *geode* resource, we see /opt/resource/lib/commands/in.rb:23:in `output': *PR has merge conflicts* (RuntimeError) from /opt/resource/lib/commands/in.rb:110:in `<main>'
That resource could not then be passed to the lower tasks *rsync_code_down *et al, resulting in the error you were seeing missing inputs: geode, instance-data While we have had some Concourse instability recently, we see no issue with those tests surrounding the one you linked. On Wed, Oct 31, 2018 at 12:36 PM, Kirk Lund <kl...@apache.org> wrote: > Just in case, others hit this: The one I was asking about failed with > "missing inputs: geode, instance-data" which Dan said means that Concourse > barfed. When this happens, pushing an empty commit or anything else was > recommended to re-trigger. > > https://concourse.apachegeode-ci.info/teams/main/pipelines/ > apache-develop-pr/jobs/AcceptanceTest/builds/293 > > Thanks, > Kirk > > On Wed, Oct 31, 2018 at 11:19 AM, Patrick Rhomberg <prhomb...@apache.org> > wrote: > > > Just to disseminate the knowledge... > > > > Although we like it when everyone just works nicely, you can check the > > consumption of your PR in the Concourse by looking at the *geode* > resource > > in the *apache-develop-pr* pipeline [1]. This resource passes the PR > > number and associated SHA to test against, so you can search for your PR > in > > this list. > > > > The first thing that the jobs are meant to do to add Check Status hooks > to > > GitHub that let us click into the specific job, but you can see in the > > *geode* resource if a job has suffered infrastructure failures. For > > instance, clicking on *0c5f7* or *ccd90* of your *pr 2730*, I see that > the > > jobs failed to launch due to merge conflicts. (Aside [2].) > > > > The PR precheckin is always run against the "if this were merged" version > > of Geode. If a precheckin doesn't fire, it is often because there are > > merge conflicts that must be resolved first. Merge origin/develop into > > your branch and push to your fork, and you should be good to go. > <soapbox> > > And if you use a merge rather than a rebase, you don't have the history > > (such as the SHAs I referenced above) disappear on you. </soapbox> > > > > To head off another potential source of confusion when looking at the > > Concourse resource, you might notice that some SHAs in your *geode* > > resource > > history will be skipped if they are immediately identified as older than > > the PR's current HEAD. For instance, your *pr 2730* with SHA *98491* > > didn't > > get a precheckin run, since it was immediately superseded by the newer > > *5ffc0* commit. > > > > But, the bottom line is: make sure you're merged with *origin/develop* > when > > you open / push your PR and precheckin should (tm) consistently fire, > > barring other infrastructure instability. > > > > Hope that helps! > > > > Imagination is Change. > > ~Patrick > > > > [1] > > https://concourse.apachegeode-ci.info/teams/main/pipelines/ > > apache-develop-pr/resources/geode > > [2] Currently, we don't get the GitHub hook when there are merge > conflicts > > because the Concourse resource acquisition itself fails and we never > reach > > the task in Concourse to update the GitHub hooks. We should probably > > investigate if there is a way to add the hooks in the case of a merge > > conflict, to avoid the potential for developer confusion. > > > > On Tue, Oct 30, 2018 at 4:16 PM, Kirk Lund <kl...@apache.org> wrote: > > > > > Nevermind. I pushed again and it seems to have triggered this time. > > > > > > On Tue, Oct 30, 2018 at 2:51 PM, Kirk Lund <kl...@apache.org> wrote: > > > > > > > I have a PR that I updated a while ago, but it's not automatically > > firing > > > > a precheckin. > > > > > > > > What's the expected behavior? Is it supposed to automatically > trigger a > > > > precheckin if I push more changes? > > > > > > > > Here's my PR: https://github.com/apache/geode/pull/2730 > > > > > > > > PS: the PR isn't ready to actually merge, it's just the only way I > know > > > to > > > > run a precheckin now > > > > > > > > Thanks, > > > > Kirk > > > > > > > > > > > > > >
