Closed Bug 1055268 Opened 10 years ago Closed 10 years ago

Package Socorro

Categories

(Socorro :: Infra, task)

x86_64
Linux
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bramwelt, Assigned: bramwelt)

Details

Currently Socorro is installed by running `deploy.sh` on a server to download and install the current version build by Jenkins. It would be nice to have Socorro installable, as either a deb or rpm package. This would simplify to deployment process to be: download package, dpkg/rpm -i. My idea is that all of the steps in 'deploy.sh' would be moved into pre/post install scripts. pre/post remove scripts would need to be written to allow for easy downgrades/rollbacks. After discussing this with on IRC with rhelmer, we came to a couple of conclusions. To fit the classic view of how software is built and packaged, two things should change with the Makefile. 1) `make` should build the project. Currently what 'install.sh' does. 2) `PREFIX=.. make install` should create a deb or rpm created in the project directory, setting the root of files to PREFIX. Note: The use of "PREFIX" here is different than how the current used in 'install.sh'. There it is more of a build directory, where PREFIX is classically used to define the root directory a project will get installed to. Ex. PREFIX=/opt/socorro, when installed would contain: /opt/socorro/socorro-virtualenv, and /opt/socorro/application
Assignee: nobody → tbramwell
Sorry silly questions/clarifications: (In reply to Trevor Bramwell :bramwelt from comment #0) > Currently Socorro is installed by running `deploy.sh` on a server to > download and install the current version build by Jenkins. > > It would be nice to have Socorro installable, as either a deb or rpm > package. This would simplify to deployment process to be: download package, > dpkg/rpm -i. My idea is that all of the steps in 'deploy.sh' would be moved > into pre/post install scripts. pre/post remove scripts would need to be > written to allow for easy downgrades/rollbacks. > > After discussing this with on IRC with rhelmer, we came to a couple of > conclusions. To fit the classic view of how software is built and packaged, > two things should change with the Makefile. > 1) `make` should build the project. Currently what 'install.sh' does. So would this populate the "./build" directory with binaries, virtualenv etc? > 2) `PREFIX=.. make install` should create a deb or rpm created in the > project directory, setting the root of files to PREFIX. Wouldn't this be what the debian/rules (deb) or SPEC file (rpm) does - that is, call "PREFIX=(chroot) make install" and then build the package based on the chroot? If it actually makes the packages I'd call it something like "make package" or "make rpm"/"make deb" etc, but that's all probably overkill... seems like packaging could be run directly.
(In reply to Robert Helmer [:rhelmer] from comment #1) > So would this populate the "./build" directory with binaries, virtualenv etc? Correct. Running `make` by itself would create `builds/socorro` and copy in the virtualenv, configs, application, wsgi files, webapp, stackwalker, etc. Exactly why `install.sh` does currently with changes to the destination path under `builds/socorro`. If you want to change the build directory, it would be: $ export BUILD_DIR=/tmp/socorro $ make > > 2) `PREFIX=.. make install` should create a deb or rpm created in the > > project directory, setting the root of files to PREFIX. > > Wouldn't this be what the debian/rules (deb) or SPEC file (rpm) does - that > is, call "PREFIX=(chroot) make install" and then build the package based on > the chroot? Yup. The default PREFIX ('/data/socorro') would make the package look like: /data/socorro/socorro-virtualenv /data/socorro/application Setting the PREFIX to something else (like '/usr/local') would look like: /usr/local/socorro-virtualenv /usr/local/application > If it actually makes the packages I'd call it something like "make package" > or "make rpm"/"make deb" etc, but that's all probably overkill... seems like > packaging could be run directly. make package could be easily added later to call 'script/package.sh', but the whole point of a build ('build.sh') is a package comes out ready for distribution.
All makes sense to me, thanks!
Commits pushed to master at https://github.com/mozilla/socorro https://github.com/mozilla/socorro/commit/fc91098c76d80f620b0658be576b54c917a3d93f Add 'package' make target. Like, 'make install' this will not currently work on it's own without environment variables being set first. fix bug 1055268 https://github.com/mozilla/socorro/commit/c654b6182d8b3e47103f8aff0603e41d0703ac93 Merge pull request #2323 from bramwelt/fix-bug-1055268-package-socorro-2 fix bug 1055268 - Package Socorro
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 101
You need to log in before you can comment on or make changes to this bug.