Closed
Bug 1055268
Opened 11 years ago
Closed 11 years ago
Package Socorro
Categories
(Socorro :: Infra, task)
Tracking
(Not tracked)
RESOLVED
FIXED
101
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 | ||
Updated•11 years ago
|
Assignee: nobody → tbramwell
Comment 1•11 years ago
|
||
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.
Assignee | ||
Comment 2•11 years ago
|
||
(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.
Comment 3•11 years ago
|
||
All makes sense to me, thanks!
Comment 4•11 years ago
|
||
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
Updated•11 years ago
|
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Target Milestone: --- → 101
You need to log in
before you can comment on or make changes to this bug.
Description
•