Closed Bug 1096001 Opened 10 years ago Closed 9 years ago

Builds from project branches cannot be bisected since 0.24

Categories

(Testing :: mozregression, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: elbart, Unassigned)

References

Details

0.24 removed the feature to bisect in other nightly-repos like ux.

https://github.com/mozilla/mozregression/commit/2062de8c66c16bf792ed995e9cf2bf144f060398

This makes bisecting bugs e.g. coming from ux/fx-team rather difficult.
Blocks: 996810
The parameter is also mentioned on http://mozilla.github.io/mozregression/
Those branches are called project branches. Updating summary for a better query.
Summary: Other nightly-repos cannot be bisected since 0.24 → Builds from project branches cannot be bisected since 0.24
It seems like a duplicate of bug 1096250.
I think that this bug is resolved on master. Note that we have two options now (for some time there was a confusion between two things in mozregression) but --repo is back, with the same meaning:

mozregression -h
...
  --repo [mozilla-aurora|mozilla-beta|...]
                        repository name used for nightly hunting.
  --inbound-branch [b2g-inbound|fx-team|...]
                        inbound branch name on ftp.mozilla.org.
...

Elbart, do you agree ?
I wonder why repo and inbound-branch still have to live side-by-side. Why can't we simply use --repo for all? fx-team like any other project branch are also repositories.
(In reply to Henrik Skupin (:whimboo) from comment #5)
> I wonder why repo and inbound-branch still have to live side-by-side. Why
> can't we simply use --repo for all? fx-team like any other project branch
> are also repositories.

That's a good question, and looking at it I must agree that it is still confusing to me. Ultimately, for nightlies, --repo is used for:

http://ftp.mozilla.org/pub/mozilla.org/%s/nightly/%04d/%02d/{REPO}

where {REPO} will be either the --repo value, or a repo name calculated for a given date and a given app.

On inbound, it will be something like (using --inbound-branch):

http://inbound-archive.pub.build.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/{INBOUND_BRANCH}-{ARCH}

where {INBOUND_BRANCH} will be the value of the --inbound-branch or some default for each app ('mozilla-inbound' for firefox, 'b2g-inbound' for B2G, ...)

If I look at the b2g config for example, default value for {REPO} is 'mozilla-central' (date is not taken in account for B2G) but default value for {INBOUND_BRANCH} is 'b2g-inbound' - this makes me think that these values may not be the same in all cases.

There is also one rule saying that we can't go from nightlies bisection to inbound bisection when a custom {REPO} was defined (see bug 1096250 comment 6). But that means that we can go to inbound with a specific {INBOUND_BRANCH} (does that make sense ?).

Well as you can read this is all a bit unclear to me, as I am not really aware of how project branches works and what are the naming conventions for build folders. I would love more explanations to make things simple if that is possible.
Project branches are used by different development teams for specific integration work, which takes longer to get implemented and cannot be merged regularly into mozilla-inbound or mozilla-central. But those branches receive the latest changes from mozilla-central. The only thing you might have to know is that in nearly all the cases the code on those project branches is based on mozilla-central. Otherwise they behave similarly to other repos like mozilla-aurora, mozilla-beta, etc.
Thinking again about it, I suppose that we could use only one command line option --repo.

1. If we are bisecting nightlies and the option is defined, we use it as {REPO} value.
2. If we are bisecting inbound (but not going from nightly bisection, see after), we use it as {INBOUND_BRANCH} value.

Since there is a rule that says that we can not go from nightly to inbound when {REPO} is defined (bug 1096250 comment 6), we won't have a conflict. So I think that we could have one option for the two concepts (maybe I should say internal mozregression concepts).

Henrik, what do you think ?
Flags: needinfo?(hskupin)
I don't know that much about the internals of mozregression, and I also think that William should be asked for that specific handling. I just gave my input based on my experience in downloading builds from various branches via mozdownload.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(hskupin) → needinfo?(wlachance)
I think the current behaviour is what we want. Really repo's and inbound branches are quite different animals and I think conflating the two is going to be more confusing than helpful. Instead, we should improve our documentation story so that people know how to use mozregression for these use cases (e.g. bisecting regressions on aurora builds or bisecting a regression into fx-team), see bug 1107602. That said, 99% of the time, mozregression's default behaviour (bisect nightlies, then mozilla-inbound) is going to be what people want to do.

The bug as described originally should be fixed in the latest master, as far as I am aware.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(wlachance)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.