You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Kirk Lund <kl...@apache.org> on 2018/10/30 21:51:27 UTC
Pull request precheckin not firing automatically
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
Re: Pull request precheckin not firing automatically
Posted by Kirk Lund <kl...@apache.org>.
But when I sent the email, the PR page on github stated:
This branch has no conflicts with the base branchMerging can be performed
automatically.
Which, in my understanding means there are no merge conflicts.
Stuff is flaky and that's ok. I just want to know how it's supposed to work
so I know what to expect.
On Thu, Nov 1, 2018 at 9:36 AM, Patrick Rhomberg <pr...@apache.org>
wrote:
> 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 <prhomberg@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
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Pull request precheckin not firing automatically
Posted by Patrick Rhomberg <pr...@apache.org>.
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 <pr...@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
> > > >
> > > >
> > >
> >
>
Re: Pull request precheckin not firing automatically
Posted by Kirk Lund <kl...@apache.org>.
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 <pr...@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
> > >
> > >
> >
>
Re: Pull request precheckin not firing automatically
Posted by Patrick Rhomberg <pr...@apache.org>.
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
> >
> >
>
Re: Pull request precheckin not firing automatically
Posted by Kirk Lund <kl...@apache.org>.
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
>
>