Closed Bug 509290 Opened 15 years ago Closed 15 years ago

Branch mozmill-test repository for mozilla1.9.1

Categories

(mozilla.org Graveyard :: Server Operations, task)

Product:
mozilla.org Graveyard
Component:
Server Operations
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: whimboo, Assigned: aravind)

Details

With bug 503285 we will clone the entire Firefox 3.5 test-run on Litmus for Firefox 3.6.

Meanwhile a couple of features have been implemented on trunk and also back-end changes were checked in which will make some Mozmill tests fail on trunk. We cannot cover those changes for ever in one branch of the mozmill-test repository. Therefor we should branch (or tag). I believe branching is the better way because a lot of additions will happen on such a branch.

Clint, which steps would we need or better who can do the cloning? Do we need someone from IT?
Yes, IT has to get involved if you want to branch the test repo as I understand it.  So, this should probably really be an IT bug.
We should figure out what is the best way. Moving bug to IT.
Assignee: nobody → server-ops
Component: Mozmill → Server Operations
Product: Testing → mozilla.org
QA Contact: mozmill → mrz
Version: unspecified → other
We can clone this repo for you.  What would you like the cloned repo called?
Assignee: server-ops → aravind
Where will this cloned repository be placed? Directly under http://hg.mozilla.org/qa/? I'm worried that we will blow up the list of repositories listed in this folder. So cloning is the only way to give the chance to work on different branches?

If yes and we could move the folders what about the following structure?

http://hg.mozilla.org/qa/
                         mozmill-tests/
                                       trunk
                                       3.0
                                       3.5  

That way we would have to move our existing repository. Would this be feasable? Everyone would have to clone the repository again for a local copy.

Clint and Mikeal, what do you think about?
I am not sure if cloning is your only option, you can have multiple heads in your repos, but I know that its frowned upon in our mozilla-central repo.  I'd talk to someone in #hg and figure out how to best do this.

If you do decide that you want to clone stuff, and change the directory structure to whats shown in comment 4, thats fine as well.  Please note that nested directories will now show up in the web view at hg.m.o/qa.

Either way, please comment here once you guys have an idea as to how you want to proceed.
I talked with Clint yesterday and we ack that multiple heads is not an option we wanna have for the mozmill-test repository. Having the directory structure I have mentioned in comment 4 is fine. Also having nested directories showing up. So we could clone the repository.
Aravind, can you give us an ETA when you can clone the repository?
http://hg.mozilla.org/qa/mozmill-tests/ is now up.  However, there is no link from http://hg.mozilla.org/qa (since we share the main template for all the reports).
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Thanks Aravind. But we really need a reference from http://hg.mozilla.org/qa to our repository. I hope there is way we can add it.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
There is no way for me to add custom templates into the wsgi configuration.  If you want the repos to show up in the top level, I suggest doing something like hg.m.o/qa/mozmill-trunk, hg.m.o/qa/mozmill-3.0 and hg.m.o/qa/mozmill-3.5.

Is that acceptable?
(In reply to comment #10)
> There is no way for me to add custom templates into the wsgi configuration.  If
> you want the repos to show up in the top level, I suggest doing something like
> hg.m.o/qa/mozmill-trunk, hg.m.o/qa/mozmill-3.0 and hg.m.o/qa/mozmill-3.5.
> 
> Is that acceptable?

When we don't have another option at the moment we should go this way, yes.

Ted, it looks like that we don't support a folder structure with more than two level depth. Are there plans to make it somekind recursive or at least support three levels?
Repos showing up now as I listed above.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Henrik: AIUI, this is a limitation of hgweb, not something we can fix locally without hacking Hg itself.
Multiple heads wouldn't have to be so painful if you just used named branches; that could work fairly well, IMO.

As for the hgwebdir woes, I'm not entirely clear on what the problem is? hgwebdir is certainly capable of recursing into nested directories. Not sure what the template issues would be, they normally don't pose problems for this sort of thing. Can anyone outline what the desired page looks like and why that's supposedly not possible?
Ok, it looks like a ping pong game now but lets really find the best option here. Thankfully to Dirkjan's comment I was able to know about named branches. I wasn't aware of those before. Having in mind that our Mozmill repository is not as big as mozilla-central we should really go this way and using named branches then. Using this way we don't clutter the /qa folder on hg.mo and have simpler mechanism for users to switch between branches without the need of cloning different repositories. Aravind, could you please revert the changes so it will look like before? I will do the branching on my own then. Sorry for the chaos.

(In reply to comment #14)
> sort of thing. Can anyone outline what the desired page looks like and why
> that's supposedly not possible?

See comment 4 for the desired look of the web page. But having three repositories under mozmill-tests will not show up "mozmill-tests" as a folder on http://hg.mozilla.org/qa/. I feel it should better be moved to its own bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
FYI, recent versions of hg are more polished WRT named branches, so if you're still using something before 1.3, upgrading might be helpful.
And, hgweb should automatically do subdirs if you use / in the repository identifier, i.e. mercurial/crew and mercurial/crew-stable on the root will show up as two repositories in /mercurial/.
(In reply to comment #16)
> FYI, recent versions of hg are more polished WRT named branches, so if you're
> still using something before 1.3, upgrading might be helpful.

So this will apply to the server or client side? On the servers we have 1.2 installed which will not be changed in the near future. Does it mean it is harder to manage named branches? Before we revert the changes it would be good to know if we will be able to manage named branches with 1.2 on the server side. Thanks!
It doesn't really matter too much for the server (although 1.3 sports a branches page in the default paper style that 1.2 doesn't have); it's mostly UI niceties in the client.
This is mostly meant @djc

I said that we couldn't do what whimboo wanted for dir listing.  For mod_wsgi to work correctly with mercurial, we have to trap certain paths and hand off any requests below a url to the python handlers.  Afaik, this works for one level only, so we have that in place.  So for example, we have repos at the top level on hg.m.o. We also have a cluster of repos at hg.m.o/build /labs and /qa etc.  What whimboo wanted was another level down from that with hg.m.o/qa/mozmill/r1, r2 and so on.  We can certainly have that cluster of repos and display it properly when someone goes to hg.m.o/qa/mozmill by using url patterns to catch the right ones and handing off the appropriate wsgi handlers.  However I do not know of an easy way to display that you have a cluster of repos below a level.

In other words, I don't know of an easy way to display hg.m.o/qa with the list thats currently there and provide a link there to the mozmill cluster which is one more level down.

The only way I know to do this is using the footers, and those are shared across all the mozilla repos.  It really doesn't make sense to display a QA specific mozmill repo as a footer to every single repo list page.


The other problem I wanted to bring up was that I accidentally tried hg 1.3 yesterday on a new read-only slave and it turns out that hg 1.3 does not work with our current templates and extensions, I found that it errors out on our bugzilla extension for some reason.  Also (and this may be related to the previous error), I found that it doesn't properly linkify the repos from the repo list page.  So the repo list page at say hg.m.o/build would have links to repos at hg.m.o/buildbot instead of http://hg.m.o/build/buildbot/ like it should.
Ok, I checked the named branch stuff for a repository on my local disk and everything works fine. Together with Clint we have decided we should go back to the original state. Means we wanna have the repository located at http://hg.mozilla.org/qa/mozmill-tests. No need for sub-folders or cloning the repository.

Aravind, please go ahead and revert everything. Thanks!
We are now back to mozmill-tests.  Should show up in the website in a few minutes.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Thanks for your patience! Looks good so far and I will branch for 3.5 tomorrow.
Status: RESOLVED → VERIFIED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.