Issue 6453 - Update buildtools dep. to c830dfa08e2f, add custom ID and updateURL

Issue 6453 - Update buildtools dep. to c830dfa08e2f, add custom ID and updateURL

** IMPORTANT **
This and https://codereview.adblockplus.org/29716693 have to land simultaneously.

[tlucas, 2018-03-07 22:14:24]

Patch Set 1

[Sebastian Noack, 2018-03-08 02:41:42]

LGTM

[kzar, 2018-03-19 20:21:27]

On 2018/03/08 02:41:42, Sebastian Noack wrote:
> LGTM

(Note since we are in feature freeze take care to push this to the 'next' branch
instead of 'master' unless Sebastian tells you differently.)

[Sebastian Noack, 2018-03-19 21:22:22]

On 2018/03/19 20:21:27, kzar wrote:
> (Note since we are in feature freeze take care to push this to the 'next'
branch
> instead of 'master' unless Sebastian tells you differently.)

If I understand correctly, if we don't land this change in "master" (i.e. the
branch devbuils are built from), together with the related change to abpssembly,
soon, we will lose our devbuilds for Firefox. In this case, landing this in
master, despite code freeze might be justified, if you double-checked that this
dependency update doesn't cause any changes to the generated builds.

[tlucas, 2018-03-20 10:09:24]

On 2018/03/19 21:22:22, Sebastian Noack wrote:
> On 2018/03/19 20:21:27, kzar wrote:
> > (Note since we are in feature freeze take care to push this to the 'next'
> branch
> > instead of 'master' unless Sebastian tells you differently.)
> 
> If I understand correctly, if we don't land this change in "master" (i.e. the
> branch devbuils are built from), together with the related change to
abpssembly,
> soon, we will lose our devbuilds for Firefox.

Correct! There also no "feature" upgrades included in this.

> In this case, landing this in
> master, despite code freeze might be justified, if you double-checked that
this
> dependency update doesn't cause any changes to the generated builds.

I have double checked that the only part affected (the manifest.json) stays the
same.
Please note that i don't have push-permission for adblockpluschrome and that
some abpssembly / infrastructure stuff has to land simultaneously (
http://hub.eyeo.com/issues/8867 )

We might need to actually schedule this.

Cheers!

[kzar, 2018-03-20 10:54:45]

On 2018/03/20 10:09:24, tlucas wrote:
> On 2018/03/19 21:22:22, Sebastian Noack wrote:
> > ... if you double-checked that this dependency update doesn't cause any
> > changes to the generated builds.
> 
> I have double checked that the only part affected (the manifest.json) stays
the
> same.

I think (correct me if I'm wrong) Sebastian meant to check the entire build to
ensure nothing changed, rather than just the manifest. To do this I do a
devbuild, initialise that as a Git repository and commit the current state,
apply my changes, do another devbuild, move the .git folder across and do a `git
status` to see exactly what changed.

[tlucas, 2018-03-20 11:32:24]

On 2018/03/20 10:54:45, kzar wrote:
> On 2018/03/20 10:09:24, tlucas wrote:
> > On 2018/03/19 21:22:22, Sebastian Noack wrote:
> > > ... if you double-checked that this dependency update doesn't cause any
> > > changes to the generated builds.
> > 
> > I have double checked that the only part affected (the manifest.json) stays
> the
> > same.
> 
> I think (correct me if I'm wrong) Sebastian meant to check the entire build to
> ensure nothing changed, rather than just the manifest. To do this I do a
> devbuild, initialise that as a Git repository and commit the current state,
> apply my changes, do another devbuild, move the .git folder across and do a
`git
> status` to see exactly what changed.

That's what i did, sorry i didn't mention it ;)

No changes (except from the version number)

[kzar, 2018-03-20 13:55:13]

On 2018/03/20 11:32:24, tlucas wrote:
> On 2018/03/20 10:54:45, kzar wrote:
> > On 2018/03/20 10:09:24, tlucas wrote:
> > > On 2018/03/19 21:22:22, Sebastian Noack wrote:
> > > > ... if you double-checked that this dependency update doesn't cause any
> > > > changes to the generated builds.
> > > 
> > > I have double checked that the only part affected (the manifest.json)
stays
> > the
> > > same.
> > 
> > I think (correct me if I'm wrong) Sebastian meant to check the entire build
to
> > ensure nothing changed, rather than just the manifest. To do this I do a
> > devbuild, initialise that as a Git repository and commit the current state,
> > apply my changes, do another devbuild, move the .git folder across and do a
> `git
> > status` to see exactly what changed.
> 
> That's what i did, sorry i didn't mention it ;)
> 
> No changes (except from the version number)

Great OK.

[Sebastian Noack, 2018-03-20 18:10:05]

On 2018/03/20 10:09:24, tlucas wrote:
> Please note that i don't have push-permission for adblockpluschrome and that
> some abpssembly / infrastructure stuff has to land simultaneously (
> http://hub.eyeo.com/issues/8867 )
> 
> We might need to actually schedule this.

Any reason, why this change cannot already land in adblockpluschrome, before the
changes to abpssembly land? As far as I understand, abpssembly is just calling
build.py, and you just verified that the output is the same after this change.

[tlucas, 2018-03-21 09:32:15]

On 2018/03/20 18:10:05, Sebastian Noack wrote:
> On 2018/03/20 10:09:24, tlucas wrote:
> > Please note that i don't have push-permission for adblockpluschrome and that
> > some abpssembly / infrastructure stuff has to land simultaneously (
> > http://hub.eyeo.com/issues/8867 )
> > 
> > We might need to actually schedule this.
> 
> Any reason, why this change cannot already land in adblockpluschrome, before
the
> changes to abpssembly land? As far as I understand, abpssembly is just calling
> build.py, and you just verified that the output is the same after this change.

The change in metadata.gecko (i.e. the new name of the variables for "id")
cannot be read by the old abpssembly revision - unfortunately, abpssembly
fetches the app-id with the buildtools revision it depends on, but not the
revision coming with adblockpluschrome.