1160717 - Nightly builds for horizon

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Comment 1

[Kevin Grandon :kgrandon]

We are currently experimenting with a new browser based on Graphene.  We would like nightly builds from the larch branch, with the following changes:

Custom preferences:
pref("b2g.default.start_manifest_url", "https://mozvr.github.io/horizon/web/manifest.webapp");

Custom build options:
ac_add_options --with-branding=b2g/branding/horizon
ac_add_options --enable-application=b2g/graphene

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Can we have custom nightly builds from this branch?  If so, can we also add a global MOZ_WEBVR define so that we can isolate things that might break or are incomplete?  Both in the build system and also a C++ -DMOZ_WEBVR.

Comment 3

[Kevin Grandon :kgrandon]

Obsoleting the old request as we're now setting the preference based on the MOZ_WEBVR=1 define. 

We are currently experimenting with a new browser based on Graphene.  We would like nightly builds from the larch branch, with the following build defines:

Custom build options:
MOZ_WEBVR=1
ac_add_options --with-branding=b2g/branding/horizon
ac_add_options --enable-application=b2g/graphene

Comment 4

[Kevin Grandon :kgrandon]

Obsoleting the old request as we're now setting the preference based on the MOZ_HORIZON=1 define. 

We are currently experimenting with a new browser based on Graphene.  We would like nightly builds from the larch branch, with the following build defines:

Custom build options:
MOZ_HORIZON=1
ac_add_options --with-branding=b2g/branding/horizon
ac_add_options --enable-application=b2g/graphene

Comment 5

[Kevin Grandon :kgrandon]

Attachment: [larch] Patch - Implement horizon mozconfigs

Comment 6

[Kevin Grandon :kgrandon]

Comment on attachment 8602245 [details] [diff] [review]
[larch] Patch - Implement horizon mozconfigs

Review of attachment 8602245 [details] [diff] [review]:
-----------------------------------------------------------------

Ben - could you take a look at this and let me know if this is the right path forward? 

See also bug 1130090 and bug 1151964.

I'm not sure what else is needed to be done here, but if you need me to make additional changes, please let me know.

Comment 7

[[e-mail] (:bhearsum)]

Comment on attachment 8602245 [details] [diff] [review]
[larch] Patch - Implement horizon mozconfigs

Review of attachment 8602245 [details] [diff] [review]:
-----------------------------------------------------------------

I'm missing context on what horizon is and what kinds of builds you want from it, but these look like sane mozconfigs. Of course, there's nothing that's going to build with these from CI yet...

Comment 8

[Kevin Grandon :kgrandon]

Hi Ben,

Horizon is a new project, built on the b2g/Graphene architecture. It uses the same gecko runtime, but with a few config changes as seen in these mozconfigs. We would like to have nightly builds of this new product with these mozconfig changes. Would you be the right person to enable these nightly builds for us? Not sure what other details you need, but I'm more than happy to hop on a video call for a few minutes if that would help clear things up.

Comment 9

[Kevin Grandon :kgrandon]

Hi Chris - I saw you guys active on some other larch/graphene related bugs and was wondering what the next steps here would be. This is very similar to what we did with larch/graphene, only with a few build changes as seen in the mozconfig patch attached here. Please see comment 4 and comment 8 and let me know if there's any additional information I can provide here. Thanks!

Comment 10

[Kevin Grandon :kgrandon]

Not sure who the right person is to ping here. Jordan - I saw you were active on some of the initial Graphene setup bugs and I was wondering if you could help us here. I've also updated the user story to encompass most of the context and scope here. Thanks!

Comment 11

[Jordan Lund (:jlund)]

(In reply to Kevin Grandon :kgrandon from comment #10)
> Not sure who the right person is to ping here. Jordan - I saw you were
> active on some of the initial Graphene setup bugs and I was wondering if you
> could help us here. I've also updated the user story to encompass most of
> the context and scope here. Thanks!

hi there! first step is to get a list of requirements/expectations. I think the easiest thing to do is have a vidyo chat like you suggested in comment 8. My calendar is accurate. Feel free to make an event sometime next week. I can't promise I'll action this myself but I'll at least get it triaged and provide you a time line of when you can expect this to be completed

does this help?

Comment 12

[Kevin Grandon :kgrandon]

(In reply to Jordan Lund (:jlund) from comment #11)
> hi there! first step is to get a list of requirements/expectations. 

Thanks Jordan! I would definitely like to get any requirements into this bug so they are documented for future generations :) Ideally we need the exact same thing that Graphene has, only with some config changes.


> I think
> the easiest thing to do is have a vidyo chat like you suggested in comment
> 8. My calendar is accurate. Feel free to make an event sometime next week. I
> can't promise I'll action this myself but I'll at least get it triaged and
> provide you a time line of when you can expect this to be completed

I am unfortunately traveling and on PTO for a while, so ideally we could gather all of the necessary information in this bug. If not I will try to have someone else from the team reach out to you. Thanks!

Comment 13

[Jordan Lund (:jlund)]

> I am unfortunately traveling and on PTO for a while, so ideally we could
> gather all of the necessary information in this bug. If not I will try to
> have someone else from the team reach out to you. Thanks!

okay, I had a quick glance at graphene continuous integration implementation. It took about a month to wrap up after some regressions/bustage. This should take less time but we should expect similar hiccups.

so we are on the same page wrt "Ideally we need the exact same thing that Graphene has", do you want:

1) support for 3 platforms: linux64, macosx64, and win64?

2) an opt build per push?

3) one nightly a day if there is a push?

4) no tests?

5) graphene runs on larch (per push) and on try (not-by-default). which branches should these run on? Along side graphene on larch? Do you want to be able to run these on Try as well?

6) Not all nightlies provide updates for products. Graphene does give updates (via balrog). Do you require updates?

7) has the mozconfigs in https://bugzilla.mozilla.org/show_bug.cgi?id=1160717#c7 landed? If so, which branch(es)?

8) broad, general question: what is horizon? what is this bug blocking? In terms of similar platforms (other b2g related projects), where does this sit in priority.


Answering these questions should give us a clearer picture of what's needed and time-line. kgrandon (or someone from this bug), please needinfo when you reply :)

Comment 14

[Kevin Grandon :kgrandon]

Jordan, thank you for taking a look at this. Please freely ping me if my answers don't make sense or I need to provide more information.

(In reply to Jordan Lund (:jlund) from comment #13)
> okay, I had a quick glance at graphene continuous integration
> implementation. It took about a month to wrap up after some
> regressions/bustage. This should take less time but we should expect similar
> hiccups.
> 
> so we are on the same page wrt "Ideally we need the exact same thing that
> Graphene has", do you want:
> 
> 1) support for 3 platforms: linux64, macosx64, and win64?

Correct, we would like support for these three platforms.


> 2) an opt build per push?

Yes.


> 3) one nightly a day if there is a push?

Yes.


> 4) no tests?

I would imagine we would want tests in the future, but for now I think we can say "no tests" to help streamline things.


> 5) graphene runs on larch (per push) and on try (not-by-default). which
> branches should these run on? Along side graphene on larch? Do you want to
> be able to run these on Try as well?

I think we want the same. We want these to run on larch (per-push), and probably on try (not by default).


> 6) Not all nightlies provide updates for products. Graphene does give
> updates (via balrog). Do you require updates?

Yes, we would like the same type of updates for users.


> 7) has the mozconfigs in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1160717#c7 landed? If so, which
> branch(es)?

It has not landed yet, but I will ask for this to be landed to larch now.


> 8) broad, general question: what is horizon? what is this bug blocking? In
> terms of similar platforms (other b2g related projects), where does this sit
> in priority.

Horizon is a new browser, built on top of Graphene, and with a new set of build configs. The build configs change out the UI, preferences, and branding of the browser. There is a new team of 7 or 8 people currently working on this product full time, and having nightly builds would greatly help the development speed of our team and is required for the eventual release.

Timeline wise, we were hoping to have something by Whistler. If that's not feasible or you have other priorities we understand. This effort is decoupled from FxOS/B2G and, and nightly builds are one of our biggest blockers currently.

Comment 15

[Kevin Grandon :kgrandon]

Fabrice - can you help me land the mozconfigs on larch here? https://bug1160717.bugzilla.mozilla.org/attachment.cgi?id=8602245

Some day I will learn how to :) Thanks!

Comment 16

[[:fabrice] Fabrice Desré]

https://hg.mozilla.org/projects/larch/rev/64aef51b0247

Comment 17

[Jordan Lund (:jlund)]

> Timeline wise, we were hoping to have something by Whistler. If that's not
> feasible or you have other priorities we understand. This effort is
> decoupled from FxOS/B2G and, and nightly builds are one of our biggest
> blockers currently.

timeline expectation ^

requirements:
* copy and s/graphene/horizon/ for patches in:
- https://bugzil.la/1130090#h6
- https://bugzil.la/1139943
- https://bugzil.la/1140123
- https://bugzil.la/1140437
- https://bugzil.la/1141633
- likely some changes to balrog (e.g. added rule(s))
- as ben found out, it's probably easier to iterate on this live in larch (rather than battle with staging)

coop: as per our discussion, I'll leave the triaging/assigning of this to you. With three weeks to Whistler, I could pick away (and complete) this without it causing much impact on my goals.

Comment 18

[Chris Cooper [:coop] (he/him)]

(In reply to Jordan Lund (:jlund) from comment #17)
> coop: as per our discussion, I'll leave the triaging/assigning of this to
> you. With three weeks to Whistler, I could pick away (and complete) this
> without it causing much impact on my goals.

Looks like you've done the lion's share of the work here, Jordan, tracking down the relevant patches and such. I'm happy to run with it from here.

Comment 19

[Chris Cooper [:coop] (he/him)]

(In reply to Chris Cooper [:coop] from comment #18)
> Looks like you've done the lion's share of the work here, Jordan, tracking
> down the relevant patches and such. I'm happy to run with it from here.

Sorry for the delay. I'm pulling together patches for this now.

Comment 20

[Chris Cooper [:coop] (he/him)]

Attachment: [buildbot-configs] Add horizon builds and nightlies

Comment 21

[Chris Cooper [:coop] (he/him)]

Attachment: [mozharness] Add horizon configs to mozharness

Comment 22

[Chris Cooper [:coop] (he/him)]

Attachment: [tools] Add horizon builds to trychooser

Comment 23

[Jordan Lund (:jlund)]

Comment on attachment 8620377 [details] [diff] [review]
[buildbot-configs] Add horizon builds and nightlies

Review of attachment 8620377 [details] [diff] [review]:
-----------------------------------------------------------------

lgtm :)

builderlist diff:
http://people.mozilla.org/~jlund/horizon_builders.diff

Comment 24

[Jordan Lund (:jlund)]

Comment on attachment 8620378 [details] [diff] [review]
[mozharness] Add horizon configs to mozharness

Review of attachment 8620378 [details] [diff] [review]:
-----------------------------------------------------------------

I think this is pretty much what we need to get started. I'm going to r- strictly for the mozconfig locations (see in line below)

::: configs/balrog/docker-worker.py
@@ +12,5 @@
>                  'thunderbird': 'tbirdbld',
>                  'mobile': 'ffxbld',
>                  'Fennec': 'ffxbld',
>                  'graphene': 'ffxbld',
> +                'horizon': 'ffxbld',

I'm unfamiliar with docker-worker.py. Judging by http://hg.mozilla.org/build/mozharness/rev/834502a2011b I suppose it is for TC to start using Balrog for certain builds?

Anyway, I think copying graphene here looks logical :)

::: configs/builds/releng_sub_linux_configs/64_horizon.py
@@ +17,5 @@
> +    'enable_signing': False,
> +    'enable_talos_sendchange': False,
> +    'enable_unittest_sendchange': False,
> +    'enable_count_ctors': False,
> +    'objdir': 'obj-horizon',

I'd assume this objdir location is right but we can adjust these bits later easily enough with mozharness if it's wrong

@@ +38,5 @@
> +        "SYMBOL_SERVER_SSH_KEY": "/home/mock_mozilla/.ssh/ffxbld_rsa",
> +        "SYMBOL_SERVER_USER": "ffxbld",
> +        "SYMBOL_SERVER_PATH": "/mnt/netapp/breakpad/symbols_ffx",
> +    },
> +    'src_mozconfig': 'b2g/horizon/config/mozconfigs/linux64/nightly',

I poked larch and it looks like we have put the horizon configs under graphene:
https://hg.mozilla.org/projects/larch/file/43bbeae174f0/b2g/graphene/config/horizon-mozconfigs

::: configs/builds/releng_sub_mac_configs/64_horizon.py
@@ +36,5 @@
> +        "SYMBOL_SERVER_SSH_KEY": "/Users/cltbld/.ssh/ffxbld_rsa",
> +        "SYMBOL_SERVER_USER": "ffxbld",
> +        "SYMBOL_SERVER_PATH": "/mnt/netapp/breakpad/symbols_ffx",
> +    },
> +    'src_mozconfig': 'b2g/horizon/config/mozconfigs/macosx64/nightly',

will need mozconfig fix like above

::: configs/builds/releng_sub_windows_configs/64_horizon.py
@@ +35,5 @@
> +        "SYMBOL_SERVER_SSH_KEY": "/c/Users/cltbld/.ssh/ffxbld_rsa",
> +        "SYMBOL_SERVER_USER": "ffxbld",
> +        "SYMBOL_SERVER_PATH": "/mnt/netapp/breakpad/symbols_ffx",
> +    },
> +    'src_mozconfig': 'b2g/horizon/config/mozconfigs/win64/nightly',

need fix here too for mozconfig (just to be explicit :)

::: mozharness/mozilla/updates/balrog.py
@@ +50,2 @@
>          balrog_props["properties"]["platform"] = balrog_props["properties"]["platform"].replace("_graphene", "")
> +        balrog_props["properties"]["platform"] = balrog_props["properties"]["platform"].replace("_horizon", "")

I remember chatting to ben over this part from last time. now that we are n>1 instances of this, I wonder if we should be making this configurable at least so we hide the hack in the config and not the script itself :)

maybe we condense both these 'hack' lines to:
if self.config.get('balrog_platform'):
     balrog_props["properties"]["platform"] = self.config['balrog_platform']

then in say, configs/builds/releng_sub_linux_configs/64_horizon.py we define:
    'balrog_platform': 'linux64' # without the _horizon extension

What do you think? I don't want to block on this just for that but I feel like this should be revisited at the least.

Comment 25

[Jordan Lund (:jlund)]

Attachment: balrog rule for graphene that horizon should copy off of

so I think we are nearly here! I just had some thoughts while I was going over your patches. I think the two follow up places we will need to address:

1) adding a rule to balrog so that it looks like the graphene attachment I'm adding here.

2) telling cloud-tools about this new platform: https://github.com/mozilla/build-cloud-tools/blob/master/configs/watch_pending.cfg#L20

There is probably other things my forgetful brain is neglecting to think of... but this should be a good start :)

Comment 26

[Chris Cooper [:coop] (he/him)]

Attachment: [mozharness] Add horizon configs to mozharness, v2

(In reply to Jordan Lund (:jlund) from comment #24) 
> I think this is pretty much what we need to get started. I'm going to r-
> strictly for the mozconfig locations (see in line below)

Fixed.

> I remember chatting to ben over this part from last time. now that we are
> n>1 instances of this, I wonder if we should be making this configurable at
> least so we hide the hack in the config and not the script itself :)
> 
> maybe we condense both these 'hack' lines to:
> if self.config.get('balrog_platform'):
>      balrog_props["properties"]["platform"] = self.config['balrog_platform']
> 
> then in say, configs/builds/releng_sub_linux_configs/64_horizon.py we define:
>     'balrog_platform': 'linux64' # without the _horizon extension
> 
> What do you think? I don't want to block on this just for that but I feel
> like this should be revisited at the least.

Sounds good. I've added balrog_platform to the graphene and horizon configs as suggested.

Comment 27

[Chris Cooper [:coop] (he/him)]

It looks like we added a new platform to balrog for graphene, and I'm presuming we'll need to do that again here for horizon.

Ben: I see an existing rule in balrog for "Graphene : nightly-larch." I'd like to duplicate that for Horizon, but how does one add the new product to allow that mapping to be valid?

Comment 28

[Jordan Lund (:jlund)]

Comment on attachment 8622614 [details] [diff] [review]
[mozharness] Add horizon configs to mozharness, v2

Review of attachment 8622614 [details] [diff] [review]:
-----------------------------------------------------------------

lgtm :)

Comment 29

[[e-mail] (:bhearsum)]

(In reply to Chris Cooper [:coop] from comment #27)
> It looks like we added a new platform to balrog for graphene, and I'm
> presuming we'll need to do that again here for horizon.
> 
> Ben: I see an existing rule in balrog for "Graphene : nightly-larch." I'd
> like to duplicate that for Horizon, but how does one add the new product to
> allow that mapping to be valid?

Horizon and Graphene are actually considered products in Balrog terms (eg, they will have separate Releases like https://aus4-admin.mozilla.org/releases#graphene). It's all data driven over there, but you will need to do a couple of things:
* Update the "b2gbld" account permissions to be able to make changes to Horizon releases, you can do that here: https://aus4-admin.mozilla.org/permissions (and stage-b2gbld on https://aus4-admin-dev.allizom.org/permissions, please).
* Make sure the Horzion builds are calling balrog-submitter.py with "Horizon" for product.
* Once you have an initial release (probably called Horizon-larch-nightly-latest) you'll need to create a new Rule for Horizon:nightly-larch that points at it. Have a look at https://aus4-admin.mozilla.org/rules#graphene for an example.

Comment 30

[Chris Cooper [:coop] (he/him)]

Comment on attachment 8620377 [details] [diff] [review]
[buildbot-configs] Add horizon builds and nightlies

Review of attachment 8620377 [details] [diff] [review]:
-----------------------------------------------------------------

https://hg.mozilla.org/build/buildbot-configs/rev/c71f4b72e5db

Comment 31

[Chris Cooper [:coop] (he/him)]

Comment on attachment 8620380 [details] [diff] [review]
[tools] Add horizon builds to trychooser

Review of attachment 8620380 [details] [diff] [review]:
-----------------------------------------------------------------

https://hg.mozilla.org/build/tools/rev/71dc31d23ca5

Comment 32

[Chris Cooper [:coop] (he/him)]

Comment on attachment 8622614 [details] [diff] [review]
[mozharness] Add horizon configs to mozharness, v2

https://hg.mozilla.org/build/mozharness/rev/8f0c7d940aee

Comment 33

[Chris Cooper [:coop] (he/him)]

In production: https://hg.mozilla.org/build/buildbot-configs/rev/c71f4b72e5db

Comment 34

[Chris Cooper [:coop] (he/him)]

mozharness production tag moved to: https://hg.mozilla.org/build/mozharness/rev/321d9dcec7b2

Comment 35

[Chris Cooper [:coop] (he/him)]

Bumped mozharness rev on m-i: https://hg.mozilla.org/integration/mozilla-inbound/rev/6579ed36ffa7

Comment 36

[Jordan Lund (:jlund)]

(In reply to Chris Cooper [:coop] from comment #33)
> In production: https://hg.mozilla.org/build/buildbot-configs/rev/c71f4b72e5db

\o/ iiuc fyi - this should be live within the hour so that subsequent pushes to larch will also generate 'horizon' builds.

If you want to test this out (and have your job actually succeed), you'll need to upload https://hg.mozilla.org/integration/mozilla-inbound/rev/6579ed36ffa7 into larch.

I'd imagine until we patch treeherder, these jobs won't show up with the correct name but will be a generic 'B'

Comment 37

[Chris Cooper [:coop] (he/him)]

Attachment: [treeherder] Parsing additions for Horizon

Comment 38

[Kevin Grandon :kgrandon]

Thank you very much for the quick turnaround on this guys.

When you get a chance please let us know where to begin looking for these builds. I noticed that graphene builds are currently located here (http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-larch/), would horizon builds be located in the same folder?

Comment 39

[Jordan Lund (:jlund)]

> When you get a chance please let us know where to begin looking for these
> builds. I noticed that graphene builds are currently located here
> (http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-larch/), would
> horizon builds be located in the same folder?

the non graphene jobs here (they look like normal linux,mac,win builds) https://treeherder.mozilla.org/#/jobs?repo=larch&revision=7f8e7c37c557 are actually horizon.

they are failing because you need to merge or cherry-pick https://hg.mozilla.org/integration/mozilla-inbound/rev/6579ed36ffa7 (see comment 36)

once the jobs are green and not failing, they should show up in http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-larch/

Comment 40

[Kevin Grandon :kgrandon]

Fabrice - could I bother you to help me out here and checkin this patch to larch? Please see comment 36 for more details. Thank you!

https://hg.mozilla.org/integration/mozilla-inbound/rev/6579ed36ffa7

Comment 41

[[:fabrice] Fabrice Desré]

I merged m-c where this revision was, so you should be all set!

Comment 42

[Treeherder GitHub Bugbot]

Commits pushed to master at https://github.com/mozilla/treeherder

https://github.com/mozilla/treeherder/commit/4db8aa1e64332cd6e989a9e4893174435cdb8a59
Bug 1160717 - add parsing for Horizon builds

https://github.com/mozilla/treeherder/commit/ede44d579eae913d34f21cfe1923d9c4e6fda656
Merge pull request #635 from ccooper/master

Bug 1160717 - add parsing for Horizon builds

Comment 43

[Kevin Grandon :kgrandon]

Hi Jordan, thank you for the work here. I see many different builds in the latest-larch[1] folder. I just wanted to make sure that our builds were in it, and ask what they were called? (Also want to make sure that we don't clobber the graphene builds). Thanks!

[1] http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-larch/

Comment 44

[Jordan Lund (:jlund)]

(In reply to Kevin Grandon (PTO) :kgrandon from comment #43)
> Hi Jordan, thank you for the work here. I see many different builds in the
> latest-larch[1] folder. I just wanted to make sure that our builds were in
> it, and ask what they were called? (Also want to make sure that we don't
> clobber the graphene builds). Thanks!
> 
> [1] http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-larch/

something doesn't look correct. I believe we are overwriting graphene builds or at the very least, using the graphene name in places we shouldn't be.

taking a look at an example nightly build:
http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/2015/06/2015-06-30-04-42-06-larch/larch-linux64_horizon-nightly-bm77-build1-build1.txt.gz

you can see that our releng automation is being told the package name and other properties are:
06:51:25     INFO -  u'packageFilename': u'graphene-42.0a1.en-US.linux-x86_64.tar.bz2',

so this suggests to me that the mozconfigs you provided in comment 4 are inheriting from graphene bits and you need to modify the build more. Releng doesn't generally know how build and package names are generated for platforms (we usually are just given the mozconfigs). I would recommend pinging someone familiar with the build setup + mozconfigs for graphene.

Comment 45

[Chris Cooper [:coop] (he/him)]

(In reply to Jordan Lund (:jlund) from comment #44) 
> so this suggests to me that the mozconfigs you provided in comment 4 are
> inheriting from graphene bits and you need to modify the build more. Releng
> doesn't generally know how build and package names are generated for
> platforms (we usually are just given the mozconfigs). I would recommend
> pinging someone familiar with the build setup + mozconfigs for graphene.

Specifically, I think the appName for Graphene is being set here:

https://hg.mozilla.org/projects/larch/file/68a1aa8c33a2/b2g/graphene/confvars.sh#l5

You'll need to switch/override that for Horizon. https://hg.mozilla.org/projects/larch/file/68a1aa8c33a2/b2g/graphene/config/horizon-mozconfigs/common seems to be a likely place.

Comment 46

[Kevin Grandon :kgrandon]

Attachment: [larch] Patch - Change app basename for horizon

Fabrice - sorry for clobbering your builds! I think this should fix the issue, could you review it and help me land on larch? Thanks!

Comment 47

[[:fabrice] Fabrice Desré]

https://hg.mozilla.org/projects/larch/rev/2181c5d27f1e

Comment 48

[Chris Cooper [:coop] (he/him)]

I see horizon-branded builds in http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-larch/ now.

Going to investigate the balrog steps now.

Comment 49

[Chris Cooper [:coop] (he/him)]

(In reply to Ben Hearsum [:bhearsum] from comment #29)
> * Update the "b2gbld" account permissions to be able to make changes to
> Horizon releases, you can do that here:
> https://aus4-admin.mozilla.org/permissions (and stage-b2gbld on
> https://aus4-admin-dev.allizom.org/permissions, please).

Done, for both production and staging.

> * Make sure the Horzion builds are calling balrog-submitter.py with
> "Horizon" for product.

Pretty sure this is working. Log excerpt:

07:27:58     INFO - Dumping config to /builds/slave/l-l64_horizon-ntly-00000000000/balrog_props.json.
07:27:58     INFO - {'properties': {'appName': 'Horizon',
07:27:58     INFO -                 'appVersion': '42.0a1',

...then later:

07:27:58     INFO - retry: Calling run_command with args: (['python', '/builds/slave/l-l64_horizon-ntly-00000000000/build/tools/scripts/updates/balrog-submitter.py', '--build-properties', '/builds/slave/l-l64_horizon-ntly-00000000000/balrog_props.json', '-t', 'nightly', '--credentials-file', '/builds/slave/l-l64_horizon-ntly-00000000000/oauth.txt', '--verbose', '--api-root', 'https://aus4-admin.mozilla.org/api', '--username', 'b2gbld', '--url-replacement', 'http://ftp.mozilla.org/pub/mozilla.org,http://download.cdn.mozilla.net/pub/mozilla.org'],), kwargs: {}, attempt #1

> * Once you have an initial release (probably called
> Horizon-larch-nightly-latest) you'll need to create a new Rule for
> Horizon:nightly-larch that points at it. Have a look at
> https://aus4-admin.mozilla.org/rules#graphene for an example.

I duplicated the Graphene rule for Horizon.

Ben: both Graphene and Horizon are on the nightly-larch channel, although the product and mapping differ. Is this a problem?

Comment 50

[[e-mail] (:bhearsum)]

(In reply to Chris Cooper [:coop] from comment #49)
> (In reply to Ben Hearsum [:bhearsum] from comment #29)
> > * Update the "b2gbld" account permissions to be able to make changes to
> > Horizon releases, you can do that here:
> > https://aus4-admin.mozilla.org/permissions (and stage-b2gbld on
> > https://aus4-admin-dev.allizom.org/permissions, please).
> 
> Done, for both production and staging.
> 
> > * Make sure the Horzion builds are calling balrog-submitter.py with
> > "Horizon" for product.
> 
> Pretty sure this is working. Log excerpt:
> 
> 07:27:58     INFO - Dumping config to
> /builds/slave/l-l64_horizon-ntly-00000000000/balrog_props.json.
> 07:27:58     INFO - {'properties': {'appName': 'Horizon',
> 07:27:58     INFO -                 'appVersion': '42.0a1',
> 
> ...then later:
> 
> 07:27:58     INFO - retry: Calling run_command with args: (['python',
> '/builds/slave/l-l64_horizon-ntly-00000000000/build/tools/scripts/updates/
> balrog-submitter.py', '--build-properties',
> '/builds/slave/l-l64_horizon-ntly-00000000000/balrog_props.json', '-t',
> 'nightly', '--credentials-file',
> '/builds/slave/l-l64_horizon-ntly-00000000000/oauth.txt', '--verbose',
> '--api-root', 'https://aus4-admin.mozilla.org/api', '--username', 'b2gbld',
> '--url-replacement',
> 'http://ftp.mozilla.org/pub/mozilla.org,http://download.cdn.mozilla.net/pub/
> mozilla.org'],), kwargs: {}, attempt #1
> 
> > * Once you have an initial release (probably called
> > Horizon-larch-nightly-latest) you'll need to create a new Rule for
> > Horizon:nightly-larch that points at it. Have a look at
> > https://aus4-admin.mozilla.org/rules#graphene for an example.
> 
> I duplicated the Graphene rule for Horizon.
> 
> Ben: both Graphene and Horizon are on the nightly-larch channel, although
> the product and mapping differ. Is this a problem?

Yep! That's exactly what I would've expected. Graphene and Horizon are different products, and Releases are tied to a single product. This is the same way that Firefox and Fennec updates work -- same channel name but different product/mapping.

Comment 51

[Chris Cooper [:coop] (he/him)]

Sorry, resolving was premature. I want to make sure I can update a Mac Horizon nightly tomorrow.

Is the Windows nightly timeout in 'mach build' being investigated?

Comment 52

[Chris Cooper [:coop] (he/him)]

Still waiting on a new set of nightlies since today's were busted by the m-c merge.

Running the Horizon app on Mac, I see no visible way to trigger an update or check the version. Assuming :fabrice's latest merge[1] results in working builds, is anyone out there better setup to check whether updates are actually working?

1. https://treeherder.mozilla.org/#/jobs?repo=larch&revision=70028afebbeb

Comment 53

[Kevin Grandon :kgrandon]

If I understand correctly, you're asking about updating the app when it's running? We have not yet built update functionality into horizon, that is something that's on our roadmap to do. Thanks for the help here, if there's problems with updates, I think we can file follow-up bugs in the future.

Comment 54

[Chris Cooper [:coop] (he/him)]

(In reply to Kevin Grandon :kgrandon from comment #53)
> If I understand correctly, you're asking about updating the app when it's
> running? We have not yet built update functionality into horizon, that is
> something that's on our roadmap to do. Thanks for the help here, if there's
> problems with updates, I think we can file follow-up bugs in the future.

OK, WFM. Thanks, Kevin.