Plugin submissions automatically update Gerrit now!

[Stefan Beller]

With the submission of [1], any change that is submitted to one of the
Gerrit core plugins[2] will trigger a superproject subscription. That
results in a change to Gerrit updating the submodule pointer to the
last state of the plugin.

Changes like [3] are no longer necessary. In fact the submodules are
kept up to date automatically now, so we get a commit in Gerrit even
if the submodule is just getting refactored.

Thanks,
Stefan

[1] https://gerrit-review.googlesource.com/#/q/topic:gerrit-submodules
[2] commit-message-length-validator cookbook-plugin
download-commands hooks replication reviewnotes singleusergroup
[3] https://gerrit-review.googlesource.com/#/c/80083/
https://gerrit-review.googlesource.com/#/c/77609/

[Edwin Kempin]

On Thu, Jul 28, 2016 at 12:11 AM, 'Stefan Beller' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

With the submission of [1], any change that is submitted to one of the
Gerrit core plugins[2] will trigger a superproject subscription. That
results in a change to Gerrit updating the submodule pointer to the
last state of the plugin.

Hey, that's really great!! :-)

There is still one use-case where we want to update the submodule pointer in Gerrit manually.

This is when we make a non-compatible change in Gerrit that requires the core plugins to be updated.

In this case the change in Gerrit which is incompatible for the plugins would also update the submodule

pointers to plugin versions which were adapted to the incompatible change. The adapted plugin versions

are uploaded as changes as well and all changes are marked with the same topic so that they are submitted

together. I guess in this case the superproject subscription would just find that there is nothing to do, right?

[1] would be an example for this.

[1] https://gerrit-review.googlesource.com/#/q/topic:matchable-predicate-mixin

 

Changes like [3] are no longer necessary. In fact the submodules are
kept up to date automatically now, so we get a commit in Gerrit even
if the submodule is just getting refactored.

Thanks,
Stefan

[1] https://gerrit-review.googlesource.com/#/q/topic:gerrit-submodules
[2] commit-message-length-validator  cookbook-plugin
download-commands  hooks  replication  reviewnotes  singleusergroup
[3] https://gerrit-review.googlesource.com/#/c/80083/
    https://gerrit-review.googlesource.com/#/c/77609/

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dave Borowitz]

On Thu, Jul 28, 2016 at 2:58 AM, Edwin Kempin <eke...@google.com> wrote:

On Thu, Jul 28, 2016 at 12:11 AM, 'Stefan Beller' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

With the submission of [1], any change that is submitted to one of the
Gerrit core plugins[2] will trigger a superproject subscription. That
results in a change to Gerrit updating the submodule pointer to the
last state of the plugin.

Hey, that's really great!! :-)

There is still one use-case where we want to update the submodule pointer in Gerrit manually.

This is when we make a non-compatible change in Gerrit that requires the core plugins to be updated.

This change doesn't preclude doing that, the superproject update step should just detect that it's a no-op in that case.

Although I'm not sure I agree with you here that we have to update the submodule link manually in this case. What would be wrong with just changing the code, linking the two changes together by topic, and letting Gerrit update the submodule link when you click "submit whole topic"?

[Edwin Kempin]

On Thu, Jul 28, 2016 at 1:27 PM, Dave Borowitz <dbor...@google.com> wrote:

On Thu, Jul 28, 2016 at 2:58 AM, Edwin Kempin <eke...@google.com> wrote:

On Thu, Jul 28, 2016 at 12:11 AM, 'Stefan Beller' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

With the submission of [1], any change that is submitted to one of the
Gerrit core plugins[2] will trigger a superproject subscription. That
results in a change to Gerrit updating the submodule pointer to the
last state of the plugin.

Hey, that's really great!! :-)

There is still one use-case where we want to update the submodule pointer in Gerrit manually.

This is when we make a non-compatible change in Gerrit that requires the core plugins to be updated.

This change doesn't preclude doing that, the superproject update step should just detect that it's a no-op in that case.

Although I'm not sure I agree with you here that we have to update the submodule link manually in this case. What would be wrong with just changing the code, linking the two changes together by topic, and letting Gerrit update the submodule link when you click "submit whole topic"?

Is the update of the submodule link instant? 

I understood 

  "That results in a change to Gerrit updating the submodule pointer to the last state of the plugin."

like it creates a change that still needs to be submitted. And in this case the submodules would be broken until somebody submits that change.

[Björn Pedersen]

Hi,

There is still one use-case where we want to update the submodule pointer in Gerrit manually.

This is when we make a non-compatible change in Gerrit that requires the core plugins to be updated.

In this case the change in Gerrit which is incompatible for the plugins would also update the submodule

pointers to plugin versions which were adapted to the incompatible change. The adapted plugin versions

are uploaded as changes as well and all changes are marked with the same topic so that they are submitted

together. I guess in this case the superproject subscription would just find that there is nothing to do, right?

I guess  [1] should have solved this use-case.

[1] https://gerrit-review.googlesource.com/#/c/79030/

[Stefan Beller]

Edwin wrote:
> "That results in a change to Gerrit updating the submodule pointer to the last state of the plugin."

> like it creates a change that still needs to be submitted. And in this case the submodules would be broken until somebody submits that change.

Well that was unclear on my part, there is no change that needs to be
submitted separately.

Back then, we could only handle topics with no commit in the superproject,
i.e. you submit in the submodule and Gerrit puts a commit in the superproject
advancing the submodule pointer. (That worked across multiple submodules)
That is where my phrasing came from.

What's new (Thanks czhen!), is the ability of Gerrit to cope with a topic
that also contains commits in the superproject as well as in the submodule.

It's up to you if you want to do the submodule pointer update yourself
or let Gerrit handle it.

On Thu, Jul 28, 2016 at 7:40 AM, Björn Pedersen <ice...@googlemail.com> wrote:
> Hi,
>>
>>
>> There is still one use-case where we want to update the submodule pointer
>> in Gerrit manually.
>> This is when we make a non-compatible change in Gerrit that requires the
>> core plugins to be updated.
>> In this case the change in Gerrit which is incompatible for the plugins
>> would also update the submodule
>> pointers to plugin versions which were adapted to the incompatible change.
>> The adapted plugin versions
>> are uploaded as changes as well and all changes are marked with the same
>> topic so that they are submitted
>> together. I guess in this case the superproject subscription would just
>> find that there is nothing to do, right?

Essentially it should "no-op".
However when you use e.g. Merge-Always/Cherry-pick in the submodule,
your manual update of the submodule pointer is wrong (as you don't know
the sha1 yet) and Gerrit corrects it for you.

[Edwin Kempin]

Am 28.07.2016 18:21 schrieb "'Stefan Beller' via Repo and Gerrit Discussion" <repo-d...@googlegroups.com>:
>
> Edwin wrote:
> >  "That results in a change to Gerrit updating the submodule pointer to the last state of the plugin."
> > like it creates a change that still needs to be submitted. And in this case the submodules would be broken until somebody submits that change.
>
> Well that was unclear on my part, there is no change that needs to be
> submitted separately.
>
> Back then, we could only handle topics with no commit in the superproject,
> i.e. you submit in the submodule and Gerrit puts a commit in the superproject
> advancing the submodule pointer. (That worked across multiple submodules)
> That is where my phrasing came from.
>
> What's new (Thanks czhen!), is the ability of Gerrit to cope with a topic
> that also contains commits in the superproject as well as in the submodule.
>
> It's up to you if you want to do the submodule pointer update yourself
> or let Gerrit handle it.

Thanks for clarifying. If this works then I leave the update of the submodule pointer to Gerrit of course :-)

>
>
> On Thu, Jul 28, 2016 at 7:40 AM, Björn Pedersen <ice...@googlemail.com> wrote:
> > Hi,
> >>
> >>
> >> There is still one use-case where we want to update the submodule pointer
> >> in Gerrit manually.
> >> This is when we make a non-compatible change in Gerrit that requires the
> >> core plugins to be updated.
> >> In this case the change in Gerrit which is incompatible for the plugins
> >> would also update the submodule
> >> pointers to plugin versions which were adapted to the incompatible change.
> >> The adapted plugin versions
> >> are uploaded as changes as well and all changes are marked with the same
> >> topic so that they are submitted
> >> together. I guess in this case the superproject subscription would just
> >> find that there is nothing to do, right?
>
> Essentially it should "no-op".
> However when you use e.g. Merge-Always/Cherry-pick in the submodule,
> your manual update of the submodule pointer is wrong (as you don't know
> the sha1 yet) and Gerrit corrects it for you.
>
> >>
> >
> > I guess  [1] should have solved this use-case.
> >
> > [1] https://gerrit-review.googlesource.com/#/c/79030/
>

[Edwin Kempin]

On Thu, Jul 28, 2016 at 6:36 PM, Edwin Kempin <eke...@google.com> wrote:

Am 28.07.2016 18:21 schrieb "'Stefan Beller' via Repo and Gerrit Discussion" <repo-d...@googlegroups.com>:
>
> Edwin wrote:

> >  "That results in a change to Gerrit updating the submodule pointer to the last state of the plugin."
> > like it creates a change that still needs to be submitted. And in this case the submodules would be broken until somebody submits that change.
>
> Well that was unclear on my part, there is no change that needs to be
> submitted separately.
>
> Back then, we could only handle topics with no commit in the superproject,
> i.e. you submit in the submodule and Gerrit puts a commit in the superproject
> advancing the submodule pointer. (That worked across multiple submodules)
> That is where my phrasing came from.
>
> What's new (Thanks czhen!), is the ability of Gerrit to cope with a topic
> that also contains commits in the superproject as well as in the submodule.
>
> It's up to you if you want to do the submodule pointer update yourself
> or let Gerrit handle it.
Thanks for clarifying. If this works then I leave the update of the submodule pointer to Gerrit of course :-)

I think there is actually a slight disadvantage with letting Gerrit do it.

Doesn't this mean that my local workspace is broken, when I checkout that Gerrit change, because the submodules would not be updated and hence don't compile? If I could checkout the topic that would work, but we don't have that yet. 

How is it after the change is submitted, are the submodules updated when I checkout the merged commit?

[Stefan Beller]

On Fri, Jul 29, 2016 at 1:28 AM, Edwin Kempin <eke...@google.com> wrote:
>> Thanks for clarifying. If this works then I leave the update of the
>> submodule pointer to Gerrit of course :-)
>
> I think there is actually a slight disadvantage with letting Gerrit do it.
> Doesn't this mean that my local workspace is broken, when I checkout that
> Gerrit change, because the submodules would not be updated and hence don't
> compile? If I could checkout the topic that would work, but we don't have
> that yet.

Right, I think the endgoal is to not pay too much attention to the topic, but
rather the superproject being correct.
e.g. for CI/testing we need a REST API call that answers "does this change have
a superproject, and if so how would that look like submission?"
Then you can either ask for the plugin or gerrit change and the CI would test
gerrit with the updated submodule.

>
> How is it after the change is submitted, are the submodules updated when I
> checkout the merged commit?

I think teaching "git checkout" to checkout the submodules or to run
"submodule update" automatically is the next step in Git.

Note that the behavior of Git is constant, no matter if we have
manual or automatic gitlink updates. (e.g. you update gerrit+plugin, and get
it merged, I pull the latest gerrit and notice it doesn't compile with
the plugins.
I could not tell if you or the Gerrit made the superproject update. No matter
how, I need to update the plugin myself for now)

[Edwin Kempin]

On Fri, Jul 29, 2016 at 6:25 PM, Stefan Beller <sbe...@google.com> wrote:

On Fri, Jul 29, 2016 at 1:28 AM, Edwin Kempin <eke...@google.com> wrote:
>> Thanks for clarifying. If this works then I leave the update of the
>> submodule pointer to Gerrit of course :-)
>
> I think there is actually a slight disadvantage with letting Gerrit do it.
> Doesn't this mean that my local workspace is broken, when I checkout that
> Gerrit change, because the submodules would not be updated and hence don't
> compile? If I could checkout the topic that would work, but we don't have
> that yet.

Right, I think the endgoal is to not pay too much attention to the topic, but
rather the superproject being correct.
e.g. for CI/testing we need a REST API call that answers "does this change have
a superproject, and if so how would that look like submission?"
Then you can either ask for the plugin or gerrit change and the CI would test
gerrit with the updated submodule.

SGTM

 

>
> How is it after the change is submitted, are the submodules updated when I
> checkout the merged commit?

I think teaching "git checkout" to checkout the submodules or to run
"submodule update" automatically is the next step in Git.

Note that the behavior of Git is constant, no matter if we have
manual or automatic gitlink updates. (e.g. you update gerrit+plugin, and get
it merged, I pull the latest gerrit and notice it doesn't compile with
the plugins.
I could not tell if you or the Gerrit made the superproject update. No matter
how, I need to update the plugin myself for now)

OK, I wasn't sure about this. Thanks for clarifying.

[Sebastian Schuberth]

On Friday, July 29, 2016 at 6:25:40 PM UTC+2, Stefan Beller wrote:

> e.g. for CI/testing we need a REST API call that answers "does this change have
> a superproject, and if so how would that look like submission?"
> Then you can either ask for the plugin or gerrit change and the CI would test
> gerrit with the updated submodule.

Has any work been done by done on this front? I'm also interestedin in doing pre-submit CI verification for topics that bundle updates to submodules, and for that to work I need to know how the superproject would look like after submission.

Regards,
Sebastian

[Dave Borowitz]

The collection of bundles returned by the Submit Preview endpoint (contributed by Stefan) should include the superproject as well as all the subprojects:

https://gerrit-review.googlesource.com/Documentation/rest-api-changes.html#submit-preview

 

Regards,
Sebastian

[Sebastian Schuberth]

On Thu, Mar 9, 2017 at 2:17 PM, Dave Borowitz <dbor...@google.com> wrote:

> The collection of bundles returned by the Submit Preview endpoint
> (contributed by Stefan) should include the superproject as well as all the
> subprojects:
> https://gerrit-review.googlesource.com/Documentation/rest-api-changes.html#submit-preview

Thanks! I'll give that a try.

--
Sebastian Schuberth