GNOME Bugzilla – Bug 675934
api.gnome.org/jhbuild/*
Last modified: 2016-10-31 16:26:50 UTC
Bug 675873 is about moving modulesets out of the jhbuild tree; past experience in moving modulesets tells us this brings quite a lot of inquiries as jhbuild stops working on "cannot find moduleset"; it would be nice to avoid this and the best solution so far is to bless api.gnome.org/something as the place where modulesets will be, now and forever. The initial plan was to ask for a hook to copy files from the git module to a location such as http://api.gnome.org/modulesets/$version/ but now I wonder if we could simply have http://api.gnome.org/modulesets/$version/gnome.modules as a static file, that would '<include ...>' the right locations. This adds an indirection level but would help in case of filename changes. Do you sysadmin have a preference on this?
(ideally it would be served on https but this bug shouldn't block on that aspect).
The GNOME Infrastructure Team is currently migrating its bug / issue tracker away from Bugzilla to Request Tracker and therefore all the currently open bugs have been closed and marked as OBSOLETE. The following move will also act as a cleanup for very old and ancient tickets that were still living on Bugzilla. If your issue still hasn't been fixed as of today please report it again on the relevant RT queue. More details about the available queues you can report the bug against can be found at https://wiki.gnome.org/Sysadmin/RequestTracker. Thanks for your patience, the GNOME Infrastructure Team
This was still valid and blocking bug 675873; as bugzilla is now back to being the place for such requests, I'm reopening it.
How hard is the requirement to have the moduleset files hosted under the api.gnome.org's hood? Right now we have static.gnome.org which is served by the proxies (which guarantees redundancy and fall back in case any of the two proxies goes down) and hosts all the static content for the GNOME websites and services. Would it be OK to have a subdirectory there in the form of i.e static.gnome.org/jhbuild? the static-web repository has a hook that automatically reflects the content changes to the server already. This might be a solution in case we are not relying on any of the files hosted under api.gnome.org.
I don't care much about the domain name but the modulesets are going to be maintained in the gnome-modulesets repository and its branch structure will probably mean it cannot readily be exported as static-web is. There are per-version branches, and they each have to be mapped to a directory; for example gnome-apps.modules of branch gnome-3-16 should be accessible as /3.16/gnome-apps.modules.
Any reason why this is taking so long time? Or simply no one has time to do this?
Hi Andrea, Do you think someone for the infra team will have time to implement this for this cycle?
Hey, yes, I should be able to handle it. Do you have a deadline in mind for this request to be finalized?
Great you can look into it; as far as a deadline the initial request is from 2012 so I think whenever you can do it is fine.
3.22 development has been opened, any chance this can be done this cycle?
This should be done: https://static.gnome.org/modulesets Whenever a new GNOME release is out please let the Sysadmin Team know as the hash table should be populated accordingly. [1] Please let me know if there's anything else missing, otherwise please close the bug report. Thanks! [1] https://infrastructure.gnome.org/browse/puppet/tree/modules/modulesets/manifests/init.pp
(In reply to Andrea Veri from comment #11) > This should be done: > > https://static.gnome.org/modulesets > > Whenever a new GNOME release is out please let the Sysadmin Team know as the > hash table should be populated accordingly. [1] uh, not sure this is what I want; we need https://static.gnome.org/modulesets being updated every time we push changes to the git.gnome.org/gnome-modulesets repo
Yes, that's what happens, what I meant is at every new GNOME release we require the following code to be added to puppet [1] for a new directory to be created / populated with the correct branch. [1] https://infrastructure.gnome.org/browse/puppet/commit/?id=d2ed8a1
Should not there be one more line? 3.24 => { branch => 'master' }, or 'next' => { branch => 'master' }, or 'dev' => { branch => 'master' },
Good catch, added [1]. Next puppet run will bring it in. [1] https://infrastructure.gnome.org/browse/puppet/commit/?id=8df2a0f
Works like a charm, thanks! Can we change the redirection so we always have a "master" folder and then we add 3.24, 3.26 ... etc when we a new release is out?
(In reply to Javier Jardón (IRC: jjardon) from comment #16) > Works like a charm, thanks! > > Can we change the redirection so we always have a "master" folder and then > we add 3.24, 3.26 ... etc when we a new release is out? This has been implemented as well, thanks Andrea! Closing ...