ReleaseEngineering/Applications/Mapper: Difference between revisions

Jump to navigation Jump to search
Remove references to "old" or "legacy" mapper, which has been decommissioned
m (fix off by one error)
(Remove references to "old" or "legacy" mapper, which has been decommissioned)
Line 20: Line 20:
Mapper is written as a RelEng API blueprint - please note RelEng API has its [https://api.pub.build.mozilla.org/docs/ own documentation] too.
Mapper is written as a RelEng API blueprint - please note RelEng API has its [https://api.pub.build.mozilla.org/docs/ own documentation] too.


= Source =
mapper's source is currently hosted at https://github.com/mozilla/build-mapper


= Old Mapper Deployment =
= Mapper Development & Deployment =


Until the "New Mapper" goes live, this is the information about the "old mapper" (which is being superceded).
The mapper is a Releng API blueprint, and so the details about how to deploy locally for development, and where the staging/production environments are, can be seen in the [https://api.pub.build.mozilla.org/docs/ RelEngAPI documentation].


mapper only requires bottle to run. It's recommended to run inside a virtual environment


Our current production deployment of mapper lives on cruncher under /home/buildduty/mapper. It listens locally on port 8888 (specified in mapper/app.py). The apache instance on cruncher is configured to forward requests to http://cruncher/mapper/* to http://locahost:8888/* (configured in /etc/httpd/conf/httpd.conf)
= Mapper Data Feed =
 
The mapper process is managed by supervisord which will ensure it is started up if the machine is ever rebooted, or if the process crashes. (configured in /etc/supervisord.conf)
 
Source is available at https://github.com/catlee/mapper
 
= New Mapper Deployment =
 
The new mapper is a Releng API blueprint, and so the details about how to deploy locally for development, and where the staging/production environments are, can be seen in the [https://api.pub.build.mozilla.org/docs/ RelEngAPI documentation].
 
= Old Mapper Data Feed =
 
This section describes (roughly) how vcs-sync provides the map files served by mapper.
 
The map files are generated and combined on the vcs-sync machines, then pulled onto cruncher and used by `mapper`. See the [http://hg.mozilla.org/users/hwine_mozilla.com/repo-sync-tools/ source] and [http://people.mozilla.com/~hwine/tmp/vcs2vcs/ docs] for vcs-sync for more details. (Especially the [http://people.mozilla.com/~hwine/tmp/vcs2vcs/mapper_support.html mapper support] section.)
 
mapper expects hggit map files to be available under the 'mapfiles' directory of the application. On cruncher, these are in /home/buildduty/mapper/mapfiles. Each subdirectory of mapfiles corresponds loosely to a different repository being tracked. On cruncher, the mapfiles for each of these projects are symlinked to the mapfiles being published to cruncher via the process outlined above.
 
Legacy vcs-sync provides mapfile information for the following repository groupings. ''(These can be seen via "<tt>ls */mapfile-needed</tt>" in the legacy configs directory.)''
* git -> hg from <tt>gaia.git</tt> code to <tt>integration/*</tt> (11 repositories configured)
* hg -> git for gaia L10N (75 repositories configured)
* hg -> git for gecko L10N (50 repositories configured)
* hg -> git for gecko.git (15 repositories configured - from <tt>releases-gecko/hgrc</tt>)
 
''Note that the above docs will be integrated into the wiki after vcs-sync development stabilizes.''
 
= New Mapper Data Feed =


VCS Sync is making HTTP Post requests to mapper, providing new mappings for mapper to insert into its database.
VCS Sync is making HTTP Post requests to mapper, providing new mappings for mapper to insert into its database.
Confirmed users
1,364

edits

Navigation menu