You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Konstantin Boudnik <co...@apache.org> on 2015/02/25 07:51:39 UTC
Patch validation on TC
Guys,
I have started working on TC's based patch validation where a job is
periodically checking against a certain Ignite JIRA filter and then pulls in
the latest available patches for the future validation.
What I've noticed is that some of the Patch Available (PA) state don't have
any attachments. E.g.
[22:16:45] Cos: what you're looking for is this
[05:59:21][Step 1/1] :slurp (1s)
[05:59:22][:slurp] IGNITE-311 is in invalid state: patch is not available
[05:59:22][:slurp] IGNITE-299 is in invalid state: patch is not available
[05:59:22][:slurp] IGNITE-239 is in invalid state: patch is not available
[05:59:22][:slurp] IGNITE-329 = https://issues.apache.org/jira/secure/attachment/12700377/0001-IGNITE-329-Example-of-CacheTypeMetadata-and-CacheJdb.patch
[05:59:22][:slurp] IGNITE-326 = https://issues.apache.org/jira/secure/attachment/12700497/ignite-326.patch
[05:59:22][:slurp] IGNITE-306 = https://issues.apache.org/jira/secure/attachment/12700471/ignite-306-1.patch
[05:59:22][:slurp] IGNITE-199 = https://issues.apache.org/jira/secure/attachment/12697480/sp-1_ignite-199_fixing_tests.patch
[05:59:22][:slurp] IGNITE-136 = https://issues.apache.org/jira/secure/attachment/12700498/136-2.patch
Dmitriy just mentioned to me that there some issues with patch application. I'd
happy to help if someone explains to me what seems to be the problem. Are the
issues arising because the patch has conflicts? Cause it might be a bit
difficult to resolve such conflicts: using git or svn merge is usually a way
more friendly. But the hurdle can be overcome using IDEA or similar systems.
One of the recipes for troubles is when patch is generated and then applied
with different prefix depth. E.g. git diff usually does something like
a/file
b/file
When such patch is applied from the top-level directory of the project one
needs to specify '-p1' option for patch commands. However if you are using 'git
format-patch' for patch creation then simple 'git am' should be sufficient
assuming the patch doesn't have any conflicts.
I don't believe patch size might be an issue, but would love to be pointed out
to the next trouble shall it happens.
--
Take care,
Cos
Re: Patch validation on TC
Posted by Konstantin Boudnik <co...@apache.org>.
It is possible that the patch just has addled. However, the latest patch seems
to be fine and I can put it on. As the code moves forward pretty fast I is
sorta expected that patches getting obsolete with the same speed. So, I guess
this mystery is solved.
And I still beg you guys: do not remove the old patches from JIRA when you put
new ones on - this is very confusing.
Regards,
Cos
On Sat, Feb 28, 2015 at 03:04PM, Alexey Kuznetsov wrote:
> Cos, I understand that you are working on automating of patches testing. :)
> I want to help you and send you c command that I used.
>
> So, I'm working from IDEA with git and can not tell you if it rebase
> branches.
> I just pull changes from origin/sprint-2 into ignute-187, manually resolve
> conflicts (if any, actually in case of IGNITE-187 I have several).
> And after that go to command line and execute git format-patch.
>
> Can you give me exact instructions I could apply on my local repo and
> create a new patch that will be tested by your scripts?
>
>
> On Sat, Feb 28, 2015 at 2:55 PM, Konstantin Boudnik <co...@apache.org> wrote:
>
> > Alexey,
> >
> > not picking up on you - just was working with this ticket hence the
> > example.
> >
> > Did you rebase your branch on top of origin/sprint-2 before generating the
> > patch? Ie
> > git rebase origin/sprint-2
> > possibly followed conflict resolving...
> >
> > Thanks,
> > Cos
> >
> > On Sat, Feb 28, 2015 at 02:46PM, Alexey Kuznetsov wrote:
> > > IGNITE-187 was fixed by me.
> > > I created patch as: git format-patch origin/sprint-2 --stdout >
> > > ignite-187.patch
> > >
> > > On Sat, Feb 28, 2015 at 2:34 PM, Konstantin Boudnik <co...@apache.org>
> > wrote:
> > >
> > > > Looks like I have stepped on (the same?) issue that everybody else. I
> > have
> > > > checked out the repo;
> > > >
> > > > % git clone --depth 1
> > > > https://git1-us-west.apache.org/repos/asf/incubator-ignite.git
> > > > % gco -b spint-2 origin/sprint-2
> > > > % git am ../IGNITE-187.patch
> > > >
> > > > and got this
> > > > Applying: IGNITE-187 Refactoring of node attributes.
> > > > error: patch failed:
> > > >
> > modules/core/src/main/java/org/apache/ignite/internal/GridKernalContext.java:500
> > > > error:
> > > >
> > modules/core/src/main/java/org/apache/ignite/internal/GridKernalContext.java:
> > > > patch does not apply
> > > > Patch failed at 0001 IGNITE-187 Refactoring of node attributes.
> > > > When you have resolved this problem run "git am --resolved".
> > > > If you would prefer to skip this patch, instead run "git am --skip".
> > > > To restore the original branch and stop patching run "git am --abort".
> > > >
> > > > Now, I'd like to figure out a couple of things, so I can move forward:
> > > > - how the patches are prepared: what is the _exact_ command being used
> > > > - are they cut after dev. branch is rebased over current integration
> > > > branch, sprint-2 I presume?
> > > > - is anyone else is seeng the same issues?
> > > >
> > > > Appreciate the input as it will help me to move forward with patch
> > > > validation. Thanks
> > > > Cos
> > > >
> > > > On Wed, Feb 25, 2015 at 06:51AM, Konstantin Boudnik wrote:
> > > > >
> > > > > Dmitriy just mentioned to me that there some issues with patch
> > > > application. I'd
> > > > > happy to help if someone explains to me what seems to be the problem.
> > > > Are the
> > > > > issues arising because the patch has conflicts? Cause it might be a
> > bit
> > > > > difficult to resolve such conflicts: using git or svn merge is
> > usually a
> > > > way
> > > > > more friendly. But the hurdle can be overcome using IDEA or similar
> > > > systems.
> > > > >
> > > > > One of the recipes for troubles is when patch is generated and then
> > > > applied
> > > > > with different prefix depth. E.g. git diff usually does something
> > like
> > > > > a/file
> > > > > b/file
> > > > > When such patch is applied from the top-level directory of the
> > project
> > > > one
> > > > > needs to specify '-p1' option for patch commands. However if you are
> > > > using 'git
> > > > > format-patch' for patch creation then simple 'git am' should be
> > > > sufficient
> > > > > assuming the patch doesn't have any conflicts.
> > > > >
> > > > > I don't believe patch size might be an issue, but would love to be
> > > > pointed out
> > > > > to the next trouble shall it happens.
> > > > >
> > > > > --
> > > > > Take care,
> > > > > Cos
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Alexey Kuznetsov
> > > GridGain Systems
> > > www.gridgain.com
> >
>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
Re: Patch validation on TC
Posted by Alexey Kuznetsov <ak...@gridgain.com>.
Cos, I understand that you are working on automating of patches testing. :)
I want to help you and send you c command that I used.
So, I'm working from IDEA with git and can not tell you if it rebase
branches.
I just pull changes from origin/sprint-2 into ignute-187, manually resolve
conflicts (if any, actually in case of IGNITE-187 I have several).
And after that go to command line and execute git format-patch.
Can you give me exact instructions I could apply on my local repo and
create a new patch that will be tested by your scripts?
On Sat, Feb 28, 2015 at 2:55 PM, Konstantin Boudnik <co...@apache.org> wrote:
> Alexey,
>
> not picking up on you - just was working with this ticket hence the
> example.
>
> Did you rebase your branch on top of origin/sprint-2 before generating the
> patch? Ie
> git rebase origin/sprint-2
> possibly followed conflict resolving...
>
> Thanks,
> Cos
>
> On Sat, Feb 28, 2015 at 02:46PM, Alexey Kuznetsov wrote:
> > IGNITE-187 was fixed by me.
> > I created patch as: git format-patch origin/sprint-2 --stdout >
> > ignite-187.patch
> >
> > On Sat, Feb 28, 2015 at 2:34 PM, Konstantin Boudnik <co...@apache.org>
> wrote:
> >
> > > Looks like I have stepped on (the same?) issue that everybody else. I
> have
> > > checked out the repo;
> > >
> > > % git clone --depth 1
> > > https://git1-us-west.apache.org/repos/asf/incubator-ignite.git
> > > % gco -b spint-2 origin/sprint-2
> > > % git am ../IGNITE-187.patch
> > >
> > > and got this
> > > Applying: IGNITE-187 Refactoring of node attributes.
> > > error: patch failed:
> > >
> modules/core/src/main/java/org/apache/ignite/internal/GridKernalContext.java:500
> > > error:
> > >
> modules/core/src/main/java/org/apache/ignite/internal/GridKernalContext.java:
> > > patch does not apply
> > > Patch failed at 0001 IGNITE-187 Refactoring of node attributes.
> > > When you have resolved this problem run "git am --resolved".
> > > If you would prefer to skip this patch, instead run "git am --skip".
> > > To restore the original branch and stop patching run "git am --abort".
> > >
> > > Now, I'd like to figure out a couple of things, so I can move forward:
> > > - how the patches are prepared: what is the _exact_ command being used
> > > - are they cut after dev. branch is rebased over current integration
> > > branch, sprint-2 I presume?
> > > - is anyone else is seeng the same issues?
> > >
> > > Appreciate the input as it will help me to move forward with patch
> > > validation. Thanks
> > > Cos
> > >
> > > On Wed, Feb 25, 2015 at 06:51AM, Konstantin Boudnik wrote:
> > > >
> > > > Dmitriy just mentioned to me that there some issues with patch
> > > application. I'd
> > > > happy to help if someone explains to me what seems to be the problem.
> > > Are the
> > > > issues arising because the patch has conflicts? Cause it might be a
> bit
> > > > difficult to resolve such conflicts: using git or svn merge is
> usually a
> > > way
> > > > more friendly. But the hurdle can be overcome using IDEA or similar
> > > systems.
> > > >
> > > > One of the recipes for troubles is when patch is generated and then
> > > applied
> > > > with different prefix depth. E.g. git diff usually does something
> like
> > > > a/file
> > > > b/file
> > > > When such patch is applied from the top-level directory of the
> project
> > > one
> > > > needs to specify '-p1' option for patch commands. However if you are
> > > using 'git
> > > > format-patch' for patch creation then simple 'git am' should be
> > > sufficient
> > > > assuming the patch doesn't have any conflicts.
> > > >
> > > > I don't believe patch size might be an issue, but would love to be
> > > pointed out
> > > > to the next trouble shall it happens.
> > > >
> > > > --
> > > > Take care,
> > > > Cos
> > > >
> > >
> >
> >
> >
> > --
> > Alexey Kuznetsov
> > GridGain Systems
> > www.gridgain.com
>
--
Alexey Kuznetsov
GridGain Systems
www.gridgain.com
Re: Patch validation on TC
Posted by Konstantin Boudnik <co...@apache.org>.
Alexey,
not picking up on you - just was working with this ticket hence the example.
Did you rebase your branch on top of origin/sprint-2 before generating the
patch? Ie
git rebase origin/sprint-2
possibly followed conflict resolving...
Thanks,
Cos
On Sat, Feb 28, 2015 at 02:46PM, Alexey Kuznetsov wrote:
> IGNITE-187 was fixed by me.
> I created patch as: git format-patch origin/sprint-2 --stdout >
> ignite-187.patch
>
> On Sat, Feb 28, 2015 at 2:34 PM, Konstantin Boudnik <co...@apache.org> wrote:
>
> > Looks like I have stepped on (the same?) issue that everybody else. I have
> > checked out the repo;
> >
> > % git clone --depth 1
> > https://git1-us-west.apache.org/repos/asf/incubator-ignite.git
> > % gco -b spint-2 origin/sprint-2
> > % git am ../IGNITE-187.patch
> >
> > and got this
> > Applying: IGNITE-187 Refactoring of node attributes.
> > error: patch failed:
> > modules/core/src/main/java/org/apache/ignite/internal/GridKernalContext.java:500
> > error:
> > modules/core/src/main/java/org/apache/ignite/internal/GridKernalContext.java:
> > patch does not apply
> > Patch failed at 0001 IGNITE-187 Refactoring of node attributes.
> > When you have resolved this problem run "git am --resolved".
> > If you would prefer to skip this patch, instead run "git am --skip".
> > To restore the original branch and stop patching run "git am --abort".
> >
> > Now, I'd like to figure out a couple of things, so I can move forward:
> > - how the patches are prepared: what is the _exact_ command being used
> > - are they cut after dev. branch is rebased over current integration
> > branch, sprint-2 I presume?
> > - is anyone else is seeng the same issues?
> >
> > Appreciate the input as it will help me to move forward with patch
> > validation. Thanks
> > Cos
> >
> > On Wed, Feb 25, 2015 at 06:51AM, Konstantin Boudnik wrote:
> > >
> > > Dmitriy just mentioned to me that there some issues with patch
> > application. I'd
> > > happy to help if someone explains to me what seems to be the problem.
> > Are the
> > > issues arising because the patch has conflicts? Cause it might be a bit
> > > difficult to resolve such conflicts: using git or svn merge is usually a
> > way
> > > more friendly. But the hurdle can be overcome using IDEA or similar
> > systems.
> > >
> > > One of the recipes for troubles is when patch is generated and then
> > applied
> > > with different prefix depth. E.g. git diff usually does something like
> > > a/file
> > > b/file
> > > When such patch is applied from the top-level directory of the project
> > one
> > > needs to specify '-p1' option for patch commands. However if you are
> > using 'git
> > > format-patch' for patch creation then simple 'git am' should be
> > sufficient
> > > assuming the patch doesn't have any conflicts.
> > >
> > > I don't believe patch size might be an issue, but would love to be
> > pointed out
> > > to the next trouble shall it happens.
> > >
> > > --
> > > Take care,
> > > Cos
> > >
> >
>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
Re: Patch validation on TC
Posted by Alexey Kuznetsov <ak...@gridgain.com>.
IGNITE-187 was fixed by me.
I created patch as: git format-patch origin/sprint-2 --stdout >
ignite-187.patch
On Sat, Feb 28, 2015 at 2:34 PM, Konstantin Boudnik <co...@apache.org> wrote:
> Looks like I have stepped on (the same?) issue that everybody else. I have
> checked out the repo;
>
> % git clone --depth 1
> https://git1-us-west.apache.org/repos/asf/incubator-ignite.git
> % gco -b spint-2 origin/sprint-2
> % git am ../IGNITE-187.patch
>
> and got this
> Applying: IGNITE-187 Refactoring of node attributes.
> error: patch failed:
> modules/core/src/main/java/org/apache/ignite/internal/GridKernalContext.java:500
> error:
> modules/core/src/main/java/org/apache/ignite/internal/GridKernalContext.java:
> patch does not apply
> Patch failed at 0001 IGNITE-187 Refactoring of node attributes.
> When you have resolved this problem run "git am --resolved".
> If you would prefer to skip this patch, instead run "git am --skip".
> To restore the original branch and stop patching run "git am --abort".
>
> Now, I'd like to figure out a couple of things, so I can move forward:
> - how the patches are prepared: what is the _exact_ command being used
> - are they cut after dev. branch is rebased over current integration
> branch, sprint-2 I presume?
> - is anyone else is seeng the same issues?
>
> Appreciate the input as it will help me to move forward with patch
> validation. Thanks
> Cos
>
> On Wed, Feb 25, 2015 at 06:51AM, Konstantin Boudnik wrote:
> >
> > Dmitriy just mentioned to me that there some issues with patch
> application. I'd
> > happy to help if someone explains to me what seems to be the problem.
> Are the
> > issues arising because the patch has conflicts? Cause it might be a bit
> > difficult to resolve such conflicts: using git or svn merge is usually a
> way
> > more friendly. But the hurdle can be overcome using IDEA or similar
> systems.
> >
> > One of the recipes for troubles is when patch is generated and then
> applied
> > with different prefix depth. E.g. git diff usually does something like
> > a/file
> > b/file
> > When such patch is applied from the top-level directory of the project
> one
> > needs to specify '-p1' option for patch commands. However if you are
> using 'git
> > format-patch' for patch creation then simple 'git am' should be
> sufficient
> > assuming the patch doesn't have any conflicts.
> >
> > I don't believe patch size might be an issue, but would love to be
> pointed out
> > to the next trouble shall it happens.
> >
> > --
> > Take care,
> > Cos
> >
>
--
Alexey Kuznetsov
GridGain Systems
www.gridgain.com
Re: Patch validation on TC
Posted by Konstantin Boudnik <co...@apache.org>.
Looks like I have stepped on (the same?) issue that everybody else. I have
checked out the repo;
% git clone --depth 1 https://git1-us-west.apache.org/repos/asf/incubator-ignite.git
% gco -b spint-2 origin/sprint-2
% git am ../IGNITE-187.patch
and got this
Applying: IGNITE-187 Refactoring of node attributes.
error: patch failed: modules/core/src/main/java/org/apache/ignite/internal/GridKernalContext.java:500
error: modules/core/src/main/java/org/apache/ignite/internal/GridKernalContext.java: patch does not apply
Patch failed at 0001 IGNITE-187 Refactoring of node attributes.
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
Now, I'd like to figure out a couple of things, so I can move forward:
- how the patches are prepared: what is the _exact_ command being used
- are they cut after dev. branch is rebased over current integration branch, sprint-2 I presume?
- is anyone else is seeng the same issues?
Appreciate the input as it will help me to move forward with patch validation. Thanks
Cos
On Wed, Feb 25, 2015 at 06:51AM, Konstantin Boudnik wrote:
>
> Dmitriy just mentioned to me that there some issues with patch application. I'd
> happy to help if someone explains to me what seems to be the problem. Are the
> issues arising because the patch has conflicts? Cause it might be a bit
> difficult to resolve such conflicts: using git or svn merge is usually a way
> more friendly. But the hurdle can be overcome using IDEA or similar systems.
>
> One of the recipes for troubles is when patch is generated and then applied
> with different prefix depth. E.g. git diff usually does something like
> a/file
> b/file
> When such patch is applied from the top-level directory of the project one
> needs to specify '-p1' option for patch commands. However if you are using 'git
> format-patch' for patch creation then simple 'git am' should be sufficient
> assuming the patch doesn't have any conflicts.
>
> I don't believe patch size might be an issue, but would love to be pointed out
> to the next trouble shall it happens.
>
> --
> Take care,
> Cos
>