IGNITE-1217 TC triggering by github pull-requests
Locked
12
12
IGNITE-1217 TC triggering by github pull-requests
 
|
Igniters,
I'm working on https://issues.apache.org/jira/browse/IGNITE-1217. Currently, everyone can fork Mirror of Apache Ignite on GitHub ( https://github.com/apache/incubator-ignite), works with own fork (create branches, commit, pull changes at fork) and then creates a pull-request to Mirror of Apache Ignite on GitHub (all changes should be done in one commit as in patch-way approach). Then test TC builds will triggered automatically. Results can be found by branch filtering by pattern <pull-request-number>/merge. "Merge" suffix here means pull-request merged with master branch (if pull-request at master branch). Notes: 1. I tried to use TC plugin for github to see TC result at pull-request. But the plugin works in unexpected way and add comments not only to pull-requests. Example: https://github.com/apache/incubator-ignite/commit/ae11e9b5aa9af4d0d58e2a16dd3a3331969961df#commitcomment-12635375 . Maybe someone had this problem before? 2. I'm looking for a simple way to add information about new pull-request to associated jira. The better way to use existing Jira plugin for it - DVCS plugin ( https://confluence.atlassian.com/display/BITBUCKET/Linking+Bitbucket+and+GitHub+accounts+to+JIRA). But I need both: Jira administration rights to configure the plugin and GitHub password for "apache" user. Or I missed something and we can't use this plugin at Apache infrastructure? Maybe someone can suggest another solution? Thanks, Artem. |
Re: IGNITE-1217 TC triggering by github pull-requests
|
|
And one more question. Is it mandatory to have possibility works via
patches if we will have pull-request way for contributions? I'd like to have only one approach. -- Artem -- On Tue, Aug 11, 2015 at 4:15 PM, Artem Shutak <[hidden email]> wrote: > Igniters, > > I'm working on https://issues.apache.org/jira/browse/IGNITE-1217. > > Currently, everyone can fork Mirror of Apache Ignite on GitHub ( > https://github.com/apache/incubator-ignite), works with own fork (create > branches, commit, pull changes at fork) and then creates a pull-request to > Mirror of Apache Ignite on GitHub (all changes should be done in one commit > as in patch-way approach). Then test TC builds will triggered > automatically. Results can be found by branch filtering by pattern > <pull-request-number>/merge. "Merge" suffix here means pull-request merged > with master branch (if pull-request at master branch). > > Notes: > > 1. I tried to use TC plugin for github to see TC result at pull-request. > But the plugin works in unexpected way and add comments not only to > pull-requests. Example: > https://github.com/apache/incubator-ignite/commit/ae11e9b5aa9af4d0d58e2a16dd3a3331969961df#commitcomment-12635375 > . > Maybe someone had this problem before? > > 2. I'm looking for a simple way to add information about new pull-request > to associated jira. > The better way to use existing Jira plugin for it - DVCS plugin ( > https://confluence.atlassian.com/display/BITBUCKET/Linking+Bitbucket+and+GitHub+accounts+to+JIRA). > But I need both: Jira administration rights to configure the plugin and > GitHub password for "apache" user. Or I missed something and we can't use > this plugin at Apache infrastructure? > Maybe someone can suggest another solution? > > Thanks, > Artem. > |
Re: IGNITE-1217 TC triggering by github pull-requests
|
On Tue, Aug 11, 2015 at 6:28 AM, Artem Shutak <[hidden email]> wrote:
> And one more question. Is it mandatory to have possibility works via > patches if we will have pull-request way for contributions? > > I'd like to have only one approach. > Artem, if possible I would allow 2 approaches and document the 2 approaches on Wiki. One question, does a pull request automatically generate a Jira comment (see Spark, Camel)? > > -- Artem -- > > On Tue, Aug 11, 2015 at 4:15 PM, Artem Shutak <[hidden email]> > wrote: > > > Igniters, > > > > I'm working on https://issues.apache.org/jira/browse/IGNITE-1217. > > > > Currently, everyone can fork Mirror of Apache Ignite on GitHub ( > > https://github.com/apache/incubator-ignite), works with own fork (create > > branches, commit, pull changes at fork) and then creates a pull-request > to > > Mirror of Apache Ignite on GitHub (all changes should be done in one > commit > > as in patch-way approach). Then test TC builds will triggered > > automatically. Results can be found by branch filtering by pattern > > <pull-request-number>/merge. "Merge" suffix here means pull-request > merged > > with master branch (if pull-request at master branch). > > > > Notes: > > > > 1. I tried to use TC plugin for github to see TC result at pull-request. > > But the plugin works in unexpected way and add comments not only to > > pull-requests. Example: > > > https://github.com/apache/incubator-ignite/commit/ae11e9b5aa9af4d0d58e2a16dd3a3331969961df#commitcomment-12635375 > > . > > Maybe someone had this problem before? > > > > 2. I'm looking for a simple way to add information about new pull-request > > to associated jira. > > The better way to use existing Jira plugin for it - DVCS plugin ( > > > https://confluence.atlassian.com/display/BITBUCKET/Linking+Bitbucket+and+GitHub+accounts+to+JIRA > ). > > But I need both: Jira administration rights to configure the plugin and > > GitHub password for "apache" user. Or I missed something and we can't use > > this plugin at Apache infrastructure? > > Maybe someone can suggest another solution? > > > > Thanks, > > Artem. > > > |
Re: IGNITE-1217 TC triggering by github pull-requests
|
|
Inline.
On Wed, Aug 12, 2015 at 10:19 AM, Dmitriy Setrakyan <[hidden email]> wrote: > On Tue, Aug 11, 2015 at 6:28 AM, Artem Shutak <[hidden email]> > wrote: > > > And one more question. Is it mandatory to have possibility works via > > patches if we will have pull-request way for contributions? > > > > I'd like to have only one approach. > > > > Artem, if possible I would allow 2 approaches and document the 2 approaches > on Wiki. > At least it increases support efforts. And if all will use only one, then there is a big chance that second will not work properly. And, to complete patch-way: - need to split simple "master" builds and "patch" builds on TC - I can do it by yourself. - need to implement git-format-patch.bat for Windows users. It's not mandatory, all can be done manually by contributors, but it would be nice. This script can make any Windows user (I'm not :) ). > > One question, does a pull request automatically generate a Jira comment > (see Spark, Camel)? > I will look at mentioned projects. From my view, by default, GitHub know nothing about our Jira. So, there's no way to GitHub can add any comments to unknown Jira. DVCS plugin - it's a standard way to acquaint Jira and GitHub and it will work pretty nice. --Artem-- > > > > > > -- Artem -- > > > > On Tue, Aug 11, 2015 at 4:15 PM, Artem Shutak <[hidden email]> > > wrote: > > > > > Igniters, > > > > > > I'm working on https://issues.apache.org/jira/browse/IGNITE-1217. > > > > > > Currently, everyone can fork Mirror of Apache Ignite on GitHub ( > > > https://github.com/apache/incubator-ignite), works with own fork > (create > > > branches, commit, pull changes at fork) and then creates a pull-request > > to > > > Mirror of Apache Ignite on GitHub (all changes should be done in one > > commit > > > as in patch-way approach). Then test TC builds will triggered > > > automatically. Results can be found by branch filtering by pattern > > > <pull-request-number>/merge. "Merge" suffix here means pull-request > > merged > > > with master branch (if pull-request at master branch). > > > > > > Notes: > > > > > > 1. I tried to use TC plugin for github to see TC result at > pull-request. > > > But the plugin works in unexpected way and add comments not only to > > > pull-requests. Example: > > > > > > https://github.com/apache/incubator-ignite/commit/ae11e9b5aa9af4d0d58e2a16dd3a3331969961df#commitcomment-12635375 > > > . > > > Maybe someone had this problem before? > > > > > > 2. I'm looking for a simple way to add information about new > pull-request > > > to associated jira. > > > The better way to use existing Jira plugin for it - DVCS plugin ( > > > > > > https://confluence.atlassian.com/display/BITBUCKET/Linking+Bitbucket+and+GitHub+accounts+to+JIRA > > ). > > > But I need both: Jira administration rights to configure the plugin and > > > GitHub password for "apache" user. Or I missed something and we can't > use > > > this plugin at Apache infrastructure? > > > Maybe someone can suggest another solution? > > > > > > Thanks, > > > Artem. > > > > > > |
Re: IGNITE-1217 TC triggering by github pull-requests
|
|
Maybe I miss a good piece of information about how Git works, but I always
thought that if a pull request is accepted, it will be merged to the GitHub mirror of Apache Ignite. How will this change get to the original Apache git repository? Can somebody explain to me the merge procedure? 2015-08-12 3:15 GMT-07:00 Artem Shutak <[hidden email]>: > Inline. > > On Wed, Aug 12, 2015 at 10:19 AM, Dmitriy Setrakyan <[hidden email] > > > wrote: > > > On Tue, Aug 11, 2015 at 6:28 AM, Artem Shutak <[hidden email]> > > wrote: > > > > > And one more question. Is it mandatory to have possibility works via > > > patches if we will have pull-request way for contributions? > > > > > > I'd like to have only one approach. > > > > > > > Artem, if possible I would allow 2 approaches and document the 2 > approaches > > on Wiki. > > > > At least it increases support efforts. And if all will use only one, then > there is a big chance that second will not work properly. > > And, to complete patch-way: > - need to split simple "master" builds and "patch" builds on TC - I can do > it by yourself. > - need to implement git-format-patch.bat for Windows users. It's not > mandatory, all can be done manually by contributors, but it would be nice. > This script can make any Windows user (I'm not :) ). > > > > > > One question, does a pull request automatically generate a Jira comment > > (see Spark, Camel)? > > > > I will look at mentioned projects. From my view, by default, GitHub know > nothing about our Jira. So, there's no way to GitHub can add any comments > to unknown Jira. > DVCS plugin - it's a standard way to acquaint Jira and GitHub and it will > work pretty nice. > > --Artem-- > > > > > > > > > > > > -- Artem -- > > > > > > On Tue, Aug 11, 2015 at 4:15 PM, Artem Shutak <[hidden email]> > > > wrote: > > > > > > > Igniters, > > > > > > > > I'm working on https://issues.apache.org/jira/browse/IGNITE-1217. > > > > > > > > Currently, everyone can fork Mirror of Apache Ignite on GitHub ( > > > > https://github.com/apache/incubator-ignite), works with own fork > > (create > > > > branches, commit, pull changes at fork) and then creates a > pull-request > > > to > > > > Mirror of Apache Ignite on GitHub (all changes should be done in one > > > commit > > > > as in patch-way approach). Then test TC builds will triggered > > > > automatically. Results can be found by branch filtering by pattern > > > > <pull-request-number>/merge. "Merge" suffix here means pull-request > > > merged > > > > with master branch (if pull-request at master branch). > > > > > > > > Notes: > > > > > > > > 1. I tried to use TC plugin for github to see TC result at > > pull-request. > > > > But the plugin works in unexpected way and add comments not only to > > > > pull-requests. Example: > > > > > > > > > > https://github.com/apache/incubator-ignite/commit/ae11e9b5aa9af4d0d58e2a16dd3a3331969961df#commitcomment-12635375 > > > > . > > > > Maybe someone had this problem before? > > > > > > > > 2. I'm looking for a simple way to add information about new > > pull-request > > > > to associated jira. > > > > The better way to use existing Jira plugin for it - DVCS plugin ( > > > > > > > > > > https://confluence.atlassian.com/display/BITBUCKET/Linking+Bitbucket+and+GitHub+accounts+to+JIRA > > > ). > > > > But I need both: Jira administration rights to configure the plugin > and > > > > GitHub password for "apache" user. Or I missed something and we can't > > use > > > > this plugin at Apache infrastructure? > > > > Maybe someone can suggest another solution? > > > > > > > > Thanks, > > > > Artem. > > > > > > > > > > |
Re: IGNITE-1217 TC triggering by github pull-requests
|
|
On Thu, Aug 13, 2015 at 05:40PM, Alexey Goncharuk wrote:
> Maybe I miss a good piece of information about how Git works, but I always > thought that if a pull request is accepted, it will be merged to the GitHub > mirror of Apache Ignite. How will this change get to the original Apache > git repository? It won't. github repo is a mirror of Apache git mirror. In order to have the changes from github PR to be in visible in the github a committer needs to commit it into our Apache repo. Cos > Can somebody explain to me the merge procedure? > > 2015-08-12 3:15 GMT-07:00 Artem Shutak <[hidden email]>: > > > Inline. > > > > On Wed, Aug 12, 2015 at 10:19 AM, Dmitriy Setrakyan <[hidden email] > > > > > wrote: > > > > > On Tue, Aug 11, 2015 at 6:28 AM, Artem Shutak <[hidden email]> > > > wrote: > > > > > > > And one more question. Is it mandatory to have possibility works via > > > > patches if we will have pull-request way for contributions? > > > > > > > > I'd like to have only one approach. > > > > > > > > > > Artem, if possible I would allow 2 approaches and document the 2 > > approaches > > > on Wiki. > > > > > > > At least it increases support efforts. And if all will use only one, then > > there is a big chance that second will not work properly. > > > > And, to complete patch-way: > > - need to split simple "master" builds and "patch" builds on TC - I can do > > it by yourself. > > - need to implement git-format-patch.bat for Windows users. It's not > > mandatory, all can be done manually by contributors, but it would be nice. > > This script can make any Windows user (I'm not :) ). > > > > > > > > > > One question, does a pull request automatically generate a Jira comment > > > (see Spark, Camel)? > > > > > > > I will look at mentioned projects. From my view, by default, GitHub know > > nothing about our Jira. So, there's no way to GitHub can add any comments > > to unknown Jira. > > DVCS plugin - it's a standard way to acquaint Jira and GitHub and it will > > work pretty nice. > > > > --Artem-- > > > > > > > > > > > > > > > > > > -- Artem -- > > > > > > > > On Tue, Aug 11, 2015 at 4:15 PM, Artem Shutak <[hidden email]> > > > > wrote: > > > > > > > > > Igniters, > > > > > > > > > > I'm working on https://issues.apache.org/jira/browse/IGNITE-1217. > > > > > > > > > > Currently, everyone can fork Mirror of Apache Ignite on GitHub ( > > > > > https://github.com/apache/incubator-ignite), works with own fork > > > (create > > > > > branches, commit, pull changes at fork) and then creates a > > pull-request > > > > to > > > > > Mirror of Apache Ignite on GitHub (all changes should be done in one > > > > commit > > > > > as in patch-way approach). Then test TC builds will triggered > > > > > automatically. Results can be found by branch filtering by pattern > > > > > <pull-request-number>/merge. "Merge" suffix here means pull-request > > > > merged > > > > > with master branch (if pull-request at master branch). > > > > > > > > > > Notes: > > > > > > > > > > 1. I tried to use TC plugin for github to see TC result at > > > pull-request. > > > > > But the plugin works in unexpected way and add comments not only to > > > > > pull-requests. Example: > > > > > > > > > > > > > > https://github.com/apache/incubator-ignite/commit/ae11e9b5aa9af4d0d58e2a16dd3a3331969961df#commitcomment-12635375 > > > > > . > > > > > Maybe someone had this problem before? > > > > > > > > > > 2. I'm looking for a simple way to add information about new > > > pull-request > > > > > to associated jira. > > > > > The better way to use existing Jira plugin for it - DVCS plugin ( > > > > > > > > > > > > > > https://confluence.atlassian.com/display/BITBUCKET/Linking+Bitbucket+and+GitHub+accounts+to+JIRA > > > > ). > > > > > But I need both: Jira administration rights to configure the plugin > > and > > > > > GitHub password for "apache" user. Or I missed something and we can't > > > use > > > > > this plugin at Apache infrastructure? > > > > > Maybe someone can suggest another solution? > > > > > > > > > > Thanks, > > > > > Artem. > > > > > > > > > > > > > > |
Re: IGNITE-1217 TC triggering by github pull-requests
|
|
On Thu, Aug 13, 2015 at 5:51 PM, Konstantin Boudnik <[hidden email]> wrote:
> On Thu, Aug 13, 2015 at 05:40PM, Alexey Goncharuk wrote: > > Maybe I miss a good piece of information about how Git works, but I > always > > thought that if a pull request is accepted, it will be merged to the > GitHub > > mirror of Apache Ignite. How will this change get to the original Apache > > git repository? > > It won't. github repo is a mirror of Apache git mirror. In order to have > the > changes from github PR to be in visible in the github a committer needs to > commit it into our Apache repo. > Cos, will the original contributor's name be preserved or should the Ignite committer add "-author" parameter when committing? > > Cos > > > Can somebody explain to me the merge procedure? > > > > 2015-08-12 3:15 GMT-07:00 Artem Shutak <[hidden email]>: > > > > > Inline. > > > > > > On Wed, Aug 12, 2015 at 10:19 AM, Dmitriy Setrakyan < > [hidden email] > > > > > > > wrote: > > > > > > > On Tue, Aug 11, 2015 at 6:28 AM, Artem Shutak <[hidden email]> > > > > wrote: > > > > > > > > > And one more question. Is it mandatory to have possibility works > via > > > > > patches if we will have pull-request way for contributions? > > > > > > > > > > I'd like to have only one approach. > > > > > > > > > > > > > Artem, if possible I would allow 2 approaches and document the 2 > > > approaches > > > > on Wiki. > > > > > > > > > > At least it increases support efforts. And if all will use only one, > then > > > there is a big chance that second will not work properly. > > > > > > And, to complete patch-way: > > > - need to split simple "master" builds and "patch" builds on TC - I > can do > > > it by yourself. > > > - need to implement git-format-patch.bat for Windows users. It's not > > > mandatory, all can be done manually by contributors, but it would be > nice. > > > This script can make any Windows user (I'm not :) ). > > > > > > > > > > > > > > One question, does a pull request automatically generate a Jira > comment > > > > (see Spark, Camel)? > > > > > > > > > > I will look at mentioned projects. From my view, by default, GitHub > know > > > nothing about our Jira. So, there's no way to GitHub can add any > comments > > > to unknown Jira. > > > DVCS plugin - it's a standard way to acquaint Jira and GitHub and it > will > > > work pretty nice. > > > > > > --Artem-- > > > > > > > > > > > > > > > > > > > > > > > > -- Artem -- > > > > > > > > > > On Tue, Aug 11, 2015 at 4:15 PM, Artem Shutak < > [hidden email]> > > > > > wrote: > > > > > > > > > > > Igniters, > > > > > > > > > > > > I'm working on https://issues.apache.org/jira/browse/IGNITE-1217 > . > > > > > > > > > > > > Currently, everyone can fork Mirror of Apache Ignite on GitHub ( > > > > > > https://github.com/apache/incubator-ignite), works with own fork > > > > (create > > > > > > branches, commit, pull changes at fork) and then creates a > > > pull-request > > > > > to > > > > > > Mirror of Apache Ignite on GitHub (all changes should be done in > one > > > > > commit > > > > > > as in patch-way approach). Then test TC builds will triggered > > > > > > automatically. Results can be found by branch filtering by > pattern > > > > > > <pull-request-number>/merge. "Merge" suffix here means > pull-request > > > > > merged > > > > > > with master branch (if pull-request at master branch). > > > > > > > > > > > > Notes: > > > > > > > > > > > > 1. I tried to use TC plugin for github to see TC result at > > > > pull-request. > > > > > > But the plugin works in unexpected way and add comments not only > to > > > > > > pull-requests. Example: > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-ignite/commit/ae11e9b5aa9af4d0d58e2a16dd3a3331969961df#commitcomment-12635375 > > > > > > . > > > > > > Maybe someone had this problem before? > > > > > > > > > > > > 2. I'm looking for a simple way to add information about new > > > > pull-request > > > > > > to associated jira. > > > > > > The better way to use existing Jira plugin for it - DVCS plugin ( > > > > > > > > > > > > > > > > > > > https://confluence.atlassian.com/display/BITBUCKET/Linking+Bitbucket+and+GitHub+accounts+to+JIRA > > > > > ). > > > > > > But I need both: Jira administration rights to configure the > plugin > > > and > > > > > > GitHub password for "apache" user. Or I missed something and we > can't > > > > use > > > > > > this plugin at Apache infrastructure? > > > > > > Maybe someone can suggest another solution? > > > > > > > > > > > > Thanks, > > > > > > Artem. > > > > > > > > > > > > > > > > > > > |
Re: IGNITE-1217 TC triggering by github pull-requests
|
|
On Thu, Aug 13, 2015 at 05:54PM, Dmitriy Setrakyan wrote:
> On Thu, Aug 13, 2015 at 5:51 PM, Konstantin Boudnik <[hidden email]> wrote: > > > On Thu, Aug 13, 2015 at 05:40PM, Alexey Goncharuk wrote: > > > Maybe I miss a good piece of information about how Git works, but I > > always > > > thought that if a pull request is accepted, it will be merged to the > > GitHub > > > mirror of Apache Ignite. How will this change get to the original Apache > > > git repository? > > > > It won't. github repo is a mirror of Apache git mirror. In order to have > > the > > changes from github PR to be in visible in the github a committer needs to > > commit it into our Apache repo. > > > > Cos, will the original contributor's name be preserved or should the Ignite > committer add "-author" parameter when committing? It depends on how the patch file was made. If 'git format-patch' was used then the name will be preserved. Otherwise, it won't. Sorry, I don't know much about github and I really am not using it. Cos > > > Can somebody explain to me the merge procedure? > > > > > > 2015-08-12 3:15 GMT-07:00 Artem Shutak <[hidden email]>: > > > > > > > Inline. > > > > > > > > On Wed, Aug 12, 2015 at 10:19 AM, Dmitriy Setrakyan < > > [hidden email] > > > > > > > > > wrote: > > > > > > > > > On Tue, Aug 11, 2015 at 6:28 AM, Artem Shutak <[hidden email]> > > > > > wrote: > > > > > > > > > > > And one more question. Is it mandatory to have possibility works > > via > > > > > > patches if we will have pull-request way for contributions? > > > > > > > > > > > > I'd like to have only one approach. > > > > > > > > > > > > > > > > Artem, if possible I would allow 2 approaches and document the 2 > > > > approaches > > > > > on Wiki. > > > > > > > > > > > > > At least it increases support efforts. And if all will use only one, > > then > > > > there is a big chance that second will not work properly. > > > > > > > > And, to complete patch-way: > > > > - need to split simple "master" builds and "patch" builds on TC - I > > can do > > > > it by yourself. > > > > - need to implement git-format-patch.bat for Windows users. It's not > > > > mandatory, all can be done manually by contributors, but it would be > > nice. > > > > This script can make any Windows user (I'm not :) ). > > > > > > > > > > > > > > > > > > One question, does a pull request automatically generate a Jira > > comment > > > > > (see Spark, Camel)? > > > > > > > > > > > > > I will look at mentioned projects. From my view, by default, GitHub > > know > > > > nothing about our Jira. So, there's no way to GitHub can add any > > comments > > > > to unknown Jira. > > > > DVCS plugin - it's a standard way to acquaint Jira and GitHub and it > > will > > > > work pretty nice. > > > > > > > > --Artem-- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Artem -- > > > > > > > > > > > > On Tue, Aug 11, 2015 at 4:15 PM, Artem Shutak < > > [hidden email]> > > > > > > wrote: > > > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > I'm working on https://issues.apache.org/jira/browse/IGNITE-1217 > > . > > > > > > > > > > > > > > Currently, everyone can fork Mirror of Apache Ignite on GitHub ( > > > > > > > https://github.com/apache/incubator-ignite), works with own fork > > > > > (create > > > > > > > branches, commit, pull changes at fork) and then creates a > > > > pull-request > > > > > > to > > > > > > > Mirror of Apache Ignite on GitHub (all changes should be done in > > one > > > > > > commit > > > > > > > as in patch-way approach). Then test TC builds will triggered > > > > > > > automatically. Results can be found by branch filtering by > > pattern > > > > > > > <pull-request-number>/merge. "Merge" suffix here means > > pull-request > > > > > > merged > > > > > > > with master branch (if pull-request at master branch). > > > > > > > > > > > > > > Notes: > > > > > > > > > > > > > > 1. I tried to use TC plugin for github to see TC result at > > > > > pull-request. > > > > > > > But the plugin works in unexpected way and add comments not only > > to > > > > > > > pull-requests. Example: > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-ignite/commit/ae11e9b5aa9af4d0d58e2a16dd3a3331969961df#commitcomment-12635375 > > > > > > > . > > > > > > > Maybe someone had this problem before? > > > > > > > > > > > > > > 2. I'm looking for a simple way to add information about new > > > > > pull-request > > > > > > > to associated jira. > > > > > > > The better way to use existing Jira plugin for it - DVCS plugin ( > > > > > > > > > > > > > > > > > > > > > > > > https://confluence.atlassian.com/display/BITBUCKET/Linking+Bitbucket+and+GitHub+accounts+to+JIRA > > > > > > ). > > > > > > > But I need both: Jira administration rights to configure the > > plugin > > > > and > > > > > > > GitHub password for "apache" user. Or I missed something and we > > can't > > > > > use > > > > > > > this plugin at Apache infrastructure? > > > > > > > Maybe someone can suggest another solution? > > > > > > > > > > > > > > Thanks, > > > > > > > Artem. > > > > > > > > > > > > > > > > > > > > > > > > |
Re: IGNITE-1217 TC triggering by github pull-requests
|
|
While the process of a pull-request creation and CI run is clear for, the
whole cycle from start to end is still fuzzy. Let me summarize my understanding and correct me if I got something wrong. For any committer/contributor John Doe we will have the following structure: +------------+ +---------------+ +-----------------+ | | replica | | fork | | | Apache Git | ==========> | GitHub Mirror | ---------> | John Doe's Fork | | | | | | | +------------+ +---------------+ +-----------------+ ^ ^ | | | | | +-----------------+ | *Apache Git remote handle for committers* | | +------------------------------------------------| Local clone | | | +-----------------+ Development is going in the JD's fork and at some point he thinks that the feature is ready to be tested by CI. He creates a pull request. Usually it takes more than one iteration to have a successful CI run, but each pull request sends an e-mail to the dev list. I think we should have some mechanism allowing to differentiate "work" pull requests and final pull requests that passed CI and should be reviewed by a committer. We also need to create (maybe) a maven profile with a set of quick tests that cover as much functionality as possible, so that a developer could run it locally before submitting a request to the CI. Let's say now the pull request is approved. If the pull request was submitted by a contributor, a committer should pull it to it's local clone. Then commit is pushed to the apache git repository. I glanced through the Apache Spark development process document [1] and it seems that we should have a similar script that will properly process commits (squash or whatever we need) before the push. Assuming my understanding is correct and the minor things I mentioned above are addressed, I like the new process :) [1] https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark 2015-08-13 18:13 GMT-07:00 Konstantin Boudnik <[hidden email]>: > On Thu, Aug 13, 2015 at 05:54PM, Dmitriy Setrakyan wrote: > > On Thu, Aug 13, 2015 at 5:51 PM, Konstantin Boudnik <[hidden email]> > wrote: > > > > > On Thu, Aug 13, 2015 at 05:40PM, Alexey Goncharuk wrote: > > > > Maybe I miss a good piece of information about how Git works, but I > > > always > > > > thought that if a pull request is accepted, it will be merged to the > > > GitHub > > > > mirror of Apache Ignite. How will this change get to the original > Apache > > > > git repository? > > > > > > It won't. github repo is a mirror of Apache git mirror. In order to > have > > > the > > > changes from github PR to be in visible in the github a committer > needs to > > > commit it into our Apache repo. > > > > > > > Cos, will the original contributor's name be preserved or should the > Ignite > > committer add "-author" parameter when committing? > > It depends on how the patch file was made. If 'git format-patch' was used > then > the name will be preserved. Otherwise, it won't. Sorry, I don't know much > about github and I really am not using it. > > Cos > > > > > Can somebody explain to me the merge procedure? > > > > > > > > 2015-08-12 3:15 GMT-07:00 Artem Shutak <[hidden email]>: > > > > > > > > > Inline. > > > > > > > > > > On Wed, Aug 12, 2015 at 10:19 AM, Dmitriy Setrakyan < > > > [hidden email] > > > > > > > > > > > wrote: > > > > > > > > > > > On Tue, Aug 11, 2015 at 6:28 AM, Artem Shutak < > [hidden email]> > > > > > > wrote: > > > > > > > > > > > > > And one more question. Is it mandatory to have possibility > works > > > via > > > > > > > patches if we will have pull-request way for contributions? > > > > > > > > > > > > > > I'd like to have only one approach. > > > > > > > > > > > > > > > > > > > Artem, if possible I would allow 2 approaches and document the 2 > > > > > approaches > > > > > > on Wiki. > > > > > > > > > > > > > > > > At least it increases support efforts. And if all will use only > one, > > > then > > > > > there is a big chance that second will not work properly. > > > > > > > > > > And, to complete patch-way: > > > > > - need to split simple "master" builds and "patch" builds on TC - I > > > can do > > > > > it by yourself. > > > > > - need to implement git-format-patch.bat for Windows users. It's > not > > > > > mandatory, all can be done manually by contributors, but it would > be > > > nice. > > > > > This script can make any Windows user (I'm not :) ). > > > > > > > > > > > > > > > > > > > > > > One question, does a pull request automatically generate a Jira > > > comment > > > > > > (see Spark, Camel)? > > > > > > > > > > > > > > > > I will look at mentioned projects. From my view, by default, GitHub > > > know > > > > > nothing about our Jira. So, there's no way to GitHub can add any > > > comments > > > > > to unknown Jira. > > > > > DVCS plugin - it's a standard way to acquaint Jira and GitHub and > it > > > will > > > > > work pretty nice. > > > > > > > > > > --Artem-- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Artem -- > > > > > > > > > > > > > > On Tue, Aug 11, 2015 at 4:15 PM, Artem Shutak < > > > [hidden email]> > > > > > > > wrote: > > > > > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > > > I'm working on > https://issues.apache.org/jira/browse/IGNITE-1217 > > > . > > > > > > > > > > > > > > > > Currently, everyone can fork Mirror of Apache Ignite on > GitHub ( > > > > > > > > https://github.com/apache/incubator-ignite), works with own > fork > > > > > > (create > > > > > > > > branches, commit, pull changes at fork) and then creates a > > > > > pull-request > > > > > > > to > > > > > > > > Mirror of Apache Ignite on GitHub (all changes should be > done in > > > one > > > > > > > commit > > > > > > > > as in patch-way approach). Then test TC builds will triggered > > > > > > > > automatically. Results can be found by branch filtering by > > > pattern > > > > > > > > <pull-request-number>/merge. "Merge" suffix here means > > > pull-request > > > > > > > merged > > > > > > > > with master branch (if pull-request at master branch). > > > > > > > > > > > > > > > > Notes: > > > > > > > > > > > > > > > > 1. I tried to use TC plugin for github to see TC result at > > > > > > pull-request. > > > > > > > > But the plugin works in unexpected way and add comments not > only > > > to > > > > > > > > pull-requests. Example: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-ignite/commit/ae11e9b5aa9af4d0d58e2a16dd3a3331969961df#commitcomment-12635375 > > > > > > > > . > > > > > > > > Maybe someone had this problem before? > > > > > > > > > > > > > > > > 2. I'm looking for a simple way to add information about new > > > > > > pull-request > > > > > > > > to associated jira. > > > > > > > > The better way to use existing Jira plugin for it - DVCS > plugin ( > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://confluence.atlassian.com/display/BITBUCKET/Linking+Bitbucket+and+GitHub+accounts+to+JIRA > > > > > > > ). > > > > > > > > But I need both: Jira administration rights to configure the > > > plugin > > > > > and > > > > > > > > GitHub password for "apache" user. Or I missed something and > we > > > can't > > > > > > use > > > > > > > > this plugin at Apache infrastructure? > > > > > > > > Maybe someone can suggest another solution? > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Artem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |
Re: IGNITE-1217 TC triggering by github pull-requests
|
|
I forgot that the mailing list takes out all formatting, the diagram meant
to be in a monospaced font :) I added it to Ignite wiki: https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute 2015-08-13 19:22 GMT-07:00 Alexey Goncharuk <[hidden email]>: > While the process of a pull-request creation and CI run is clear for, the > whole cycle from start to end is still fuzzy. Let me summarize my > understanding and correct me if I got something wrong. > > For any committer/contributor John Doe we will have the following > structure: > > +------------+ +---------------+ > +-----------------+ > | | replica | | fork | > | > | Apache Git | ==========> | GitHub Mirror | ---------> | John Doe's Fork > | > | | | | | > | > +------------+ +---------------+ > +-----------------+ > ^ ^ > | | > | | > | > +-----------------+ > | *Apache Git remote handle for committers* | > | > +------------------------------------------------| Local clone > | > | > | > > +-----------------+ > Development is going in the JD's fork and at some point he thinks that the > feature is ready to be tested by CI. > > He creates a pull request. Usually it takes more than one iteration to > have a successful CI run, but each pull request sends an e-mail to the dev > list. I think we should have some mechanism allowing to differentiate > "work" pull requests and final pull requests that passed CI and should be > reviewed by a committer. We also need to create (maybe) a maven profile > with a set of quick tests that cover as much functionality as possible, so > that a developer could run it locally before submitting a request to the CI. > > Let's say now the pull request is approved. If the pull request was > submitted by a contributor, a committer should pull it to it's local clone. > Then commit is pushed to the apache git repository. I glanced through the > Apache Spark development process document [1] and it seems that we should > have a similar script that will properly process commits (squash or > whatever we need) before the push. > > Assuming my understanding is correct and the minor things I mentioned > above are addressed, I like the new process :) > > [1] > https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark > > > 2015-08-13 18:13 GMT-07:00 Konstantin Boudnik <[hidden email]>: > >> On Thu, Aug 13, 2015 at 05:54PM, Dmitriy Setrakyan wrote: >> > On Thu, Aug 13, 2015 at 5:51 PM, Konstantin Boudnik <[hidden email]> >> wrote: >> > >> > > On Thu, Aug 13, 2015 at 05:40PM, Alexey Goncharuk wrote: >> > > > Maybe I miss a good piece of information about how Git works, but I >> > > always >> > > > thought that if a pull request is accepted, it will be merged to the >> > > GitHub >> > > > mirror of Apache Ignite. How will this change get to the original >> Apache >> > > > git repository? >> > > >> > > It won't. github repo is a mirror of Apache git mirror. In order to >> have >> > > the >> > > changes from github PR to be in visible in the github a committer >> needs to >> > > commit it into our Apache repo. >> > > >> > >> > Cos, will the original contributor's name be preserved or should the >> Ignite >> > committer add "-author" parameter when committing? >> >> It depends on how the patch file was made. If 'git format-patch' was used >> then >> the name will be preserved. Otherwise, it won't. Sorry, I don't know much >> about github and I really am not using it. >> >> Cos >> >> > > > Can somebody explain to me the merge procedure? >> > > > >> > > > 2015-08-12 3:15 GMT-07:00 Artem Shutak <[hidden email]>: >> > > > >> > > > > Inline. >> > > > > >> > > > > On Wed, Aug 12, 2015 at 10:19 AM, Dmitriy Setrakyan < >> > > [hidden email] >> > > > > > >> > > > > wrote: >> > > > > >> > > > > > On Tue, Aug 11, 2015 at 6:28 AM, Artem Shutak < >> [hidden email]> >> > > > > > wrote: >> > > > > > >> > > > > > > And one more question. Is it mandatory to have possibility >> works >> > > via >> > > > > > > patches if we will have pull-request way for contributions? >> > > > > > > >> > > > > > > I'd like to have only one approach. >> > > > > > > >> > > > > > >> > > > > > Artem, if possible I would allow 2 approaches and document the 2 >> > > > > approaches >> > > > > > on Wiki. >> > > > > > >> > > > > >> > > > > At least it increases support efforts. And if all will use only >> one, >> > > then >> > > > > there is a big chance that second will not work properly. >> > > > > >> > > > > And, to complete patch-way: >> > > > > - need to split simple "master" builds and "patch" builds on TC - >> I >> > > can do >> > > > > it by yourself. >> > > > > - need to implement git-format-patch.bat for Windows users. It's >> not >> > > > > mandatory, all can be done manually by contributors, but it would >> be >> > > nice. >> > > > > This script can make any Windows user (I'm not :) ). >> > > > > >> > > > > >> > > > > > >> > > > > > One question, does a pull request automatically generate a Jira >> > > comment >> > > > > > (see Spark, Camel)? >> > > > > > >> > > > > >> > > > > I will look at mentioned projects. From my view, by default, >> GitHub >> > > know >> > > > > nothing about our Jira. So, there's no way to GitHub can add any >> > > comments >> > > > > to unknown Jira. >> > > > > DVCS plugin - it's a standard way to acquaint Jira and GitHub and >> it >> > > will >> > > > > work pretty nice. >> > > > > >> > > > > --Artem-- >> > > > > >> > > > > >> > > > > > >> > > > > > >> > > > > > > >> > > > > > > -- Artem -- >> > > > > > > >> > > > > > > On Tue, Aug 11, 2015 at 4:15 PM, Artem Shutak < >> > > [hidden email]> >> > > > > > > wrote: >> > > > > > > >> > > > > > > > Igniters, >> > > > > > > > >> > > > > > > > I'm working on >> https://issues.apache.org/jira/browse/IGNITE-1217 >> > > . >> > > > > > > > >> > > > > > > > Currently, everyone can fork Mirror of Apache Ignite on >> GitHub ( >> > > > > > > > https://github.com/apache/incubator-ignite), works with >> own fork >> > > > > > (create >> > > > > > > > branches, commit, pull changes at fork) and then creates a >> > > > > pull-request >> > > > > > > to >> > > > > > > > Mirror of Apache Ignite on GitHub (all changes should be >> done in >> > > one >> > > > > > > commit >> > > > > > > > as in patch-way approach). Then test TC builds will >> triggered >> > > > > > > > automatically. Results can be found by branch filtering by >> > > pattern >> > > > > > > > <pull-request-number>/merge. "Merge" suffix here means >> > > pull-request >> > > > > > > merged >> > > > > > > > with master branch (if pull-request at master branch). >> > > > > > > > >> > > > > > > > Notes: >> > > > > > > > >> > > > > > > > 1. I tried to use TC plugin for github to see TC result at >> > > > > > pull-request. >> > > > > > > > But the plugin works in unexpected way and add comments not >> only >> > > to >> > > > > > > > pull-requests. Example: >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > >> https://github.com/apache/incubator-ignite/commit/ae11e9b5aa9af4d0d58e2a16dd3a3331969961df#commitcomment-12635375 >> > > > > > > > . >> > > > > > > > Maybe someone had this problem before? >> > > > > > > > >> > > > > > > > 2. I'm looking for a simple way to add information about new >> > > > > > pull-request >> > > > > > > > to associated jira. >> > > > > > > > The better way to use existing Jira plugin for it - DVCS >> plugin ( >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > >> https://confluence.atlassian.com/display/BITBUCKET/Linking+Bitbucket+and+GitHub+accounts+to+JIRA >> > > > > > > ). >> > > > > > > > But I need both: Jira administration rights to configure the >> > > plugin >> > > > > and >> > > > > > > > GitHub password for "apache" user. Or I missed something >> and we >> > > can't >> > > > > > use >> > > > > > > > this plugin at Apache infrastructure? >> > > > > > > > Maybe someone can suggest another solution? >> > > > > > > > >> > > > > > > > Thanks, >> > > > > > > > Artem. >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > >> > > |
Re: IGNITE-1217 TC triggering by github pull-requests
|
|
Alexey,
You are right and big thanks for the diagram on the wiki! In bounds of IGNITE-1217 <https://issues.apache.org/jira/browse/IGNITE-1217> I've created a script for commiters (see patch). You need to point to the script a contributor_github_user_name and a branch_name_with_contribution. The script just fetchs a remote repository (by contributor_github_user_name) and cherry-picks last commit from this branch to local master - it stores commit author information. So, the commiter can push master at apache git. In this case we have one requirement: a pull-request should have only one commit (as with patches). I've mention next model of development at fork (see steps below). But now, I see it has too many steps. I will think about more simple way. 1. Preparation (need to configure once): git remote add apache https://git-wip-us.apache.org/repos/asf/incubator-ignite git remote my_fork https://github.com/<github_uname>/incubator-ignite.git 2. Forking on jira ignite-xxxx # Update local master from apache repo git checkout master git pull apache master # Create new development branch for the ticket. git checkout -b ignite-xxxx-dev # Some development here with many commits at ignite-xxxx-dev. git commit -a -m 'ignite-xxxx: Intermediate commit 1' ... git commit -a -m 'ignite-xxxx: Intermediate commit 100' # Push at fork git push my_fork ignite-xxxx-dev Now a pull-request can be created. TC will be triggered. To fix some something and rerun TC, you need just fix it at ignite-xxxx-dev and push to fork again, TC will be triggered again for new commit. When TC is green, it needs to create 'final' pull-request branch with one commit. For it: # Update local master from apache repo git checkout master git pull apache master # Create a final pull-request branch for the ticket. git checkout -b ignite-xxxx # Squash all changes at one commit. git merge --squash ignite-xxxx-dev git commit -a -m 'ignite-xxxx: Implemented' Then need to push it to fork and open new pull-request. -- Artem -- On Fri, Aug 14, 2015 at 5:30 AM, Alexey Goncharuk < [hidden email]> wrote: > I forgot that the mailing list takes out all formatting, the diagram meant > to be in a monospaced font :) > > I added it to Ignite wiki: > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute > > 2015-08-13 19:22 GMT-07:00 Alexey Goncharuk <[hidden email]>: > > > While the process of a pull-request creation and CI run is clear for, the > > whole cycle from start to end is still fuzzy. Let me summarize my > > understanding and correct me if I got something wrong. > > > > For any committer/contributor John Doe we will have the following > > structure: > > > > +------------+ +---------------+ > > +-----------------+ > > | | replica | | fork | > > | > > | Apache Git | ==========> | GitHub Mirror | ---------> | John Doe's > Fork > > | > > | | | | | > > | > > +------------+ +---------------+ > > +-----------------+ > > ^ ^ > > | | > > | | > > | > > +-----------------+ > > | *Apache Git remote handle for committers* | > > | > > +------------------------------------------------| Local clone > > | > > | > > | > > > > +-----------------+ > > Development is going in the JD's fork and at some point he thinks that > the > > feature is ready to be tested by CI. > > > > He creates a pull request. Usually it takes more than one iteration to > > have a successful CI run, but each pull request sends an e-mail to the > dev > > list. I think we should have some mechanism allowing to differentiate > > "work" pull requests and final pull requests that passed CI and should be > > reviewed by a committer. We also need to create (maybe) a maven profile > > with a set of quick tests that cover as much functionality as possible, > so > > that a developer could run it locally before submitting a request to the > CI. > > > > Let's say now the pull request is approved. If the pull request was > > submitted by a contributor, a committer should pull it to it's local > clone. > > Then commit is pushed to the apache git repository. I glanced through the > > Apache Spark development process document [1] and it seems that we should > > have a similar script that will properly process commits (squash or > > whatever we need) before the push. > > > > Assuming my understanding is correct and the minor things I mentioned > > above are addressed, I like the new process :) > > > > [1] > > https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark > > > > > > 2015-08-13 18:13 GMT-07:00 Konstantin Boudnik <[hidden email]>: > > > >> On Thu, Aug 13, 2015 at 05:54PM, Dmitriy Setrakyan wrote: > >> > On Thu, Aug 13, 2015 at 5:51 PM, Konstantin Boudnik <[hidden email]> > >> wrote: > >> > > >> > > On Thu, Aug 13, 2015 at 05:40PM, Alexey Goncharuk wrote: > >> > > > Maybe I miss a good piece of information about how Git works, but > I > >> > > always > >> > > > thought that if a pull request is accepted, it will be merged to > the > >> > > GitHub > >> > > > mirror of Apache Ignite. How will this change get to the original > >> Apache > >> > > > git repository? > >> > > > >> > > It won't. github repo is a mirror of Apache git mirror. In order to > >> have > >> > > the > >> > > changes from github PR to be in visible in the github a committer > >> needs to > >> > > commit it into our Apache repo. > >> > > > >> > > >> > Cos, will the original contributor's name be preserved or should the > >> Ignite > >> > committer add "-author" parameter when committing? > >> > >> It depends on how the patch file was made. If 'git format-patch' was > used > >> then > >> the name will be preserved. Otherwise, it won't. Sorry, I don't know > much > >> about github and I really am not using it. > >> > >> Cos > >> > >> > > > Can somebody explain to me the merge procedure? > >> > > > > >> > > > 2015-08-12 3:15 GMT-07:00 Artem Shutak <[hidden email]>: > >> > > > > >> > > > > Inline. > >> > > > > > >> > > > > On Wed, Aug 12, 2015 at 10:19 AM, Dmitriy Setrakyan < > >> > > [hidden email] > >> > > > > > > >> > > > > wrote: > >> > > > > > >> > > > > > On Tue, Aug 11, 2015 at 6:28 AM, Artem Shutak < > >> [hidden email]> > >> > > > > > wrote: > >> > > > > > > >> > > > > > > And one more question. Is it mandatory to have possibility > >> works > >> > > via > >> > > > > > > patches if we will have pull-request way for contributions? > >> > > > > > > > >> > > > > > > I'd like to have only one approach. > >> > > > > > > > >> > > > > > > >> > > > > > Artem, if possible I would allow 2 approaches and document > the 2 > >> > > > > approaches > >> > > > > > on Wiki. > >> > > > > > > >> > > > > > >> > > > > At least it increases support efforts. And if all will use only > >> one, > >> > > then > >> > > > > there is a big chance that second will not work properly. > >> > > > > > >> > > > > And, to complete patch-way: > >> > > > > - need to split simple "master" builds and "patch" builds on TC > - > >> I > >> > > can do > >> > > > > it by yourself. > >> > > > > - need to implement git-format-patch.bat for Windows users. It's > >> not > >> > > > > mandatory, all can be done manually by contributors, but it > would > >> be > >> > > nice. > >> > > > > This script can make any Windows user (I'm not :) ). > >> > > > > > >> > > > > > >> > > > > > > >> > > > > > One question, does a pull request automatically generate a > Jira > >> > > comment > >> > > > > > (see Spark, Camel)? > >> > > > > > > >> > > > > > >> > > > > I will look at mentioned projects. From my view, by default, > >> GitHub > >> > > know > >> > > > > nothing about our Jira. So, there's no way to GitHub can add any > >> > > comments > >> > > > > to unknown Jira. > >> > > > > DVCS plugin - it's a standard way to acquaint Jira and GitHub > and > >> it > >> > > will > >> > > > > work pretty nice. > >> > > > > > >> > > > > --Artem-- > >> > > > > > >> > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > -- Artem -- > >> > > > > > > > >> > > > > > > On Tue, Aug 11, 2015 at 4:15 PM, Artem Shutak < > >> > > [hidden email]> > >> > > > > > > wrote: > >> > > > > > > > >> > > > > > > > Igniters, > >> > > > > > > > > >> > > > > > > > I'm working on > >> https://issues.apache.org/jira/browse/IGNITE-1217 > >> > > . > >> > > > > > > > > >> > > > > > > > Currently, everyone can fork Mirror of Apache Ignite on > >> GitHub ( > >> > > > > > > > https://github.com/apache/incubator-ignite), works with > >> own fork > >> > > > > > (create > >> > > > > > > > branches, commit, pull changes at fork) and then creates a > >> > > > > pull-request > >> > > > > > > to > >> > > > > > > > Mirror of Apache Ignite on GitHub (all changes should be > >> done in > >> > > one > >> > > > > > > commit > >> > > > > > > > as in patch-way approach). Then test TC builds will > >> triggered > >> > > > > > > > automatically. Results can be found by branch filtering by > >> > > pattern > >> > > > > > > > <pull-request-number>/merge. "Merge" suffix here means > >> > > pull-request > >> > > > > > > merged > >> > > > > > > > with master branch (if pull-request at master branch). > >> > > > > > > > > >> > > > > > > > Notes: > >> > > > > > > > > >> > > > > > > > 1. I tried to use TC plugin for github to see TC result at > >> > > > > > pull-request. > >> > > > > > > > But the plugin works in unexpected way and add comments > not > >> only > >> > > to > >> > > > > > > > pull-requests. Example: > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > >> > https://github.com/apache/incubator-ignite/commit/ae11e9b5aa9af4d0d58e2a16dd3a3331969961df#commitcomment-12635375 > >> > > > > > > > . > >> > > > > > > > Maybe someone had this problem before? > >> > > > > > > > > >> > > > > > > > 2. I'm looking for a simple way to add information about > new > >> > > > > > pull-request > >> > > > > > > > to associated jira. > >> > > > > > > > The better way to use existing Jira plugin for it - DVCS > >> plugin ( > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > >> > https://confluence.atlassian.com/display/BITBUCKET/Linking+Bitbucket+and+GitHub+accounts+to+JIRA > >> > > > > > > ). > >> > > > > > > > But I need both: Jira administration rights to configure > the > >> > > plugin > >> > > > > and > >> > > > > > > > GitHub password for "apache" user. Or I missed something > >> and we > >> > > can't > >> > > > > > use > >> > > > > > > > this plugin at Apache infrastructure? > >> > > > > > > > Maybe someone can suggest another solution? > >> > > > > > > > > >> > > > > > > > Thanks, > >> > > > > > > > Artem. > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > >> > > > > > |
Re: IGNITE-1217 TC triggering by github pull-requests
|
|
Artem,
Seems that TC doesn't write down comments into a corresponding JIRA issue for branches that have 'dev' suffix (like 'ignite-xxx-dev'). I've created a pull-request to merge from 'ignite-1241-dev': https://github.com/apache/incubator-ignite/pull/19 I've received an e-mail saying that the request has been received and I see that TC triggered the request for validation. However, there is no any info left regarding this in a corresponding ticket: https://issues.apache.org/jira/browse/IGNITE-1241 Meanwhile, here I see that such info from GitHub Bot: https://issues.apache.org/jira/browse/IGNITE-1203 In addition I have one more thing to clarify. When TC ends validating my changes will it send links to tests' results over email or to JIRA ticket? Cause as you know TC cleans 'active branches' history and I guess that it won't be easy for me to find the results on TC in a couple of days. -- Denis On 8/14/2015 1:30 PM, Artem Shutak wrote: > Alexey, > > You are right and big thanks for the diagram on the wiki! > > In bounds of IGNITE-1217 > <https://issues.apache.org/jira/browse/IGNITE-1217> I've > created a script for commiters (see patch). You need to point to the script > a contributor_github_user_name and a branch_name_with_contribution. The > script just fetchs a remote repository (by contributor_github_user_name) > and cherry-picks last commit from this branch to local master - it stores > commit author information. So, the commiter can push master at apache git. > > In this case we have one requirement: a pull-request should have only one > commit (as with patches). > > I've mention next model of development at fork (see steps below). But now, > I see it has too many steps. I will think about more simple way. > 1. Preparation (need to configure once): > > git remote add apache > https://git-wip-us.apache.org/repos/asf/incubator-ignite > git remote my_fork https://github.com/<github_uname>/incubator-ignite.git > > 2. Forking on jira ignite-xxxx > # Update local master from apache repo > git checkout master > git pull apache master > > # Create new development branch for the ticket. > git checkout -b ignite-xxxx-dev > > # Some development here with many commits at ignite-xxxx-dev. > git commit -a -m 'ignite-xxxx: Intermediate commit 1' > ... > git commit -a -m 'ignite-xxxx: Intermediate commit 100' > > # Push at fork > git push my_fork ignite-xxxx-dev > > Now a pull-request can be created. TC will be triggered. To fix some > something and rerun TC, you need just fix it at ignite-xxxx-dev and push to > fork again, TC will be triggered again for new commit. > > When TC is green, it needs to create 'final' pull-request branch with one > commit. For it: > # Update local master from apache repo > git checkout master > git pull apache master > > # Create a final pull-request branch for the ticket. > git checkout -b ignite-xxxx > > # Squash all changes at one commit. > git merge --squash ignite-xxxx-dev > git commit -a -m 'ignite-xxxx: Implemented' > > Then need to push it to fork and open new pull-request. > > > -- Artem -- > > On Fri, Aug 14, 2015 at 5:30 AM, Alexey Goncharuk < > [hidden email]> wrote: > >> I forgot that the mailing list takes out all formatting, the diagram meant >> to be in a monospaced font :) >> >> I added it to Ignite wiki: >> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute >> >> 2015-08-13 19:22 GMT-07:00 Alexey Goncharuk <[hidden email]>: >> >>> While the process of a pull-request creation and CI run is clear for, the >>> whole cycle from start to end is still fuzzy. Let me summarize my >>> understanding and correct me if I got something wrong. >>> >>> For any committer/contributor John Doe we will have the following >>> structure: >>> >>> +------------+ +---------------+ >>> +-----------------+ >>> | | replica | | fork | >>> | >>> | Apache Git | ==========> | GitHub Mirror | ---------> | John Doe's >> Fork >>> | >>> | | | | | >>> | >>> +------------+ +---------------+ >>> +-----------------+ >>> ^ ^ >>> | | >>> | | >>> | >>> +-----------------+ >>> | *Apache Git remote handle for committers* | >>> | >>> +------------------------------------------------| Local clone >>> | >>> | >>> | >>> >>> +-----------------+ >>> Development is going in the JD's fork and at some point he thinks that >> the >>> feature is ready to be tested by CI. >>> >>> He creates a pull request. Usually it takes more than one iteration to >>> have a successful CI run, but each pull request sends an e-mail to the >> dev >>> list. I think we should have some mechanism allowing to differentiate >>> "work" pull requests and final pull requests that passed CI and should be >>> reviewed by a committer. We also need to create (maybe) a maven profile >>> with a set of quick tests that cover as much functionality as possible, >> so >>> that a developer could run it locally before submitting a request to the >> CI. >>> Let's say now the pull request is approved. If the pull request was >>> submitted by a contributor, a committer should pull it to it's local >> clone. >>> Then commit is pushed to the apache git repository. I glanced through the >>> Apache Spark development process document [1] and it seems that we should >>> have a similar script that will properly process commits (squash or >>> whatever we need) before the push. >>> >>> Assuming my understanding is correct and the minor things I mentioned >>> above are addressed, I like the new process :) >>> >>> [1] >>> https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark >>> >>> >>> 2015-08-13 18:13 GMT-07:00 Konstantin Boudnik <[hidden email]>: >>> >>>> On Thu, Aug 13, 2015 at 05:54PM, Dmitriy Setrakyan wrote: >>>>> On Thu, Aug 13, 2015 at 5:51 PM, Konstantin Boudnik <[hidden email]> >>>> wrote: >>>>>> On Thu, Aug 13, 2015 at 05:40PM, Alexey Goncharuk wrote: >>>>>>> Maybe I miss a good piece of information about how Git works, but >> I >>>>>> always >>>>>>> thought that if a pull request is accepted, it will be merged to >> the >>>>>> GitHub >>>>>>> mirror of Apache Ignite. How will this change get to the original >>>> Apache >>>>>>> git repository? >>>>>> It won't. github repo is a mirror of Apache git mirror. In order to >>>> have >>>>>> the >>>>>> changes from github PR to be in visible in the github a committer >>>> needs to >>>>>> commit it into our Apache repo. >>>>>> >>>>> Cos, will the original contributor's name be preserved or should the >>>> Ignite >>>>> committer add "-author" parameter when committing? >>>> It depends on how the patch file was made. If 'git format-patch' was >> used >>>> then >>>> the name will be preserved. Otherwise, it won't. Sorry, I don't know >> much >>>> about github and I really am not using it. >>>> >>>> Cos >>>> >>>>>>> Can somebody explain to me the merge procedure? >>>>>>> >>>>>>> 2015-08-12 3:15 GMT-07:00 Artem Shutak <[hidden email]>: >>>>>>> >>>>>>>> Inline. >>>>>>>> >>>>>>>> On Wed, Aug 12, 2015 at 10:19 AM, Dmitriy Setrakyan < >>>>>> [hidden email] >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Tue, Aug 11, 2015 at 6:28 AM, Artem Shutak < >>>> [hidden email]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> And one more question. Is it mandatory to have possibility >>>> works >>>>>> via >>>>>>>>>> patches if we will have pull-request way for contributions? >>>>>>>>>> >>>>>>>>>> I'd like to have only one approach. >>>>>>>>>> >>>>>>>>> Artem, if possible I would allow 2 approaches and document >> the 2 >>>>>>>> approaches >>>>>>>>> on Wiki. >>>>>>>>> >>>>>>>> At least it increases support efforts. And if all will use only >>>> one, >>>>>> then >>>>>>>> there is a big chance that second will not work properly. >>>>>>>> >>>>>>>> And, to complete patch-way: >>>>>>>> - need to split simple "master" builds and "patch" builds on TC >> - >>>> I >>>>>> can do >>>>>>>> it by yourself. >>>>>>>> - need to implement git-format-patch.bat for Windows users. It's >>>> not >>>>>>>> mandatory, all can be done manually by contributors, but it >> would >>>> be >>>>>> nice. >>>>>>>> This script can make any Windows user (I'm not :) ). >>>>>>>> >>>>>>>> >>>>>>>>> One question, does a pull request automatically generate a >> Jira >>>>>> comment >>>>>>>>> (see Spark, Camel)? >>>>>>>>> >>>>>>>> I will look at mentioned projects. From my view, by default, >>>> GitHub >>>>>> know >>>>>>>> nothing about our Jira. So, there's no way to GitHub can add any >>>>>> comments >>>>>>>> to unknown Jira. >>>>>>>> DVCS plugin - it's a standard way to acquaint Jira and GitHub >> and >>>> it >>>>>> will >>>>>>>> work pretty nice. >>>>>>>> >>>>>>>> --Artem-- >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> -- Artem -- >>>>>>>>>> >>>>>>>>>> On Tue, Aug 11, 2015 at 4:15 PM, Artem Shutak < >>>>>> [hidden email]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Igniters, >>>>>>>>>>> >>>>>>>>>>> I'm working on >>>> https://issues.apache.org/jira/browse/IGNITE-1217 >>>>>> . >>>>>>>>>>> Currently, everyone can fork Mirror of Apache Ignite on >>>> GitHub ( >>>>>>>>>>> https://github.com/apache/incubator-ignite), works with >>>> own fork >>>>>>>>> (create >>>>>>>>>>> branches, commit, pull changes at fork) and then creates a >>>>>>>> pull-request >>>>>>>>>> to >>>>>>>>>>> Mirror of Apache Ignite on GitHub (all changes should be >>>> done in >>>>>> one >>>>>>>>>> commit >>>>>>>>>>> as in patch-way approach). Then test TC builds will >>>> triggered >>>>>>>>>>> automatically. Results can be found by branch filtering by >>>>>> pattern >>>>>>>>>>> <pull-request-number>/merge. "Merge" suffix here means >>>>>> pull-request >>>>>>>>>> merged >>>>>>>>>>> with master branch (if pull-request at master branch). >>>>>>>>>>> >>>>>>>>>>> Notes: >>>>>>>>>>> >>>>>>>>>>> 1. I tried to use TC plugin for github to see TC result at >>>>>>>>> pull-request. >>>>>>>>>>> But the plugin works in unexpected way and add comments >> not >>>> only >>>>>> to >>>>>>>>>>> pull-requests. Example: >>>>>>>>>>> >> https://github.com/apache/incubator-ignite/commit/ae11e9b5aa9af4d0d58e2a16dd3a3331969961df#commitcomment-12635375 >>>>>>>>>>> . >>>>>>>>>>> Maybe someone had this problem before? >>>>>>>>>>> >>>>>>>>>>> 2. I'm looking for a simple way to add information about >> new >>>>>>>>> pull-request >>>>>>>>>>> to associated jira. >>>>>>>>>>> The better way to use existing Jira plugin for it - DVCS >>>> plugin ( >> https://confluence.atlassian.com/display/BITBUCKET/Linking+Bitbucket+and+GitHub+accounts+to+JIRA >>>>>>>>>> ). >>>>>>>>>>> But I need both: Jira administration rights to configure >> the >>>>>> plugin >>>>>>>> and >>>>>>>>>>> GitHub password for "apache" user. Or I missed something >>>> and we >>>>>> can't >>>>>>>>> use >>>>>>>>>>> this plugin at Apache infrastructure? >>>>>>>>>>> Maybe someone can suggest another solution? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Artem. >>>>>>>>>>> >>> |
Re: IGNITE-1217 TC triggering by github pull-requests
|
|
Artem,
Why do we need a requirement about one commit per pull request? I understand that we should should avoid garbage in history and properly deal with merges from master. But I don't see anything wrong with 2-3 commits in a PR if they are meaningful. E.g., "implemented initial version" -> "fixed failures in tests" -> "addressed comments from a committer". They should just contain good comments and (probably) corresponding JIRA ticket number. In your process (if I understood everything correctly) we will create two PRs for each feature. This looks weird and confusing for me. And I really don't understand what issue we're trying to solve here. I think we should take a look at Spark .py script that can be found here: https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-HowtoMergeaPullRequest. It looks like they already addressed and automated everything we discuss here. Thoughts? -Val On Fri, Aug 14, 2015 at 7:03 AM, Denis Magda <[hidden email]> wrote: > Artem, > > Seems that TC doesn't write down comments into a corresponding JIRA issue > for branches that have 'dev' suffix (like 'ignite-xxx-dev'). > > I've created a pull-request to merge from 'ignite-1241-dev': > https://github.com/apache/incubator-ignite/pull/19 > > I've received an e-mail saying that the request has been received and I > see that TC triggered the request for validation. > However, there is no any info left regarding this in a corresponding > ticket: > https://issues.apache.org/jira/browse/IGNITE-1241 > > Meanwhile, here I see that such info from GitHub Bot: > https://issues.apache.org/jira/browse/IGNITE-1203 > > In addition I have one more thing to clarify. > When TC ends validating my changes will it send links to tests' results > over email or to JIRA ticket? > Cause as you know TC cleans 'active branches' history and I guess that it > won't be easy for me to find the results on TC in a couple of days. > > -- > Denis > > > On 8/14/2015 1:30 PM, Artem Shutak wrote: > >> Alexey, >> >> You are right and big thanks for the diagram on the wiki! >> >> In bounds of IGNITE-1217 >> <https://issues.apache.org/jira/browse/IGNITE-1217> I've >> created a script for commiters (see patch). You need to point to the >> script >> a contributor_github_user_name and a branch_name_with_contribution. The >> script just fetchs a remote repository (by contributor_github_user_name) >> and cherry-picks last commit from this branch to local master - it stores >> commit author information. So, the commiter can push master at apache git. >> >> In this case we have one requirement: a pull-request should have only one >> commit (as with patches). >> >> I've mention next model of development at fork (see steps below). But now, >> I see it has too many steps. I will think about more simple way. >> 1. Preparation (need to configure once): >> >> git remote add apache >> https://git-wip-us.apache.org/repos/asf/incubator-ignite >> git remote my_fork https://github.com/<github_uname>/incubator-ignite.git >> >> 2. Forking on jira ignite-xxxx >> # Update local master from apache repo >> git checkout master >> git pull apache master >> >> # Create new development branch for the ticket. >> git checkout -b ignite-xxxx-dev >> >> # Some development here with many commits at ignite-xxxx-dev. >> git commit -a -m 'ignite-xxxx: Intermediate commit 1' >> ... >> git commit -a -m 'ignite-xxxx: Intermediate commit 100' >> >> # Push at fork >> git push my_fork ignite-xxxx-dev >> >> Now a pull-request can be created. TC will be triggered. To fix some >> something and rerun TC, you need just fix it at ignite-xxxx-dev and push >> to >> fork again, TC will be triggered again for new commit. >> >> When TC is green, it needs to create 'final' pull-request branch with one >> commit. For it: >> # Update local master from apache repo >> git checkout master >> git pull apache master >> >> # Create a final pull-request branch for the ticket. >> git checkout -b ignite-xxxx >> >> # Squash all changes at one commit. >> git merge --squash ignite-xxxx-dev >> git commit -a -m 'ignite-xxxx: Implemented' >> >> Then need to push it to fork and open new pull-request. >> >> >> -- Artem -- >> >> On Fri, Aug 14, 2015 at 5:30 AM, Alexey Goncharuk < >> [hidden email]> wrote: >> >> I forgot that the mailing list takes out all formatting, the diagram meant >>> to be in a monospaced font :) >>> >>> I added it to Ignite wiki: >>> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute >>> >>> 2015-08-13 19:22 GMT-07:00 Alexey Goncharuk <[hidden email] >>> >: >>> >>> While the process of a pull-request creation and CI run is clear for, the >>>> whole cycle from start to end is still fuzzy. Let me summarize my >>>> understanding and correct me if I got something wrong. >>>> >>>> For any committer/contributor John Doe we will have the following >>>> structure: >>>> >>>> +------------+ +---------------+ >>>> +-----------------+ >>>> | | replica | | fork | >>>> | >>>> | Apache Git | ==========> | GitHub Mirror | ---------> | John Doe's >>>> >>> Fork >>> >>>> | >>>> | | | | | >>>> | >>>> +------------+ +---------------+ >>>> +-----------------+ >>>> ^ ^ >>>> | | >>>> | | >>>> | >>>> +-----------------+ >>>> | *Apache Git remote handle for committers* | >>>> | >>>> +------------------------------------------------| Local >>>> clone >>>> | >>>> | >>>> | >>>> >>>> +-----------------+ >>>> Development is going in the JD's fork and at some point he thinks that >>>> >>> the >>> >>>> feature is ready to be tested by CI. >>>> >>>> He creates a pull request. Usually it takes more than one iteration to >>>> have a successful CI run, but each pull request sends an e-mail to the >>>> >>> dev >>> >>>> list. I think we should have some mechanism allowing to differentiate >>>> "work" pull requests and final pull requests that passed CI and should >>>> be >>>> reviewed by a committer. We also need to create (maybe) a maven profile >>>> with a set of quick tests that cover as much functionality as possible, >>>> >>> so >>> >>>> that a developer could run it locally before submitting a request to the >>>> >>> CI. >>> >>>> Let's say now the pull request is approved. If the pull request was >>>> submitted by a contributor, a committer should pull it to it's local >>>> >>> clone. >>> >>>> Then commit is pushed to the apache git repository. I glanced through >>>> the >>>> Apache Spark development process document [1] and it seems that we >>>> should >>>> have a similar script that will properly process commits (squash or >>>> whatever we need) before the push. >>>> >>>> Assuming my understanding is correct and the minor things I mentioned >>>> above are addressed, I like the new process :) >>>> >>>> [1] >>>> https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark >>>> >>>> >>>> 2015-08-13 18:13 GMT-07:00 Konstantin Boudnik <[hidden email]>: >>>> >>>> On Thu, Aug 13, 2015 at 05:54PM, Dmitriy Setrakyan wrote: >>>>> >>>>>> On Thu, Aug 13, 2015 at 5:51 PM, Konstantin Boudnik <[hidden email]> >>>>>> >>>>> wrote: >>>>> >>>>>> On Thu, Aug 13, 2015 at 05:40PM, Alexey Goncharuk wrote: >>>>>>> >>>>>>>> Maybe I miss a good piece of information about how Git works, but >>>>>>>> >>>>>>> I >>> >>>> always >>>>>>> >>>>>>>> thought that if a pull request is accepted, it will be merged to >>>>>>>> >>>>>>> the >>> >>>> GitHub >>>>>>> >>>>>>>> mirror of Apache Ignite. How will this change get to the original >>>>>>>> >>>>>>> Apache >>>>> >>>>>> git repository? >>>>>>>> >>>>>>> It won't. github repo is a mirror of Apache git mirror. In order to >>>>>>> >>>>>> have >>>>> >>>>>> the >>>>>>> changes from github PR to be in visible in the github a committer >>>>>>> >>>>>> needs to >>>>> >>>>>> commit it into our Apache repo. >>>>>>> >>>>>>> Cos, will the original contributor's name be preserved or should the >>>>>> >>>>> Ignite >>>>> >>>>>> committer add "-author" parameter when committing? >>>>>> >>>>> It depends on how the patch file was made. If 'git format-patch' was >>>>> >>>> used >>> >>>> then >>>>> the name will be preserved. Otherwise, it won't. Sorry, I don't know >>>>> >>>> much >>> >>>> about github and I really am not using it. >>>>> >>>>> Cos >>>>> >>>>> Can somebody explain to me the merge procedure? >>>>>>>> >>>>>>>> 2015-08-12 3:15 GMT-07:00 Artem Shutak <[hidden email]>: >>>>>>>> >>>>>>>> Inline. >>>>>>>>> >>>>>>>>> On Wed, Aug 12, 2015 at 10:19 AM, Dmitriy Setrakyan < >>>>>>>>> >>>>>>>> [hidden email] >>>>>>> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On Tue, Aug 11, 2015 at 6:28 AM, Artem Shutak < >>>>>>>>>> >>>>>>>>> [hidden email]> >>>>> >>>>>> wrote: >>>>>>>>>> >>>>>>>>>> And one more question. Is it mandatory to have possibility >>>>>>>>>>> >>>>>>>>>> works >>>>> >>>>>> via >>>>>>> >>>>>>>> patches if we will have pull-request way for contributions? >>>>>>>>>>> >>>>>>>>>>> I'd like to have only one approach. >>>>>>>>>>> >>>>>>>>>>> Artem, if possible I would allow 2 approaches and document >>>>>>>>>> >>>>>>>>> the 2 >>> >>>> approaches >>>>>>>>> >>>>>>>>>> on Wiki. >>>>>>>>>> >>>>>>>>>> At least it increases support efforts. And if all will use only >>>>>>>>> >>>>>>>> one, >>>>> >>>>>> then >>>>>>> >>>>>>>> there is a big chance that second will not work properly. >>>>>>>>> >>>>>>>>> And, to complete patch-way: >>>>>>>>> - need to split simple "master" builds and "patch" builds on TC >>>>>>>>> >>>>>>>> - >>> >>>> I >>>>> >>>>>> can do >>>>>>> >>>>>>>> it by yourself. >>>>>>>>> - need to implement git-format-patch.bat for Windows users. It's >>>>>>>>> >>>>>>>> not >>>>> >>>>>> mandatory, all can be done manually by contributors, but it >>>>>>>>> >>>>>>>> would >>> >>>> be >>>>> >>>>>> nice. >>>>>>> >>>>>>>> This script can make any Windows user (I'm not :) ). >>>>>>>>> >>>>>>>>> >>>>>>>>> One question, does a pull request automatically generate a >>>>>>>>>> >>>>>>>>> Jira >>> >>>> comment >>>>>>> >>>>>>>> (see Spark, Camel)? >>>>>>>>>> >>>>>>>>>> I will look at mentioned projects. From my view, by default, >>>>>>>>> >>>>>>>> GitHub >>>>> >>>>>> know >>>>>>> >>>>>>>> nothing about our Jira. So, there's no way to GitHub can add any >>>>>>>>> >>>>>>>> comments >>>>>>> >>>>>>>> to unknown Jira. >>>>>>>>> DVCS plugin - it's a standard way to acquaint Jira and GitHub >>>>>>>>> >>>>>>>> and >>> >>>> it >>>>> >>>>>> will >>>>>>> >>>>>>>> work pretty nice. >>>>>>>>> >>>>>>>>> --Artem-- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> -- Artem -- >>>>>>>>>>> >>>>>>>>>>> On Tue, Aug 11, 2015 at 4:15 PM, Artem Shutak < >>>>>>>>>>> >>>>>>>>>> [hidden email]> >>>>>>> >>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Igniters, >>>>>>>>>>>> >>>>>>>>>>>> I'm working on >>>>>>>>>>>> >>>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-1217 >>>>> >>>>>> . >>>>>>> >>>>>>>> Currently, everyone can fork Mirror of Apache Ignite on >>>>>>>>>>>> >>>>>>>>>>> GitHub ( >>>>> >>>>>> https://github.com/apache/incubator-ignite), works with >>>>>>>>>>>> >>>>>>>>>>> own fork >>>>> >>>>>> (create >>>>>>>>>> >>>>>>>>>>> branches, commit, pull changes at fork) and then creates a >>>>>>>>>>>> >>>>>>>>>>> pull-request >>>>>>>>> >>>>>>>>>> to >>>>>>>>>>> >>>>>>>>>>>> Mirror of Apache Ignite on GitHub (all changes should be >>>>>>>>>>>> >>>>>>>>>>> done in >>>>> >>>>>> one >>>>>>> >>>>>>>> commit >>>>>>>>>>> >>>>>>>>>>>> as in patch-way approach). Then test TC builds will >>>>>>>>>>>> >>>>>>>>>>> triggered >>>>> >>>>>> automatically. Results can be found by branch filtering by >>>>>>>>>>>> >>>>>>>>>>> pattern >>>>>>> >>>>>>>> <pull-request-number>/merge. "Merge" suffix here means >>>>>>>>>>>> >>>>>>>>>>> pull-request >>>>>>> >>>>>>>> merged >>>>>>>>>>> >>>>>>>>>>>> with master branch (if pull-request at master branch). >>>>>>>>>>>> >>>>>>>>>>>> Notes: >>>>>>>>>>>> >>>>>>>>>>>> 1. I tried to use TC plugin for github to see TC result at >>>>>>>>>>>> >>>>>>>>>>> pull-request. >>>>>>>>>> >>>>>>>>>>> But the plugin works in unexpected way and add comments >>>>>>>>>>>> >>>>>>>>>>> not >>> >>>> only >>>>> >>>>>> to >>>>>>> >>>>>>>> pull-requests. Example: >>>>>>>>>>>> >>>>>>>>>>>> >>> https://github.com/apache/incubator-ignite/commit/ae11e9b5aa9af4d0d58e2a16dd3a3331969961df#commitcomment-12635375 >>> >>>> . >>>>>>>>>>>> Maybe someone had this problem before? >>>>>>>>>>>> >>>>>>>>>>>> 2. I'm looking for a simple way to add information about >>>>>>>>>>>> >>>>>>>>>>> new >>> >>>> pull-request >>>>>>>>>> >>>>>>>>>>> to associated jira. >>>>>>>>>>>> The better way to use existing Jira plugin for it - DVCS >>>>>>>>>>>> >>>>>>>>>>> plugin ( >>>>> >>>> >>> https://confluence.atlassian.com/display/BITBUCKET/Linking+Bitbucket+and+GitHub+accounts+to+JIRA >>> >>>> ). >>>>>>>>>>> >>>>>>>>>>>> But I need both: Jira administration rights to configure >>>>>>>>>>>> >>>>>>>>>>> the >>> >>>> plugin >>>>>>> >>>>>>>> and >>>>>>>>> >>>>>>>>>> GitHub password for "apache" user. Or I missed something >>>>>>>>>>>> >>>>>>>>>>> and we >>>>> >>>>>> can't >>>>>>> >>>>>>>> use >>>>>>>>>> >>>>>>>>>>> this plugin at Apache infrastructure? >>>>>>>>>>>> Maybe someone can suggest another solution? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Artem. >>>>>>>>>>>> >>>>>>>>>>>> >>>> > |
Re: IGNITE-1217 TC triggering by github pull-requests
|
|
And a minor question.
On TC in branches dropdown I see 'pull/xx/head' and 'pull/xx/merge'. What is the difference? -Val On Fri, Aug 14, 2015 at 3:23 PM, Valentin Kulichenko < [hidden email]> wrote: > Artem, > > Why do we need a requirement about one commit per pull request? I > understand that we should should avoid garbage in history and properly deal > with merges from master. But I don't see anything wrong with 2-3 commits in > a PR if they are meaningful. E.g., "implemented initial version" -> "fixed > failures in tests" -> "addressed comments from a committer". They should > just contain good comments and (probably) corresponding JIRA ticket number. > > In your process (if I understood everything correctly) we will create two > PRs for each feature. This looks weird and confusing for me. And I really > don't understand what issue we're trying to solve here. > > I think we should take a look at Spark .py script that can be found here: > https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-HowtoMergeaPullRequest. > It looks like they already addressed and automated everything we discuss > here. > > Thoughts? > > -Val > > On Fri, Aug 14, 2015 at 7:03 AM, Denis Magda <[hidden email]> wrote: > >> Artem, >> >> Seems that TC doesn't write down comments into a corresponding JIRA issue >> for branches that have 'dev' suffix (like 'ignite-xxx-dev'). >> >> I've created a pull-request to merge from 'ignite-1241-dev': >> https://github.com/apache/incubator-ignite/pull/19 >> >> I've received an e-mail saying that the request has been received and I >> see that TC triggered the request for validation. >> However, there is no any info left regarding this in a corresponding >> ticket: >> https://issues.apache.org/jira/browse/IGNITE-1241 >> >> Meanwhile, here I see that such info from GitHub Bot: >> https://issues.apache.org/jira/browse/IGNITE-1203 >> >> In addition I have one more thing to clarify. >> When TC ends validating my changes will it send links to tests' results >> over email or to JIRA ticket? >> Cause as you know TC cleans 'active branches' history and I guess that it >> won't be easy for me to find the results on TC in a couple of days. >> >> -- >> Denis >> >> >> On 8/14/2015 1:30 PM, Artem Shutak wrote: >> >>> Alexey, >>> >>> You are right and big thanks for the diagram on the wiki! >>> >>> In bounds of IGNITE-1217 >>> <https://issues.apache.org/jira/browse/IGNITE-1217> I've >>> created a script for commiters (see patch). You need to point to the >>> script >>> a contributor_github_user_name and a branch_name_with_contribution. The >>> script just fetchs a remote repository (by contributor_github_user_name) >>> and cherry-picks last commit from this branch to local master - it stores >>> commit author information. So, the commiter can push master at apache >>> git. >>> >>> In this case we have one requirement: a pull-request should have only one >>> commit (as with patches). >>> >>> I've mention next model of development at fork (see steps below). But >>> now, >>> I see it has too many steps. I will think about more simple way. >>> 1. Preparation (need to configure once): >>> >>> git remote add apache >>> https://git-wip-us.apache.org/repos/asf/incubator-ignite >>> git remote my_fork https://github.com/ >>> <github_uname>/incubator-ignite.git >>> >>> 2. Forking on jira ignite-xxxx >>> # Update local master from apache repo >>> git checkout master >>> git pull apache master >>> >>> # Create new development branch for the ticket. >>> git checkout -b ignite-xxxx-dev >>> >>> # Some development here with many commits at ignite-xxxx-dev. >>> git commit -a -m 'ignite-xxxx: Intermediate commit 1' >>> ... >>> git commit -a -m 'ignite-xxxx: Intermediate commit 100' >>> >>> # Push at fork >>> git push my_fork ignite-xxxx-dev >>> >>> Now a pull-request can be created. TC will be triggered. To fix some >>> something and rerun TC, you need just fix it at ignite-xxxx-dev and push >>> to >>> fork again, TC will be triggered again for new commit. >>> >>> When TC is green, it needs to create 'final' pull-request branch with one >>> commit. For it: >>> # Update local master from apache repo >>> git checkout master >>> git pull apache master >>> >>> # Create a final pull-request branch for the ticket. >>> git checkout -b ignite-xxxx >>> >>> # Squash all changes at one commit. >>> git merge --squash ignite-xxxx-dev >>> git commit -a -m 'ignite-xxxx: Implemented' >>> >>> Then need to push it to fork and open new pull-request. >>> >>> >>> -- Artem -- >>> >>> On Fri, Aug 14, 2015 at 5:30 AM, Alexey Goncharuk < >>> [hidden email]> wrote: >>> >>> I forgot that the mailing list takes out all formatting, the diagram >>>> meant >>>> to be in a monospaced font :) >>>> >>>> I added it to Ignite wiki: >>>> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute >>>> >>>> 2015-08-13 19:22 GMT-07:00 Alexey Goncharuk <[hidden email] >>>> >: >>>> >>>> While the process of a pull-request creation and CI run is clear for, >>>>> the >>>>> whole cycle from start to end is still fuzzy. Let me summarize my >>>>> understanding and correct me if I got something wrong. >>>>> >>>>> For any committer/contributor John Doe we will have the following >>>>> structure: >>>>> >>>>> +------------+ +---------------+ >>>>> +-----------------+ >>>>> | | replica | | fork | >>>>> | >>>>> | Apache Git | ==========> | GitHub Mirror | ---------> | John Doe's >>>>> >>>> Fork >>>> >>>>> | >>>>> | | | | | >>>>> | >>>>> +------------+ +---------------+ >>>>> +-----------------+ >>>>> ^ ^ >>>>> | | >>>>> | | >>>>> | >>>>> +-----------------+ >>>>> | *Apache Git remote handle for committers* | >>>>> | >>>>> +------------------------------------------------| Local >>>>> clone >>>>> | >>>>> | >>>>> | >>>>> >>>>> +-----------------+ >>>>> Development is going in the JD's fork and at some point he thinks that >>>>> >>>> the >>>> >>>>> feature is ready to be tested by CI. >>>>> >>>>> He creates a pull request. Usually it takes more than one iteration to >>>>> have a successful CI run, but each pull request sends an e-mail to the >>>>> >>>> dev >>>> >>>>> list. I think we should have some mechanism allowing to differentiate >>>>> "work" pull requests and final pull requests that passed CI and should >>>>> be >>>>> reviewed by a committer. We also need to create (maybe) a maven profile >>>>> with a set of quick tests that cover as much functionality as possible, >>>>> >>>> so >>>> >>>>> that a developer could run it locally before submitting a request to >>>>> the >>>>> >>>> CI. >>>> >>>>> Let's say now the pull request is approved. If the pull request was >>>>> submitted by a contributor, a committer should pull it to it's local >>>>> >>>> clone. >>>> >>>>> Then commit is pushed to the apache git repository. I glanced through >>>>> the >>>>> Apache Spark development process document [1] and it seems that we >>>>> should >>>>> have a similar script that will properly process commits (squash or >>>>> whatever we need) before the push. >>>>> >>>>> Assuming my understanding is correct and the minor things I mentioned >>>>> above are addressed, I like the new process :) >>>>> >>>>> [1] >>>>> https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark >>>>> >>>>> >>>>> 2015-08-13 18:13 GMT-07:00 Konstantin Boudnik <[hidden email]>: >>>>> >>>>> On Thu, Aug 13, 2015 at 05:54PM, Dmitriy Setrakyan wrote: >>>>>> >>>>>>> On Thu, Aug 13, 2015 at 5:51 PM, Konstantin Boudnik <[hidden email]> >>>>>>> >>>>>> wrote: >>>>>> >>>>>>> On Thu, Aug 13, 2015 at 05:40PM, Alexey Goncharuk wrote: >>>>>>>> >>>>>>>>> Maybe I miss a good piece of information about how Git works, but >>>>>>>>> >>>>>>>> I >>>> >>>>> always >>>>>>>> >>>>>>>>> thought that if a pull request is accepted, it will be merged to >>>>>>>>> >>>>>>>> the >>>> >>>>> GitHub >>>>>>>> >>>>>>>>> mirror of Apache Ignite. How will this change get to the original >>>>>>>>> >>>>>>>> Apache >>>>>> >>>>>>> git repository? >>>>>>>>> >>>>>>>> It won't. github repo is a mirror of Apache git mirror. In order to >>>>>>>> >>>>>>> have >>>>>> >>>>>>> the >>>>>>>> changes from github PR to be in visible in the github a committer >>>>>>>> >>>>>>> needs to >>>>>> >>>>>>> commit it into our Apache repo. >>>>>>>> >>>>>>>> Cos, will the original contributor's name be preserved or should the >>>>>>> >>>>>> Ignite >>>>>> >>>>>>> committer add "-author" parameter when committing? >>>>>>> >>>>>> It depends on how the patch file was made. If 'git format-patch' was >>>>>> >>>>> used >>>> >>>>> then >>>>>> the name will be preserved. Otherwise, it won't. Sorry, I don't know >>>>>> >>>>> much >>>> >>>>> about github and I really am not using it. >>>>>> >>>>>> Cos >>>>>> >>>>>> Can somebody explain to me the merge procedure? >>>>>>>>> >>>>>>>>> 2015-08-12 3:15 GMT-07:00 Artem Shutak <[hidden email]>: >>>>>>>>> >>>>>>>>> Inline. >>>>>>>>>> >>>>>>>>>> On Wed, Aug 12, 2015 at 10:19 AM, Dmitriy Setrakyan < >>>>>>>>>> >>>>>>>>> [hidden email] >>>>>>>> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> On Tue, Aug 11, 2015 at 6:28 AM, Artem Shutak < >>>>>>>>>>> >>>>>>>>>> [hidden email]> >>>>>> >>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> And one more question. Is it mandatory to have possibility >>>>>>>>>>>> >>>>>>>>>>> works >>>>>> >>>>>>> via >>>>>>>> >>>>>>>>> patches if we will have pull-request way for contributions? >>>>>>>>>>>> >>>>>>>>>>>> I'd like to have only one approach. >>>>>>>>>>>> >>>>>>>>>>>> Artem, if possible I would allow 2 approaches and document >>>>>>>>>>> >>>>>>>>>> the 2 >>>> >>>>> approaches >>>>>>>>>> >>>>>>>>>>> on Wiki. >>>>>>>>>>> >>>>>>>>>>> At least it increases support efforts. And if all will use only >>>>>>>>>> >>>>>>>>> one, >>>>>> >>>>>>> then >>>>>>>> >>>>>>>>> there is a big chance that second will not work properly. >>>>>>>>>> >>>>>>>>>> And, to complete patch-way: >>>>>>>>>> - need to split simple "master" builds and "patch" builds on TC >>>>>>>>>> >>>>>>>>> - >>>> >>>>> I >>>>>> >>>>>>> can do >>>>>>>> >>>>>>>>> it by yourself. >>>>>>>>>> - need to implement git-format-patch.bat for Windows users. It's >>>>>>>>>> >>>>>>>>> not >>>>>> >>>>>>> mandatory, all can be done manually by contributors, but it >>>>>>>>>> >>>>>>>>> would >>>> >>>>> be >>>>>> >>>>>>> nice. >>>>>>>> >>>>>>>>> This script can make any Windows user (I'm not :) ). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> One question, does a pull request automatically generate a >>>>>>>>>>> >>>>>>>>>> Jira >>>> >>>>> comment >>>>>>>> >>>>>>>>> (see Spark, Camel)? >>>>>>>>>>> >>>>>>>>>>> I will look at mentioned projects. From my view, by default, >>>>>>>>>> >>>>>>>>> GitHub >>>>>> >>>>>>> know >>>>>>>> >>>>>>>>> nothing about our Jira. So, there's no way to GitHub can add any >>>>>>>>>> >>>>>>>>> comments >>>>>>>> >>>>>>>>> to unknown Jira. >>>>>>>>>> DVCS plugin - it's a standard way to acquaint Jira and GitHub >>>>>>>>>> >>>>>>>>> and >>>> >>>>> it >>>>>> >>>>>>> will >>>>>>>> >>>>>>>>> work pretty nice. >>>>>>>>>> >>>>>>>>>> --Artem-- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -- Artem -- >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Aug 11, 2015 at 4:15 PM, Artem Shutak < >>>>>>>>>>>> >>>>>>>>>>> [hidden email]> >>>>>>>> >>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Igniters, >>>>>>>>>>>>> >>>>>>>>>>>>> I'm working on >>>>>>>>>>>>> >>>>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-1217 >>>>>> >>>>>>> . >>>>>>>> >>>>>>>>> Currently, everyone can fork Mirror of Apache Ignite on >>>>>>>>>>>>> >>>>>>>>>>>> GitHub ( >>>>>> >>>>>>> https://github.com/apache/incubator-ignite), works with >>>>>>>>>>>>> >>>>>>>>>>>> own fork >>>>>> >>>>>>> (create >>>>>>>>>>> >>>>>>>>>>>> branches, commit, pull changes at fork) and then creates a >>>>>>>>>>>>> >>>>>>>>>>>> pull-request >>>>>>>>>> >>>>>>>>>>> to >>>>>>>>>>>> >>>>>>>>>>>>> Mirror of Apache Ignite on GitHub (all changes should be >>>>>>>>>>>>> >>>>>>>>>>>> done in >>>>>> >>>>>>> one >>>>>>>> >>>>>>>>> commit >>>>>>>>>>>> >>>>>>>>>>>>> as in patch-way approach). Then test TC builds will >>>>>>>>>>>>> >>>>>>>>>>>> triggered >>>>>> >>>>>>> automatically. Results can be found by branch filtering by >>>>>>>>>>>>> >>>>>>>>>>>> pattern >>>>>>>> >>>>>>>>> <pull-request-number>/merge. "Merge" suffix here means >>>>>>>>>>>>> >>>>>>>>>>>> pull-request >>>>>>>> >>>>>>>>> merged >>>>>>>>>>>> >>>>>>>>>>>>> with master branch (if pull-request at master branch). >>>>>>>>>>>>> >>>>>>>>>>>>> Notes: >>>>>>>>>>>>> >>>>>>>>>>>>> 1. I tried to use TC plugin for github to see TC result at >>>>>>>>>>>>> >>>>>>>>>>>> pull-request. >>>>>>>>>>> >>>>>>>>>>>> But the plugin works in unexpected way and add comments >>>>>>>>>>>>> >>>>>>>>>>>> not >>>> >>>>> only >>>>>> >>>>>>> to >>>>>>>> >>>>>>>>> pull-requests. Example: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>> https://github.com/apache/incubator-ignite/commit/ae11e9b5aa9af4d0d58e2a16dd3a3331969961df#commitcomment-12635375 >>>> >>>>> . >>>>>>>>>>>>> Maybe someone had this problem before? >>>>>>>>>>>>> >>>>>>>>>>>>> 2. I'm looking for a simple way to add information about >>>>>>>>>>>>> >>>>>>>>>>>> new >>>> >>>>> pull-request >>>>>>>>>>> >>>>>>>>>>>> to associated jira. >>>>>>>>>>>>> The better way to use existing Jira plugin for it - DVCS >>>>>>>>>>>>> >>>>>>>>>>>> plugin ( >>>>>> >>>>> >>>> https://confluence.atlassian.com/display/BITBUCKET/Linking+Bitbucket+and+GitHub+accounts+to+JIRA >>>> >>>>> ). >>>>>>>>>>>> >>>>>>>>>>>>> But I need both: Jira administration rights to configure >>>>>>>>>>>>> >>>>>>>>>>>> the >>>> >>>>> plugin >>>>>>>> >>>>>>>>> and >>>>>>>>>> >>>>>>>>>>> GitHub password for "apache" user. Or I missed something >>>>>>>>>>>>> >>>>>>>>>>>> and we >>>>>> >>>>>>> can't >>>>>>>> >>>>>>>>> use >>>>>>>>>>> >>>>>>>>>>>> this plugin at Apache infrastructure? >>>>>>>>>>>>> Maybe someone can suggest another solution? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Artem. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>> >> > |
Re: IGNITE-1217 TC triggering by github pull-requests
|
|
In reply to this post by dsetrakyan
Although you can, I don't recommend merging the pull request directly from
the contributor's repo into the ASF Git. Normally you wouldn't be interested in preserving their commit history. It might have taken them 2, 5 or 10 commits to implement the contribution, and keeping that history on our side is not useful. Rather, it's cleaner to generate a patch and apply it in ASF Git. At Camel, we include a note "With thanks to John Doe" in the commit message to leave the meritocracy footprint. Raúl. On 14 Aug 2015 01:55, "Dmitriy Setrakyan" <[hidden email]> wrote: > On Thu, Aug 13, 2015 at 5:51 PM, Konstantin Boudnik <[hidden email]> > wrote: > > > On Thu, Aug 13, 2015 at 05:40PM, Alexey Goncharuk wrote: > > > Maybe I miss a good piece of information about how Git works, but I > > always > > > thought that if a pull request is accepted, it will be merged to the > > GitHub > > > mirror of Apache Ignite. How will this change get to the original > Apache > > > git repository? > > > > It won't. github repo is a mirror of Apache git mirror. In order to have > > the > > changes from github PR to be in visible in the github a committer needs > to > > commit it into our Apache repo. > > > > Cos, will the original contributor's name be preserved or should the Ignite > committer add "-author" parameter when committing? > > > > > > Cos > > > > > Can somebody explain to me the merge procedure? > > > > > > 2015-08-12 3:15 GMT-07:00 Artem Shutak <[hidden email]>: > > > > > > > Inline. > > > > > > > > On Wed, Aug 12, 2015 at 10:19 AM, Dmitriy Setrakyan < > > [hidden email] > > > > > > > > > wrote: > > > > > > > > > On Tue, Aug 11, 2015 at 6:28 AM, Artem Shutak < > [hidden email]> > > > > > wrote: > > > > > > > > > > > And one more question. Is it mandatory to have possibility works > > via > > > > > > patches if we will have pull-request way for contributions? > > > > > > > > > > > > I'd like to have only one approach. > > > > > > > > > > > > > > > > Artem, if possible I would allow 2 approaches and document the 2 > > > > approaches > > > > > on Wiki. > > > > > > > > > > > > > At least it increases support efforts. And if all will use only one, > > then > > > > there is a big chance that second will not work properly. > > > > > > > > And, to complete patch-way: > > > > - need to split simple "master" builds and "patch" builds on TC - I > > can do > > > > it by yourself. > > > > - need to implement git-format-patch.bat for Windows users. It's not > > > > mandatory, all can be done manually by contributors, but it would be > > nice. > > > > This script can make any Windows user (I'm not :) ). > > > > > > > > > > > > > > > > > > One question, does a pull request automatically generate a Jira > > comment > > > > > (see Spark, Camel)? > > > > > > > > > > > > > I will look at mentioned projects. From my view, by default, GitHub > > know > > > > nothing about our Jira. So, there's no way to GitHub can add any > > comments > > > > to unknown Jira. > > > > DVCS plugin - it's a standard way to acquaint Jira and GitHub and it > > will > > > > work pretty nice. > > > > > > > > --Artem-- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Artem -- > > > > > > > > > > > > On Tue, Aug 11, 2015 at 4:15 PM, Artem Shutak < > > [hidden email]> > > > > > > wrote: > > > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > I'm working on > https://issues.apache.org/jira/browse/IGNITE-1217 > > . > > > > > > > > > > > > > > Currently, everyone can fork Mirror of Apache Ignite on GitHub > ( > > > > > > > https://github.com/apache/incubator-ignite), works with own > fork > > > > > (create > > > > > > > branches, commit, pull changes at fork) and then creates a > > > > pull-request > > > > > > to > > > > > > > Mirror of Apache Ignite on GitHub (all changes should be done > in > > one > > > > > > commit > > > > > > > as in patch-way approach). Then test TC builds will triggered > > > > > > > automatically. Results can be found by branch filtering by > > pattern > > > > > > > <pull-request-number>/merge. "Merge" suffix here means > > pull-request > > > > > > merged > > > > > > > with master branch (if pull-request at master branch). > > > > > > > > > > > > > > Notes: > > > > > > > > > > > > > > 1. I tried to use TC plugin for github to see TC result at > > > > > pull-request. > > > > > > > But the plugin works in unexpected way and add comments not > only > > to > > > > > > > pull-requests. Example: > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-ignite/commit/ae11e9b5aa9af4d0d58e2a16dd3a3331969961df#commitcomment-12635375 > > > > > > > . > > > > > > > Maybe someone had this problem before? > > > > > > > > > > > > > > 2. I'm looking for a simple way to add information about new > > > > > pull-request > > > > > > > to associated jira. > > > > > > > The better way to use existing Jira plugin for it - DVCS > plugin ( > > > > > > > > > > > > > > > > > > > > > > > > > https://confluence.atlassian.com/display/BITBUCKET/Linking+Bitbucket+and+GitHub+accounts+to+JIRA > > > > > > ). > > > > > > > But I need both: Jira administration rights to configure the > > plugin > > > > and > > > > > > > GitHub password for "apache" user. Or I missed something and we > > can't > > > > > use > > > > > > > this plugin at Apache infrastructure? > > > > > > > Maybe someone can suggest another solution? > > > > > > > > > > > > > > Thanks, > > > > > > > Artem. > > > > > > > > > > > > > > > > > > > > > > > > > |
Re: IGNITE-1217 TC triggering by github pull-requests
|
|
In reply to this post by dsetrakyan
Although you can, I don't recommend merging the pull request directly from
the contributor's Github repo into the ASF Git, as you will preserve their commit history. Normally you wouldn't be interested in doing so, as it might have taken them 2, 5 or 10 commits to implement the contribution, and keeping that history on our side is not useful nor does it provide value. Rather, it's cleaner to generate a patch and apply it in ASF Git. At Camel, we include a note "With thanks to John Doe" in the commit message to leave the meritocracy footprint. Raúl. On 14 Aug 2015 01:55, "Dmitriy Setrakyan" <[hidden email]> wrote: > On Thu, Aug 13, 2015 at 5:51 PM, Konstantin Boudnik <[hidden email]> > wrote: > > > On Thu, Aug 13, 2015 at 05:40PM, Alexey Goncharuk wrote: > > > Maybe I miss a good piece of information about how Git works, but I > > always > > > thought that if a pull request is accepted, it will be merged to the > > GitHub > > > mirror of Apache Ignite. How will this change get to the original > Apache > > > git repository? > > > > It won't. github repo is a mirror of Apache git mirror. In order to have > > the > > changes from github PR to be in visible in the github a committer needs > to > > commit it into our Apache repo. > > > > Cos, will the original contributor's name be preserved or should the Ignite > committer add "-author" parameter when committing? > > > > > > Cos > > > > > Can somebody explain to me the merge procedure? > > > > > > 2015-08-12 3:15 GMT-07:00 Artem Shutak <[hidden email]>: > > > > > > > Inline. > > > > > > > > On Wed, Aug 12, 2015 at 10:19 AM, Dmitriy Setrakyan < > > [hidden email] > > > > > > > > > wrote: > > > > > > > > > On Tue, Aug 11, 2015 at 6:28 AM, Artem Shutak < > [hidden email]> > > > > > wrote: > > > > > > > > > > > And one more question. Is it mandatory to have possibility works > > via > > > > > > patches if we will have pull-request way for contributions? > > > > > > > > > > > > I'd like to have only one approach. > > > > > > > > > > > > > > > > Artem, if possible I would allow 2 approaches and document the 2 > > > > approaches > > > > > on Wiki. > > > > > > > > > > > > > At least it increases support efforts. And if all will use only one, > > then > > > > there is a big chance that second will not work properly. > > > > > > > > And, to complete patch-way: > > > > - need to split simple "master" builds and "patch" builds on TC - I > > can do > > > > it by yourself. > > > > - need to implement git-format-patch.bat for Windows users. It's not > > > > mandatory, all can be done manually by contributors, but it would be > > nice. > > > > This script can make any Windows user (I'm not :) ). > > > > > > > > > > > > > > > > > > One question, does a pull request automatically generate a Jira > > comment > > > > > (see Spark, Camel)? > > > > > > > > > > > > > I will look at mentioned projects. From my view, by default, GitHub > > know > > > > nothing about our Jira. So, there's no way to GitHub can add any > > comments > > > > to unknown Jira. > > > > DVCS plugin - it's a standard way to acquaint Jira and GitHub and it > > will > > > > work pretty nice. > > > > > > > > --Artem-- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Artem -- > > > > > > > > > > > > On Tue, Aug 11, 2015 at 4:15 PM, Artem Shutak < > > [hidden email]> > > > > > > wrote: > > > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > I'm working on > https://issues.apache.org/jira/browse/IGNITE-1217 > > . > > > > > > > > > > > > > > Currently, everyone can fork Mirror of Apache Ignite on GitHub > ( > > > > > > > https://github.com/apache/incubator-ignite), works with own > fork > > > > > (create > > > > > > > branches, commit, pull changes at fork) and then creates a > > > > pull-request > > > > > > to > > > > > > > Mirror of Apache Ignite on GitHub (all changes should be done > in > > one > > > > > > commit > > > > > > > as in patch-way approach). Then test TC builds will triggered > > > > > > > automatically. Results can be found by branch filtering by > > pattern > > > > > > > <pull-request-number>/merge. "Merge" suffix here means > > pull-request > > > > > > merged > > > > > > > with master branch (if pull-request at master branch). > > > > > > > > > > > > > > Notes: > > > > > > > > > > > > > > 1. I tried to use TC plugin for github to see TC result at > > > > > pull-request. > > > > > > > But the plugin works in unexpected way and add comments not > only > > to > > > > > > > pull-requests. Example: > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-ignite/commit/ae11e9b5aa9af4d0d58e2a16dd3a3331969961df#commitcomment-12635375 > > > > > > > . > > > > > > > Maybe someone had this problem before? > > > > > > > > > > > > > > 2. I'm looking for a simple way to add information about new > > > > > pull-request > > > > > > > to associated jira. > > > > > > > The better way to use existing Jira plugin for it - DVCS > plugin ( > > > > > > > > > > > > > > > > > > > > > > > > > https://confluence.atlassian.com/display/BITBUCKET/Linking+Bitbucket+and+GitHub+accounts+to+JIRA > > > > > > ). > > > > > > > But I need both: Jira administration rights to configure the > > plugin > > > > and > > > > > > > GitHub password for "apache" user. Or I missed something and we > > can't > > > > > use > > > > > > > this plugin at Apache infrastructure? > > > > > > > Maybe someone can suggest another solution? > > > > > > > > > > > > > > Thanks, > > > > > > > Artem. > > > > > > > > > > > > > > > > > > > > > > > > > |
Re: IGNITE-1217 TC triggering by github pull-requests
|
|
Agree. Actually, it's up to a committer, I think. I just don't see a reason
to have one-commit-per-pull-request requirement. From my understanding, this is not how pull requests work. BTW, I just tested the process and it works like a charm. I like it! And I'm about to merge your contributions, Raul ;-) -Val On Fri, Aug 14, 2015 at 3:34 PM, Raul Kripalani <[hidden email]> wrote: > Although you can, I don't recommend merging the pull request directly from > the contributor's Github repo into the ASF Git, as you will preserve their > commit history. > > Normally you wouldn't be interested in doing so, as it might have taken > them 2, 5 or 10 commits to implement the contribution, and keeping that > history on our side is not useful nor does it provide value. > > Rather, it's cleaner to generate a patch and apply it in ASF Git. > > At Camel, we include a note "With thanks to John Doe" in the commit message > to leave the meritocracy footprint. > > Raúl. > On 14 Aug 2015 01:55, "Dmitriy Setrakyan" <[hidden email]> wrote: > > > On Thu, Aug 13, 2015 at 5:51 PM, Konstantin Boudnik <[hidden email]> > > wrote: > > > > > On Thu, Aug 13, 2015 at 05:40PM, Alexey Goncharuk wrote: > > > > Maybe I miss a good piece of information about how Git works, but I > > > always > > > > thought that if a pull request is accepted, it will be merged to the > > > GitHub > > > > mirror of Apache Ignite. How will this change get to the original > > Apache > > > > git repository? > > > > > > It won't. github repo is a mirror of Apache git mirror. In order to > have > > > the > > > changes from github PR to be in visible in the github a committer needs > > to > > > commit it into our Apache repo. > > > > > > > Cos, will the original contributor's name be preserved or should the > Ignite > > committer add "-author" parameter when committing? > > > > > > > > > > Cos > > > > > > > Can somebody explain to me the merge procedure? > > > > > > > > 2015-08-12 3:15 GMT-07:00 Artem Shutak <[hidden email]>: > > > > > > > > > Inline. > > > > > > > > > > On Wed, Aug 12, 2015 at 10:19 AM, Dmitriy Setrakyan < > > > [hidden email] > > > > > > > > > > > wrote: > > > > > > > > > > > On Tue, Aug 11, 2015 at 6:28 AM, Artem Shutak < > > [hidden email]> > > > > > > wrote: > > > > > > > > > > > > > And one more question. Is it mandatory to have possibility > works > > > via > > > > > > > patches if we will have pull-request way for contributions? > > > > > > > > > > > > > > I'd like to have only one approach. > > > > > > > > > > > > > > > > > > > Artem, if possible I would allow 2 approaches and document the 2 > > > > > approaches > > > > > > on Wiki. > > > > > > > > > > > > > > > > At least it increases support efforts. And if all will use only > one, > > > then > > > > > there is a big chance that second will not work properly. > > > > > > > > > > And, to complete patch-way: > > > > > - need to split simple "master" builds and "patch" builds on TC - I > > > can do > > > > > it by yourself. > > > > > - need to implement git-format-patch.bat for Windows users. It's > not > > > > > mandatory, all can be done manually by contributors, but it would > be > > > nice. > > > > > This script can make any Windows user (I'm not :) ). > > > > > > > > > > > > > > > > > > > > > > One question, does a pull request automatically generate a Jira > > > comment > > > > > > (see Spark, Camel)? > > > > > > > > > > > > > > > > I will look at mentioned projects. From my view, by default, GitHub > > > know > > > > > nothing about our Jira. So, there's no way to GitHub can add any > > > comments > > > > > to unknown Jira. > > > > > DVCS plugin - it's a standard way to acquaint Jira and GitHub and > it > > > will > > > > > work pretty nice. > > > > > > > > > > --Artem-- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Artem -- > > > > > > > > > > > > > > On Tue, Aug 11, 2015 at 4:15 PM, Artem Shutak < > > > [hidden email]> > > > > > > > wrote: > > > > > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > > > I'm working on > > https://issues.apache.org/jira/browse/IGNITE-1217 > > > . > > > > > > > > > > > > > > > > Currently, everyone can fork Mirror of Apache Ignite on > GitHub > > ( > > > > > > > > https://github.com/apache/incubator-ignite), works with own > > fork > > > > > > (create > > > > > > > > branches, commit, pull changes at fork) and then creates a > > > > > pull-request > > > > > > > to > > > > > > > > Mirror of Apache Ignite on GitHub (all changes should be done > > in > > > one > > > > > > > commit > > > > > > > > as in patch-way approach). Then test TC builds will triggered > > > > > > > > automatically. Results can be found by branch filtering by > > > pattern > > > > > > > > <pull-request-number>/merge. "Merge" suffix here means > > > pull-request > > > > > > > merged > > > > > > > > with master branch (if pull-request at master branch). > > > > > > > > > > > > > > > > Notes: > > > > > > > > > > > > > > > > 1. I tried to use TC plugin for github to see TC result at > > > > > > pull-request. > > > > > > > > But the plugin works in unexpected way and add comments not > > only > > > to > > > > > > > > pull-requests. Example: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-ignite/commit/ae11e9b5aa9af4d0d58e2a16dd3a3331969961df#commitcomment-12635375 > > > > > > > > . > > > > > > > > Maybe someone had this problem before? > > > > > > > > > > > > > > > > 2. I'm looking for a simple way to add information about new > > > > > > pull-request > > > > > > > > to associated jira. > > > > > > > > The better way to use existing Jira plugin for it - DVCS > > plugin ( > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://confluence.atlassian.com/display/BITBUCKET/Linking+Bitbucket+and+GitHub+accounts+to+JIRA > > > > > > > ). > > > > > > > > But I need both: Jira administration rights to configure the > > > plugin > > > > > and > > > > > > > > GitHub password for "apache" user. Or I missed something and > we > > > can't > > > > > > use > > > > > > > > this plugin at Apache infrastructure? > > > > > > > > Maybe someone can suggest another solution? > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Artem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |
Re: IGNITE-1217 TC triggering by github pull-requests
|
|
On 14 Aug 2015 23:41, "Valentin Kulichenko" <[hidden email]>
wrote: > > Agree. Actually, it's up to a committer, I think. I just don't see a reason > to have one-commit-per-pull-request requirement. From my understanding, > this is not how pull requests work. Yeah, in reality it depends on the quality of the history at the contributor's repo. If the commits are well structured, well described and they follow best practices, I don't see why not merge it with a pull. > BTW, I just tested the process and it works like a charm. I like it! And > I'm about to merge your contributions, Raul ;-) Woohoo! Party time! > -Val > > On Fri, Aug 14, 2015 at 3:34 PM, Raul Kripalani <[hidden email]> wrote: > > > Although you can, I don't recommend merging the pull request directly from > > the contributor's Github repo into the ASF Git, as you will preserve their > > commit history. > > > > Normally you wouldn't be interested in doing so, as it might have taken > > them 2, 5 or 10 commits to implement the contribution, and keeping that > > history on our side is not useful nor does it provide value. > > > > Rather, it's cleaner to generate a patch and apply it in ASF Git. > > > > At Camel, we include a note "With thanks to John Doe" in the commit message > > to leave the meritocracy footprint. > > > > Raúl. > > On 14 Aug 2015 01:55, "Dmitriy Setrakyan" <[hidden email]> wrote: > > > > > On Thu, Aug 13, 2015 at 5:51 PM, Konstantin Boudnik <[hidden email]> > > > wrote: > > > > > > > On Thu, Aug 13, 2015 at 05:40PM, Alexey Goncharuk wrote: > > > > > Maybe I miss a good piece of information about how Git works, but > > > > always > > > > > thought that if a pull request is accepted, it will be merged to the > > > > GitHub > > > > > mirror of Apache Ignite. How will this change get to the original > > > Apache > > > > > git repository? > > > > > > > > It won't. github repo is a mirror of Apache git mirror. In order to > > have > > > > the > > > > changes from github PR to be in visible in the github a committer needs > > > to > > > > commit it into our Apache repo. > > > > > > > > > > Cos, will the original contributor's name be preserved or should the > > Ignite > > > committer add "-author" parameter when committing? > > > > > > > > > > > > > > Cos > > > > > > > > > Can somebody explain to me the merge procedure? > > > > > > > > > > 2015-08-12 3:15 GMT-07:00 Artem Shutak <[hidden email]>: > > > > > > > > > > > Inline. > > > > > > > > > > > > On Wed, Aug 12, 2015 at 10:19 AM, Dmitriy Setrakyan < > > > > [hidden email] > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > On Tue, Aug 11, 2015 at 6:28 AM, Artem Shutak < > > > [hidden email]> > > > > > > > wrote: > > > > > > > > > > > > > > > And one more question. Is it mandatory to have possibility > > works > > > > via > > > > > > > > patches if we will have pull-request way for contributions? > > > > > > > > > > > > > > > > I'd like to have only one approach. > > > > > > > > > > > > > > > > > > > > > > Artem, if possible I would allow 2 approaches and document > > > > > > approaches > > > > > > > on Wiki. > > > > > > > > > > > > > > > > > > > At least it increases support efforts. And if all will use only > > one, > > > > then > > > > > > there is a big chance that second will not work properly. > > > > > > > > > > > > And, to complete patch-way: > > > > > > - need to split simple "master" builds and "patch" builds on TC > > > > can do > > > > > > it by yourself. > > > > > > - need to implement git-format-patch.bat for Windows users. It's > > not > > > > > > mandatory, all can be done manually by contributors, but it would > > be > > > > nice. > > > > > > This script can make any Windows user (I'm not :) ). > > > > > > > > > > > > > > > > > > > > > > > > > > One question, does a pull request automatically generate a Jira > > > > comment > > > > > > > (see Spark, Camel)? > > > > > > > > > > > > > > > > > > > I will look at mentioned projects. From my view, by default, GitHub > > > > know > > > > > > nothing about our Jira. So, there's no way to GitHub can add any > > > > comments > > > > > > to unknown Jira. > > > > > > DVCS plugin - it's a standard way to acquaint Jira and GitHub and > > it > > > > will > > > > > > work pretty nice. > > > > > > > > > > > > --Artem-- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Artem -- > > > > > > > > > > > > > > > > On Tue, Aug 11, 2015 at 4:15 PM, Artem Shutak < > > > > [hidden email]> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > > > > > I'm working on > > > https://issues.apache.org/jira/browse/IGNITE-1217 > > > > . > > > > > > > > > > > > > > > > > > Currently, everyone can fork Mirror of Apache Ignite on > > GitHub > > > ( > > > > > > > > > https://github.com/apache/incubator-ignite), works with > > > fork > > > > > > > (create > > > > > > > > > branches, commit, pull changes at fork) and then creates a > > > > > > pull-request > > > > > > > > to > > > > > > > > > Mirror of Apache Ignite on GitHub (all changes should be done > > > in > > > > one > > > > > > > > commit > > > > > > > > > as in patch-way approach). Then test TC builds will triggered > > > > > > > > > automatically. Results can be found by branch filtering by > > > > pattern > > > > > > > > > <pull-request-number>/merge. "Merge" suffix here means > > > > pull-request > > > > > > > > merged > > > > > > > > > with master branch (if pull-request at master branch). > > > > > > > > > > > > > > > > > > Notes: > > > > > > > > > > > > > > > > > > 1. I tried to use TC plugin for github to see TC result at > > > > > > > pull-request. > > > > > > > > > But the plugin works in unexpected way and add comments > > > only > > > > to > > > > > > > > > pull-requests. Example: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > . > > > > > > > > > Maybe someone had this problem before? > > > > > > > > > > > > > > > > > > 2. I'm looking for a simple way to add information about new > > > > > > > pull-request > > > > > > > > > to associated jira. > > > > > > > > > The better way to use existing Jira plugin for it - DVCS > > > plugin ( > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ). > > > > > > > > > But I need both: Jira administration rights to configure the > > > > plugin > > > > > > and > > > > > > > > > GitHub password for "apache" user. Or I missed something and > > we > > > > can't > > > > > > > use > > > > > > > > > this plugin at Apache infrastructure? > > > > > > > > > Maybe someone can suggest another solution? > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Artem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |
Re: IGNITE-1217 TC triggering by github pull-requests
|
|
Guys,
I updated the section about pull requests on Wiki. Please take a look and provide your comments if you have any. -Val On Fri, Aug 14, 2015 at 3:46 PM, Raul Kripalani <[hidden email]> wrote: > On 14 Aug 2015 23:41, "Valentin Kulichenko" <[hidden email] > > > wrote: > > > > Agree. Actually, it's up to a committer, I think. I just don't see a > reason > > to have one-commit-per-pull-request requirement. From my understanding, > > this is not how pull requests work. > > Yeah, in reality it depends on the quality of the history at the > contributor's repo. If the commits are well structured, well described and > they follow best practices, I don't see why not merge it with a pull. > > > BTW, I just tested the process and it works like a charm. I like it! And > > I'm about to merge your contributions, Raul ;-) > > Woohoo! Party time! > > > -Val > > > > On Fri, Aug 14, 2015 at 3:34 PM, Raul Kripalani <[hidden email]> > wrote: > > > > > Although you can, I don't recommend merging the pull request directly > from > > > the contributor's Github repo into the ASF Git, as you will preserve > their > > > commit history. > > > > > > Normally you wouldn't be interested in doing so, as it might have taken > > > them 2, 5 or 10 commits to implement the contribution, and keeping that > > > history on our side is not useful nor does it provide value. > > > > > > Rather, it's cleaner to generate a patch and apply it in ASF Git. > > > > > > At Camel, we include a note "With thanks to John Doe" in the commit > message > > > to leave the meritocracy footprint. > > > > > > Raúl. > > > On 14 Aug 2015 01:55, "Dmitriy Setrakyan" <[hidden email]> > wrote: > > > > > > > On Thu, Aug 13, 2015 at 5:51 PM, Konstantin Boudnik <[hidden email]> > > > > wrote: > > > > > > > > > On Thu, Aug 13, 2015 at 05:40PM, Alexey Goncharuk wrote: > > > > > > Maybe I miss a good piece of information about how Git works, but > I > > > > > always > > > > > > thought that if a pull request is accepted, it will be merged to > the > > > > > GitHub > > > > > > mirror of Apache Ignite. How will this change get to the original > > > > Apache > > > > > > git repository? > > > > > > > > > > It won't. github repo is a mirror of Apache git mirror. In order to > > > have > > > > > the > > > > > changes from github PR to be in visible in the github a committer > needs > > > > to > > > > > commit it into our Apache repo. > > > > > > > > > > > > > Cos, will the original contributor's name be preserved or should the > > > Ignite > > > > committer add "-author" parameter when committing? > > > > > > > > > > > > > > > > > > Cos > > > > > > > > > > > Can somebody explain to me the merge procedure? > > > > > > > > > > > > 2015-08-12 3:15 GMT-07:00 Artem Shutak <[hidden email]>: > > > > > > > > > > > > > Inline. > > > > > > > > > > > > > > On Wed, Aug 12, 2015 at 10:19 AM, Dmitriy Setrakyan < > > > > > [hidden email] > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > On Tue, Aug 11, 2015 at 6:28 AM, Artem Shutak < > > > > [hidden email]> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > And one more question. Is it mandatory to have possibility > > > works > > > > > via > > > > > > > > > patches if we will have pull-request way for contributions? > > > > > > > > > > > > > > > > > > I'd like to have only one approach. > > > > > > > > > > > > > > > > > > > > > > > > > Artem, if possible I would allow 2 approaches and document > the 2 > > > > > > > approaches > > > > > > > > on Wiki. > > > > > > > > > > > > > > > > > > > > > > At least it increases support efforts. And if all will use only > > > one, > > > > > then > > > > > > > there is a big chance that second will not work properly. > > > > > > > > > > > > > > And, to complete patch-way: > > > > > > > - need to split simple "master" builds and "patch" builds on TC > - I > > > > > can do > > > > > > > it by yourself. > > > > > > > - need to implement git-format-patch.bat for Windows users. > It's > > > not > > > > > > > mandatory, all can be done manually by contributors, but it > would > > > be > > > > > nice. > > > > > > > This script can make any Windows user (I'm not :) ). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One question, does a pull request automatically generate a > Jira > > > > > comment > > > > > > > > (see Spark, Camel)? > > > > > > > > > > > > > > > > > > > > > > I will look at mentioned projects. From my view, by default, > GitHub > > > > > know > > > > > > > nothing about our Jira. So, there's no way to GitHub can add > any > > > > > comments > > > > > > > to unknown Jira. > > > > > > > DVCS plugin - it's a standard way to acquaint Jira and GitHub > and > > > it > > > > > will > > > > > > > work pretty nice. > > > > > > > > > > > > > > --Artem-- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Artem -- > > > > > > > > > > > > > > > > > > On Tue, Aug 11, 2015 at 4:15 PM, Artem Shutak < > > > > > [hidden email]> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > > > > > > > I'm working on > > > > https://issues.apache.org/jira/browse/IGNITE-1217 > > > > > . > > > > > > > > > > > > > > > > > > > > Currently, everyone can fork Mirror of Apache Ignite on > > > GitHub > > > > ( > > > > > > > > > > https://github.com/apache/incubator-ignite), works with > own > > > > fork > > > > > > > > (create > > > > > > > > > > branches, commit, pull changes at fork) and then creates > a > > > > > > > pull-request > > > > > > > > > to > > > > > > > > > > Mirror of Apache Ignite on GitHub (all changes should be > done > > > > in > > > > > one > > > > > > > > > commit > > > > > > > > > > as in patch-way approach). Then test TC builds will > triggered > > > > > > > > > > automatically. Results can be found by branch filtering > by > > > > > pattern > > > > > > > > > > <pull-request-number>/merge. "Merge" suffix here means > > > > > pull-request > > > > > > > > > merged > > > > > > > > > > with master branch (if pull-request at master branch). > > > > > > > > > > > > > > > > > > > > Notes: > > > > > > > > > > > > > > > > > > > > 1. I tried to use TC plugin for github to see TC result > at > > > > > > > > pull-request. > > > > > > > > > > But the plugin works in unexpected way and add comments > not > > > > only > > > > > to > > > > > > > > > > pull-requests. Example: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-ignite/commit/ae11e9b5aa9af4d0d58e2a16dd3a3331969961df#commitcomment-12635375 > > > > > > > > > > . > > > > > > > > > > Maybe someone had this problem before? > > > > > > > > > > > > > > > > > > > > 2. I'm looking for a simple way to add information about > new > > > > > > > > pull-request > > > > > > > > > > to associated jira. > > > > > > > > > > The better way to use existing Jira plugin for it - DVCS > > > > plugin ( > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://confluence.atlassian.com/display/BITBUCKET/Linking+Bitbucket+and+GitHub+accounts+to+JIRA > > > > > > > > > ). > > > > > > > > > > But I need both: Jira administration rights to configure > the > > > > > plugin > > > > > > > and > > > > > > > > > > GitHub password for "apache" user. Or I missed something > and > > > we > > > > > can't > > > > > > > > use > > > > > > > > > > this plugin at Apache infrastructure? > > > > > > > > > > Maybe someone can suggest another solution? > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Artem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |
Re: IGNITE-1217 TC triggering by github pull-requests
|
|
In reply to this post by Valentin Kulichenko
On Fri, Aug 14, 2015 at 03:23PM, Valentin Kulichenko wrote:
> Artem, > > Why do we need a requirement about one commit per pull request? I > understand that we should should avoid garbage in history and properly deal > with merges from master. But I don't see anything wrong with 2-3 commits in > a PR if they are meaningful. E.g., "implemented initial version" -> "fixed > failures in tests" -> "addressed comments from a committer". They should > just contain good comments and (probably) corresponding JIRA ticket number. Because such incremental commits for the same JIRA have two properties: - they are largely irrelevant and lack of substance for anyone but their author - they make later navigation through the history a royal PITA because you never know if this JIRA had one commit or six Cos > In your process (if I understood everything correctly) we will create two > PRs for each feature. This looks weird and confusing for me. And I really > don't understand what issue we're trying to solve here. > > I think we should take a look at Spark .py script that can be found here: > https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-HowtoMergeaPullRequest. > It looks like they already addressed and automated everything we discuss > here. > > Thoughts? > > -Val > > On Fri, Aug 14, 2015 at 7:03 AM, Denis Magda <[hidden email]> wrote: > > > Artem, > > > > Seems that TC doesn't write down comments into a corresponding JIRA issue > > for branches that have 'dev' suffix (like 'ignite-xxx-dev'). > > > > I've created a pull-request to merge from 'ignite-1241-dev': > > https://github.com/apache/incubator-ignite/pull/19 > > > > I've received an e-mail saying that the request has been received and I > > see that TC triggered the request for validation. > > However, there is no any info left regarding this in a corresponding > > ticket: > > https://issues.apache.org/jira/browse/IGNITE-1241 > > > > Meanwhile, here I see that such info from GitHub Bot: > > https://issues.apache.org/jira/browse/IGNITE-1203 > > > > In addition I have one more thing to clarify. > > When TC ends validating my changes will it send links to tests' results > > over email or to JIRA ticket? > > Cause as you know TC cleans 'active branches' history and I guess that it > > won't be easy for me to find the results on TC in a couple of days. > > > > -- > > Denis > > > > > > On 8/14/2015 1:30 PM, Artem Shutak wrote: > > > >> Alexey, > >> > >> You are right and big thanks for the diagram on the wiki! > >> > >> In bounds of IGNITE-1217 > >> <https://issues.apache.org/jira/browse/IGNITE-1217> I've > >> created a script for commiters (see patch). You need to point to the > >> script > >> a contributor_github_user_name and a branch_name_with_contribution. The > >> script just fetchs a remote repository (by contributor_github_user_name) > >> and cherry-picks last commit from this branch to local master - it stores > >> commit author information. So, the commiter can push master at apache git. > >> > >> In this case we have one requirement: a pull-request should have only one > >> commit (as with patches). > >> > >> I've mention next model of development at fork (see steps below). But now, > >> I see it has too many steps. I will think about more simple way. > >> 1. Preparation (need to configure once): > >> > >> git remote add apache > >> https://git-wip-us.apache.org/repos/asf/incubator-ignite > >> git remote my_fork https://github.com/<github_uname>/incubator-ignite.git > >> > >> 2. Forking on jira ignite-xxxx > >> # Update local master from apache repo > >> git checkout master > >> git pull apache master > >> > >> # Create new development branch for the ticket. > >> git checkout -b ignite-xxxx-dev > >> > >> # Some development here with many commits at ignite-xxxx-dev. > >> git commit -a -m 'ignite-xxxx: Intermediate commit 1' > >> ... > >> git commit -a -m 'ignite-xxxx: Intermediate commit 100' > >> > >> # Push at fork > >> git push my_fork ignite-xxxx-dev > >> > >> Now a pull-request can be created. TC will be triggered. To fix some > >> something and rerun TC, you need just fix it at ignite-xxxx-dev and push > >> to > >> fork again, TC will be triggered again for new commit. > >> > >> When TC is green, it needs to create 'final' pull-request branch with one > >> commit. For it: > >> # Update local master from apache repo > >> git checkout master > >> git pull apache master > >> > >> # Create a final pull-request branch for the ticket. > >> git checkout -b ignite-xxxx > >> > >> # Squash all changes at one commit. > >> git merge --squash ignite-xxxx-dev > >> git commit -a -m 'ignite-xxxx: Implemented' > >> > >> Then need to push it to fork and open new pull-request. > >> > >> > >> -- Artem -- > >> > >> On Fri, Aug 14, 2015 at 5:30 AM, Alexey Goncharuk < > >> [hidden email]> wrote: > >> > >> I forgot that the mailing list takes out all formatting, the diagram meant > >>> to be in a monospaced font :) > >>> > >>> I added it to Ignite wiki: > >>> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute > >>> > >>> 2015-08-13 19:22 GMT-07:00 Alexey Goncharuk <[hidden email] > >>> >: > >>> > >>> While the process of a pull-request creation and CI run is clear for, the > >>>> whole cycle from start to end is still fuzzy. Let me summarize my > >>>> understanding and correct me if I got something wrong. > >>>> > >>>> For any committer/contributor John Doe we will have the following > >>>> structure: > >>>> > >>>> +------------+ +---------------+ > >>>> +-----------------+ > >>>> | | replica | | fork | > >>>> | > >>>> | Apache Git | ==========> | GitHub Mirror | ---------> | John Doe's > >>>> > >>> Fork > >>> > >>>> | > >>>> | | | | | > >>>> | > >>>> +------------+ +---------------+ > >>>> +-----------------+ > >>>> ^ ^ > >>>> | | > >>>> | | > >>>> | > >>>> +-----------------+ > >>>> | *Apache Git remote handle for committers* | > >>>> | > >>>> +------------------------------------------------| Local > >>>> clone > >>>> | > >>>> | > >>>> | > >>>> > >>>> +-----------------+ > >>>> Development is going in the JD's fork and at some point he thinks that > >>>> > >>> the > >>> > >>>> feature is ready to be tested by CI. > >>>> > >>>> He creates a pull request. Usually it takes more than one iteration to > >>>> have a successful CI run, but each pull request sends an e-mail to the > >>>> > >>> dev > >>> > >>>> list. I think we should have some mechanism allowing to differentiate > >>>> "work" pull requests and final pull requests that passed CI and should > >>>> be > >>>> reviewed by a committer. We also need to create (maybe) a maven profile > >>>> with a set of quick tests that cover as much functionality as possible, > >>>> > >>> so > >>> > >>>> that a developer could run it locally before submitting a request to the > >>>> > >>> CI. > >>> > >>>> Let's say now the pull request is approved. If the pull request was > >>>> submitted by a contributor, a committer should pull it to it's local > >>>> > >>> clone. > >>> > >>>> Then commit is pushed to the apache git repository. I glanced through > >>>> the > >>>> Apache Spark development process document [1] and it seems that we > >>>> should > >>>> have a similar script that will properly process commits (squash or > >>>> whatever we need) before the push. > >>>> > >>>> Assuming my understanding is correct and the minor things I mentioned > >>>> above are addressed, I like the new process :) > >>>> > >>>> [1] > >>>> https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark > >>>> > >>>> > >>>> 2015-08-13 18:13 GMT-07:00 Konstantin Boudnik <[hidden email]>: > >>>> > >>>> On Thu, Aug 13, 2015 at 05:54PM, Dmitriy Setrakyan wrote: > >>>>> > >>>>>> On Thu, Aug 13, 2015 at 5:51 PM, Konstantin Boudnik <[hidden email]> > >>>>>> > >>>>> wrote: > >>>>> > >>>>>> On Thu, Aug 13, 2015 at 05:40PM, Alexey Goncharuk wrote: > >>>>>>> > >>>>>>>> Maybe I miss a good piece of information about how Git works, but > >>>>>>>> > >>>>>>> I > >>> > >>>> always > >>>>>>> > >>>>>>>> thought that if a pull request is accepted, it will be merged to > >>>>>>>> > >>>>>>> the > >>> > >>>> GitHub > >>>>>>> > >>>>>>>> mirror of Apache Ignite. How will this change get to the original > >>>>>>>> > >>>>>>> Apache > >>>>> > >>>>>> git repository? > >>>>>>>> > >>>>>>> It won't. github repo is a mirror of Apache git mirror. In order to > >>>>>>> > >>>>>> have > >>>>> > >>>>>> the > >>>>>>> changes from github PR to be in visible in the github a committer > >>>>>>> > >>>>>> needs to > >>>>> > >>>>>> commit it into our Apache repo. > >>>>>>> > >>>>>>> Cos, will the original contributor's name be preserved or should the > >>>>>> > >>>>> Ignite > >>>>> > >>>>>> committer add "-author" parameter when committing? > >>>>>> > >>>>> It depends on how the patch file was made. If 'git format-patch' was > >>>>> > >>>> used > >>> > >>>> then > >>>>> the name will be preserved. Otherwise, it won't. Sorry, I don't know > >>>>> > >>>> much > >>> > >>>> about github and I really am not using it. > >>>>> > >>>>> Cos > >>>>> > >>>>> Can somebody explain to me the merge procedure? > >>>>>>>> > >>>>>>>> 2015-08-12 3:15 GMT-07:00 Artem Shutak <[hidden email]>: > >>>>>>>> > >>>>>>>> Inline. > >>>>>>>>> > >>>>>>>>> On Wed, Aug 12, 2015 at 10:19 AM, Dmitriy Setrakyan < > >>>>>>>>> > >>>>>>>> [hidden email] > >>>>>>> > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> On Tue, Aug 11, 2015 at 6:28 AM, Artem Shutak < > >>>>>>>>>> > >>>>>>>>> [hidden email]> > >>>>> > >>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> And one more question. Is it mandatory to have possibility > >>>>>>>>>>> > >>>>>>>>>> works > >>>>> > >>>>>> via > >>>>>>> > >>>>>>>> patches if we will have pull-request way for contributions? > >>>>>>>>>>> > >>>>>>>>>>> I'd like to have only one approach. > >>>>>>>>>>> > >>>>>>>>>>> Artem, if possible I would allow 2 approaches and document > >>>>>>>>>> > >>>>>>>>> the 2 > >>> > >>>> approaches > >>>>>>>>> > >>>>>>>>>> on Wiki. > >>>>>>>>>> > >>>>>>>>>> At least it increases support efforts. And if all will use only > >>>>>>>>> > >>>>>>>> one, > >>>>> > >>>>>> then > >>>>>>> > >>>>>>>> there is a big chance that second will not work properly. > >>>>>>>>> > >>>>>>>>> And, to complete patch-way: > >>>>>>>>> - need to split simple "master" builds and "patch" builds on TC > >>>>>>>>> > >>>>>>>> - > >>> > >>>> I > >>>>> > >>>>>> can do > >>>>>>> > >>>>>>>> it by yourself. > >>>>>>>>> - need to implement git-format-patch.bat for Windows users. It's > >>>>>>>>> > >>>>>>>> not > >>>>> > >>>>>> mandatory, all can be done manually by contributors, but it > >>>>>>>>> > >>>>>>>> would > >>> > >>>> be > >>>>> > >>>>>> nice. > >>>>>>> > >>>>>>>> This script can make any Windows user (I'm not :) ). > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> One question, does a pull request automatically generate a > >>>>>>>>>> > >>>>>>>>> Jira > >>> > >>>> comment > >>>>>>> > >>>>>>>> (see Spark, Camel)? > >>>>>>>>>> > >>>>>>>>>> I will look at mentioned projects. From my view, by default, > >>>>>>>>> > >>>>>>>> GitHub > >>>>> > >>>>>> know > >>>>>>> > >>>>>>>> nothing about our Jira. So, there's no way to GitHub can add any > >>>>>>>>> > >>>>>>>> comments > >>>>>>> > >>>>>>>> to unknown Jira. > >>>>>>>>> DVCS plugin - it's a standard way to acquaint Jira and GitHub > >>>>>>>>> > >>>>>>>> and > >>> > >>>> it > >>>>> > >>>>>> will > >>>>>>> > >>>>>>>> work pretty nice. > >>>>>>>>> > >>>>>>>>> --Artem-- > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -- Artem -- > >>>>>>>>>>> > >>>>>>>>>>> On Tue, Aug 11, 2015 at 4:15 PM, Artem Shutak < > >>>>>>>>>>> > >>>>>>>>>> [hidden email]> > >>>>>>> > >>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> Igniters, > >>>>>>>>>>>> > >>>>>>>>>>>> I'm working on > >>>>>>>>>>>> > >>>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-1217 > >>>>> > >>>>>> . > >>>>>>> > >>>>>>>> Currently, everyone can fork Mirror of Apache Ignite on > >>>>>>>>>>>> > >>>>>>>>>>> GitHub ( > >>>>> > >>>>>> https://github.com/apache/incubator-ignite), works with > >>>>>>>>>>>> > >>>>>>>>>>> own fork > >>>>> > >>>>>> (create > >>>>>>>>>> > >>>>>>>>>>> branches, commit, pull changes at fork) and then creates a > >>>>>>>>>>>> > >>>>>>>>>>> pull-request > >>>>>>>>> > >>>>>>>>>> to > >>>>>>>>>>> > >>>>>>>>>>>> Mirror of Apache Ignite on GitHub (all changes should be > >>>>>>>>>>>> > >>>>>>>>>>> done in > >>>>> > >>>>>> one > >>>>>>> > >>>>>>>> commit > >>>>>>>>>>> > >>>>>>>>>>>> as in patch-way approach). Then test TC builds will > >>>>>>>>>>>> > >>>>>>>>>>> triggered > >>>>> > >>>>>> automatically. Results can be found by branch filtering by > >>>>>>>>>>>> > >>>>>>>>>>> pattern > >>>>>>> > >>>>>>>> <pull-request-number>/merge. "Merge" suffix here means > >>>>>>>>>>>> > >>>>>>>>>>> pull-request > >>>>>>> > >>>>>>>> merged > >>>>>>>>>>> > >>>>>>>>>>>> with master branch (if pull-request at master branch). > >>>>>>>>>>>> > >>>>>>>>>>>> Notes: > >>>>>>>>>>>> > >>>>>>>>>>>> 1. I tried to use TC plugin for github to see TC result at > >>>>>>>>>>>> > >>>>>>>>>>> pull-request. > >>>>>>>>>> > >>>>>>>>>>> But the plugin works in unexpected way and add comments > >>>>>>>>>>>> > >>>>>>>>>>> not > >>> > >>>> only > >>>>> > >>>>>> to > >>>>>>> > >>>>>>>> pull-requests. Example: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>> https://github.com/apache/incubator-ignite/commit/ae11e9b5aa9af4d0d58e2a16dd3a3331969961df#commitcomment-12635375 > >>> > >>>> . > >>>>>>>>>>>> Maybe someone had this problem before? > >>>>>>>>>>>> > >>>>>>>>>>>> 2. I'm looking for a simple way to add information about > >>>>>>>>>>>> > >>>>>>>>>>> new > >>> > >>>> pull-request > >>>>>>>>>> > >>>>>>>>>>> to associated jira. > >>>>>>>>>>>> The better way to use existing Jira plugin for it - DVCS > >>>>>>>>>>>> > >>>>>>>>>>> plugin ( > >>>>> > >>>> > >>> https://confluence.atlassian.com/display/BITBUCKET/Linking+Bitbucket+and+GitHub+accounts+to+JIRA > >>> > >>>> ). > >>>>>>>>>>> > >>>>>>>>>>>> But I need both: Jira administration rights to configure > >>>>>>>>>>>> > >>>>>>>>>>> the > >>> > >>>> plugin > >>>>>>> > >>>>>>>> and > >>>>>>>>> > >>>>>>>>>> GitHub password for "apache" user. Or I missed something > >>>>>>>>>>>> > >>>>>>>>>>> and we > >>>>> > >>>>>> can't > >>>>>>> > >>>>>>>> use > >>>>>>>>>> > >>>>>>>>>>> this plugin at Apache infrastructure? > >>>>>>>>>>>> Maybe someone can suggest another solution? > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks, > >>>>>>>>>>>> Artem. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>> > > |
«
Return to Apache Ignite Developers - Legacy Mail Archive
|
1 view|%1 views
| Free forum by Nabble | Edit this page |