Closed Bug 759910 Opened 12 years ago Closed 12 years ago

provide human readable buildID for b2g builds

Categories

(Firefox OS Graveyard :: General, defect, P1)

x86
Gonk (Firefox OS)
defect

Tracking

(blocking-kilimanjaro:+, blocking-basecamp:+)

RESOLVED DUPLICATE of bug 759911
B2G C1 (to 19nov)
blocking-kilimanjaro +
blocking-basecamp +

People

(Reporter: lsblakk, Assigned: jhford)

References

Details

(Whiteboard: [WebAPI:P0])

We'll need this for  user-testing/qa/release cycling.
blocking-basecamp: --- → +
Blocks: 759911
Thanks for +ing for blocking-basecamp. Also setting this as a P1 since we need to be able to compare build versions asap. Finally, assigning to John since he's driving the build work.

John - please provide an estimate when you can.
Assignee: nobody → jhford
Priority: -- → P1
John - can you provide status?
(In reply to Alex Keybl [:akeybl] from comment #2)
> John - can you provide status?

Hi Alex, I've been focused on getting our desktop B2G builds going.

I am working on a tool that will generate and insert a repo manifest that describes the state of the repositories used in a given build.  Once I have that landed, I'll be able to figure out a way to generate a build id based on the manifest.
blocking-kilimanjaro: --- → +
FYI, I just did a build of gaia from the downloadable zip of the gaia github repo (not sure why I can't clone it), and the Git commit into once this is installed on the phone says:
 2012-07-08 22:06:04 
 Unknown Git commit, build date shown here

I know this to be https://github.com/mozilla-b2g/gaia/commit/5803383889d6af54e8aa1073656062a8c77f6294 from 2012-07-07

So, let me know if you need another bug on that or if your plan from comment 3 will eliminate the need for the Settings: About Phone section to have this info displayed properly where the build is reflective of what changeset and not of the time it got put on the phone.
The complication here is that there is currently more than one commit id that describes a given build of B2G.  Having the Gaia version is helpful, but far from a complete picture.

I am working on a better branching/tagging strategy which would allow us to have a single sha-1 ID of the b2g-manifest repository that would describe a full build of B2G on github, https://github.com/mozilla-b2g/B2G/issues/54

In the meantime, if you have a full build of B2G and need to find out which version of a given repository was used, you can grab that off the device/emulator with:

  adb pull /system/sources.xml sources.xml

To replicate the environment used to build the software on your device/emulator , you can clone all the repositories with:
  
  git clone github.com:mozilla-b2g/B2G
  cd B2G
  ./config.sh <device> sources.xml
Priority: P1 → P2
Renom if you think we can't ship a v1 without this.
blocking-basecamp: + → ---
As far as I know, we are not shipping a v1 product without doing internal dogfooding and testing which means that this is still a P1 basecamp blocker as it's standing in the way of a concise and human-usable way of performing QA on our product.  There's no way we can expect even QA, let alone other MoCo employees who will be testing our product to be able to use adb calls to get a sources.xml file in order to file bugs or talk with devs about issues they come up against. 

John, we talked last week about having the manifest for the sources and you mention doing a sha-1 ID of the manifest for a build - how much longer until we can start relying on being able to create that on a per-build basis so that it can be fed into the about: page asked for in bug 759911?
blocking-basecamp: --- → +
Priority: P2 → P1
Whiteboard: [WebAPI:P0]
John, any update here?
I've heard multiple requests for what this Build ID should be, how it should be generated and on what information it should be based.  I also don't personally know how releng plans to actually generate the builds of all the parts of Firefox OS.  I think we need to separate this bug into two concerns:

1) How are we going to generate a B2G build id?

2) How do we take a computed build id and make it available on the phone?

For the first concern, we need to figure out how arbitrary or not the build id should be and what it represents.  We need to figure out how these build ids should change (or not) when we have updates that don't change the entire system image.

My thought is that we should have build ids for each component that gets updated as a single unit (i.e. one per gecko, gaia and gonk) and display those independently.  We already have a Gaia identifier shown and Gecko contains its own buildid.

I'll work on adding a timestamp based buildid to gonk.  It's fairly arbitrary, but sources.xml is the correct way to figure out what was built.
I think we can combine Gecko/Gaia, since they're being packaged together currently. In a perfect world, we'd look something like:


==Pre-Release==
Channel: Stable
B2G: v1.2 (YYYYMMDDHHMM)
Gonk: 
Firmware: 

==Post-Release==
Channel: Release
B2G: v1.2
Gonk: 
Firmware: 


Where the B2G major/minor version is specified in some file (as we do in Firefox), and the BuildID (YYYYMMDDHHMM) is stamped on at build time. I don't have strong feelings on what we do about Gonk/Firmware versioning - we can leave this as changesets for now until we figure something out.
Hi All,

I've been assigned to a similar issue, currently the os version (or B2G version) is set in b2g/confvar.sh, and the b2g/chrome/content/settings.js is doing a hack of writing these information into IndexedDB at launch time. Please reference bug 790158 for more details, thanks.
In the meantime, one way to get build id, with the phone connected via usb, is:

$ adb shell cat /system/sources.xml
(In reply to Alex Keybl [:akeybl] from comment #10)
> I think we can combine Gecko/Gaia, since they're being packaged together
> currently. In a perfect world, we'd look something like:

This is not yet true, the best would be to have one as a submodule of the other or merging the sources.

> Where the B2G major/minor version is specified in some file (as we do in
> Firefox), and the BuildID (YYYYMMDDHHMM) is stamped on at build time. I
> don't have strong feelings on what we do about Gonk/Firmware versioning - we
> can leave this as changesets for now until we figure something out.

I recommend to replace the build time by a committer timestamp, which is way more valuable in a linear history and which will not change across compilations.  A committer timestamp can be obtained with « git show -s --format="%ci" » and is a good approximation of a sha1 in the history of a branch.
(In reply to Nicolas B. Pierron [:pierron] [:nbp] from comment #13)
> This is not yet true, the best would be to have one as a submodule of the
> other or merging the sources.

Aren't Gecko/Gaia packaged together in OTA updates? A developer should be able to trace a buildID back to the corresponding Gecko/Gaia changesets. I'd appreciate if you could clarify why you think that isn't doable.

> I recommend to replace the build time by a committer timestamp, which is way
> more valuable in a linear history and which will not change across
> compilations.  A committer timestamp can be obtained with « git show -s
> --format="%ci" » and is a good approximation of a sha1 in the history of a
> branch.

The identifier needs to be easily entered on a computer when filing a bug. Date/Times make a lot of sense to people.
(In reply to Alex Keybl [:akeybl] from comment #14)
> (In reply to Nicolas B. Pierron [:pierron] [:nbp] from comment #13)
> > This is not yet true, the best would be to have one as a submodule of the
> > other or merging the sources.
> 
> Aren't Gecko/Gaia packaged together in OTA updates? A developer should be
> able to trace a buildID back to the corresponding Gecko/Gaia changesets. I'd
> appreciate if you could clarify why you think that isn't doable.

I don't know about OTA packages, and for sure you can number the released packages.  What I mentioned is that this cannot be used to identify developer/home-made versions because Gaia and Gecko are living in different repository which are not yet correlated.

> > I recommend to replace the build time by a committer timestamp, which is way
> > more valuable in a linear history and which will not change across
> > compilations.  A committer timestamp can be obtained with « git show -s
> > --format="%ci" » and is a good approximation of a sha1 in the history of a
> > branch.
> 
> The identifier needs to be easily entered on a computer when filing a bug.
> Date/Times make a lot of sense to people.

The committer timestamp, is a date & time which can almost represent a commit in a git repository without the verbosity and readability issues related to sha1.
The problem with that timestamp is that it's per repository.  We have ~70 repositories that make up the gonk layer, one for gecko and one for gaia.  We'd need to have so many timestamps, that it'd be easier to just grab the sources.xml file.

The sources.xml is the absolute best source of truth regarding revisions.  What is desired is something that uniquely identifies a specific build.  One set of revisions could conceivably have more than one build, especially in a release process.  Because of that, we need something that uniquely identifies the specific build of each shippable component.

Gecko already has this, gaia doesn't actually compile code and gonk doesn't have anything.  I've opened a pull request that generates a buildid for the gonk layer using an arbitrary identifier: https://github.com/mozilla-b2g/gonk-misc/pull/31

This is something that can uniquely identify a specific *build* of gonk.
Now that the dogfood phones are out, could this please be expedited?

I'm sometimes having to type my full Git commit hash out while filing bug reports (technically I don't have to, but...), but it'll be nice to consolidate to some form of agreed format here.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Target Milestone: --- → B2G C1 (to 19nov)
You need to log in before you can comment on or make changes to this bug.