On Mon, Aug 13, 2018 at 5:52 PM Michael Vorburger <vorburger@...> wrote:

On Mon, Aug 13, 2018 at 2:09 PM Robert Varga <nite@...> wrote:

On 13/08/18 14:06, Anil Belur wrote:
>
>     https://git.opendaylight.org/gerrit/#/c/75151/
>
>
> cool, now we just need to get autorelease to actually pass again... ;-)
> I'm still, right now, seeing various failures
> on https://jenkins.opendaylight.org/releng/job/genius-validate-autorelease-neon/8/console
> from the following projects:
>

00:04:11.596 Entering 'mdsal'
00:04:11.607 mdsal 3e5d53eefead8a109f72b9d658432050d01e8cf1 Validate

mdsal is not getting updated to the proper commit, which should be
3346408b80c3dd860d42f18469c7e35aa01cfee3

I've hopefully fixed it with https://git.opendaylight.org/gerrit/#/c/75167/

by doing what I've documented on https://wiki.opendaylight.org/view/RelEng/Autorelease/Maintenance_Guide#Fix_up_broken_autorelease_which_fell_behind (which can perhaps be improved)

but it begs the quesiton why we have to manually do this?

Robert, Michael: Thank you, I've merged the change #75167 and restarted AR #6. The .gitmodules seem to set to the correct branch (v2.6.x), I am not sure about this.

The issue is when we update the submodules recursively AR should get forwarded to the head on the remote but instead it gets forwarded locally.

Using the `--remote` on the CLI seem to get us the latest changes.

$ git submodule update --init 

Submodule path 'mdsal': checked out '3e5d53eefead8a109f72b9d658432050d01e8cf1'

$ git submodule update --init --remote 

Submodule path 'mdsal': checked out '3346408b80c3dd860d42f18469c7e35aa01cfee3'

On Mon, Aug 13, 2018 at 5:59 AM Anil Belur <abelur@...> wrote:

On Mon, Aug 13, 2018 at 5:52 PM Michael Vorburger <vorburger@...> wrote:

On Mon, Aug 13, 2018 at 2:09 PM Robert Varga <nite@...> wrote:

On 13/08/18 14:06, Anil Belur wrote:
>
>     https://git.opendaylight.org/gerrit/#/c/75151/
>
>
> cool, now we just need to get autorelease to actually pass again... ;-)
> I'm still, right now, seeing various failures
> on https://jenkins.opendaylight.org/releng/job/genius-validate-autorelease-neon/8/console
> from the following projects:
>

00:04:11.596 Entering 'mdsal'
00:04:11.607 mdsal 3e5d53eefead8a109f72b9d658432050d01e8cf1 Validate

mdsal is not getting updated to the proper commit, which should be
3346408b80c3dd860d42f18469c7e35aa01cfee3

I've hopefully fixed it with https://git.opendaylight.org/gerrit/#/c/75167/

by doing what I've documented on https://wiki.opendaylight.org/view/RelEng/Autorelease/Maintenance_Guide#Fix_up_broken_autorelease_which_fell_behind (which can perhaps be improved)

but it begs the quesiton why we have to manually do this?

Robert, Michael: Thank you, I've merged the change #75167 and restarted AR #6. The .gitmodules seem to set to the correct branch (v2.6.x), I am not sure about this.

The issue is when we update the submodules recursively AR should get forwarded to the head on the remote but instead it gets forwarded locally.

Using the `--remote` on the CLI seem to get us the latest changes.

$ git submodule update --init 

Submodule path 'mdsal': checked out '3e5d53eefead8a109f72b9d658432050d01e8cf1'

$ git submodule update --init --remote 

Submodule path 'mdsal': checked out '3346408b80c3dd860d42f18469c7e35aa01cfee3'

It is absolutely critical that when we update .gitmodules and the to update the submodule reference pointer:

https://git.opendaylight.org/gerrit/75100

https://git.opendaylight.org/gerrit/75019

is merged ASAP. Gerrit will only auto-update submodule subscriptions for a submodule, if the submodule is on the latest HEAD of branch. If we merged the submodule update patch after MD-SAL's v2.6.x branch has moved, the HEAD won't be in sync anymore and Gerrit will not pull in the updates.

Regards,

Thanh

On Mon, Aug 13, 2018 at 6:48 PM Thanh Ha <thanh.ha@...> wrote:

On Mon, Aug 13, 2018 at 5:59 AM Anil Belur <abelur@...> wrote:

On Mon, Aug 13, 2018 at 5:52 PM Michael Vorburger <vorburger@...> wrote:

On Mon, Aug 13, 2018 at 2:09 PM Robert Varga <nite@...> wrote:

On 13/08/18 14:06, Anil Belur wrote:
>
>     https://git.opendaylight.org/gerrit/#/c/75151/
>
>
> cool, now we just need to get autorelease to actually pass again... ;-)
> I'm still, right now, seeing various failures
> on https://jenkins.opendaylight.org/releng/job/genius-validate-autorelease-neon/8/console
> from the following projects:
>

00:04:11.596 Entering 'mdsal'
00:04:11.607 mdsal 3e5d53eefead8a109f72b9d658432050d01e8cf1 Validate

mdsal is not getting updated to the proper commit, which should be
3346408b80c3dd860d42f18469c7e35aa01cfee3

I've hopefully fixed it with https://git.opendaylight.org/gerrit/#/c/75167/

by doing what I've documented on https://wiki.opendaylight.org/view/RelEng/Autorelease/Maintenance_Guide#Fix_up_broken_autorelease_which_fell_behind (which can perhaps be improved)

but it begs the quesiton why we have to manually do this?

Robert, Michael: Thank you, I've merged the change #75167 and restarted AR #6. The .gitmodules seem to set to the correct branch (v2.6.x), I am not sure about this.

The issue is when we update the submodules recursively AR should get forwarded to the head on the remote but instead it gets forwarded locally.

Using the `--remote` on the CLI seem to get us the latest changes.

$ git submodule update --init 

Submodule path 'mdsal': checked out '3e5d53eefead8a109f72b9d658432050d01e8cf1'

$ git submodule update --init --remote 

Submodule path 'mdsal': checked out '3346408b80c3dd860d42f18469c7e35aa01cfee3'

It is absolutely critical that when we update .gitmodules and the to update the submodule reference pointer:

https://git.opendaylight.org/gerrit/75100

https://git.opendaylight.org/gerrit/75019

is merged ASAP. Gerrit will only auto-update submodule subscriptions for a submodule, if the submodule is on the latest HEAD of branch. If we merged the submodule update patch after MD-SAL's v2.6.x branch has moved, the HEAD won't be in sync anymore and Gerrit will not pull in the updates.

Regards,

Thanh

JJB SCM submodule supports a tracking flag, to retrive the tip of the configured branch always. I think using the flag would avoid potential sync issues in the future. Any thoughts?  

"

tracking (bool) - Retrieve the tip of the configured branch in .gitmodules (Uses ‘–remote’ option which requires git>=1.8.2)

"

https://docs.openstack.org/infra/jenkins-job-builder/scm.html?highlight=scm