For a while, device builds have been broken badly on both pine and m-c. Pine builds were fixed a few days ago, but m-c is still broken as of now. This means anyone looking at the treeherder status cannot check if B2G is broken or not.
This is about to change, but we will need help from anyone interested in B2G to keep it green.
You can track the current status on pine tree from the URL https://treeherder.mozilla.org/#/jobs?repo=pine&filter-tier=1&filter-tier=2&filter-tier=3&filter-searchStr=device when “B” is green it means it’s okay. When it’s orange, it’s broken and we need to fix it ASAP.
Now, on mozilla-central, this is going to be another story. There are multiple issues: build configuration have not been updated for a while and it still references a lot of broken stuff, including: use of stlport, missing build flags, old repos mirrors. The second main issue is that as of now, nobody can push to try with device builds.
What does it means? People can test patches using the TryServer as documented on https://wiki.mozilla.org/Build:TryServer, but the way Docker images for B2G device builds are currently done, we cannot make this possible. It makes merging tedious because one has to build locally to make sure device build works. In https://bugzilla.mozilla.org/show_bug.cgi?id=1282226 which is about to land, this is going to be fixed and this try syntax will work: “-p aries-eng,nexus-5l-eng”. This will issue a device build for Z3c eng (Kitkat base) and Nexus 5 eng (Lollipop base).
So, now, what can you do to help keeping the builds green? Anybody can do this:
- Keep an eye on Mulet builds on integration branch (mozilla-inbound): https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&filter-tier=1&filter-tier=2&filter-tier=3&filter-searchStr=mulet
- Keep an eye on Device builds on integration branch: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&filter-tier=1&filter-tier=2&filter-tier=3&filter-searchStr=b2g%20device
- Keep an eye on Device builds on mozilla-central: https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&filter-tier=1&filter-tier=2&filter-tier=3&filter-searchStr=b2g%20device
- Checking autoland repo also (alternative to mozilla-inbound): https://treeherder.mozilla.org/#/jobs?repo=autoland&filter-tier=1&filter-tier=2&filter-tier=3&filter-searchStr=b2g%20device
Anything that does not contains a green “B” means there is a build failure. Clicking on the “B” symbol will give you more details.
It is very important to catch build failure as soon as possible, hence, monitoring the integration branch is the most efficient way: we can issue a fix (often it’s very simple, missing includes or similar stuff) in time to land in mozilla-central.
What to do once you have spotted a build failure?
- File a bug that blocks https://bugzilla.mozilla.org/show_bug.cgi?id=1245091 so that anyone can be aware there is an issue
- Copy/paste the first line of the error in the bug title
- If possible, try to find (quickly, don’t waste too much time) which change is probably related to this. You can do this by looking at the history of the files impacted in the error and see what changed recently. If you can find a suspect, collect the bug number and also add this in the “blocks” field of the bug you filed
- If you have time/knowledge, you can try to make a patch !
It is very important that more people gets involved in this process:
- It’s critical that we keep builds green to be able to continue to hack
- Those changes are often simple breakages
- Because of (2), it makes those patches often simple to do and thus good first bug
- It’s a simple way to contribute efficiently to the codebase and get to learn it
Thanks for anyone’s hep!