I’m facing similar problems during the setup. It’s tutorial is out-of-date.

Hi otheus,

the development environment hasn’t been properly upgraded for 7.0., but you shouldn’t use that as a base to set up a production environment. Please see the following resources for this information:

1. Download and Installation contains information regarding OpenProject packaged installation. We highly suggest anyone to use the packages if at all possible. We support most common Linux destributions.
2. https://github.com/opf/openproject/blob/release/7.0/docs/installation/manual/README.md

Our documentation is mostly available on GitHub, so feel free to improve or hint us what we didn’t properly upgrade. The development guide you mentioned resides here and still concerns OpenProject 5:
https://github.com/opf/openproject/blob/release/7.0/docs/development/setting-up-development-environment.md

Regarding your remarks about dependencies and NodeJS:

1. NodeJS v0.12.* support has ceased in 2016 and we were rather late to upgrade it. We now require the latest LTS, I don’t think that’s absurd. Since we provide packages that contain all required dependencies, we focus on supporting these distributions.

2. You do not need to install twice. There is a package.json in the OpenProject root for convenience, but npm install there simply yields to frontend and runs npm install there.

3. If you’re trying to do a manual installation and not using a version manager for both node and ruby, you’re doing it wrong. If you’re using one, it does not matter at all whether an application requires ruby 2.1. or ruby 2.4. We tend to keep running on the latest stable versions of all our dependencies
and OpenProject has gained significant performance improvements by doing so (especially in the step from ruby-2.1.x to 2.2.5 and since to 2.4.1).

I suspect that you do the following steps to clean up assets:

1. Remove <op root>frontend/bower_components, <op root>/node_modules and <op root>/frontend/node_modules

2. Re-run npm install

3. Re-run the precompilation step

On a side-note: Why don’t you use the packaged installation method described above?

Best,
Oliver

For now, i’m following the tutorial in https://github.com/opf/openproject-ce/tree/stable/7/docs/installation/manual.

I got stucked at Finish the installation of OpenProject section.

When i try to run the command RAILS_ENV="production" ./bin/rake assets:precompile
@
npm ERR! Exit status 137
npm ERR!
npm ERR! Failed at the openproject@0.1.0 postinstall script ‘cd frontend && npm install’.
npm ERR! This is most likely a problem with the openproject package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! cd frontend && npm install
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs openproject
npm ERR! Or if that isn’t available, you can get their info via:
npm ERR!
npm ERR! npm owner ls openproject
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR! /root/openproject-ce/npm-debug.log@

And part of the npm-debug.log file

27 error npm v2.15.11 28 error code ELIFECYCLE 29 error openproject0.1.0 postinstall: `cd frontend && npm install`
29 error Exit status 137
30 error Failed at the openproject@0.1.0 postinstall script ‘cd frontend && npm install’.
30 error This is most likely a problem with the openproject package,
30 error not with npm itself.
30 error Tell the author that this fails on your system:
30 error cd frontend && npm install
30 error You can get information on how to open an issue for this project with:
30 error npm bugs openproject
30 error Or if that isn’t available, you can get their info via:
30 error
30 error npm owner ls openproject
30 error There is likely additional logging output above.
31 verbose exit [ 1, true ]@

The @ ELIFECYCLE@ error is generic and doesn’t itself provide any useful information on what happens, other than the process it tried to run was killed or died.
It may be that your system doesn’t have enough RAM available and the process is terminated by an OOM killer.

Best,
Oliver

Yeah, Oliver was right again, it was a RAM issue, solved by adding some temporary SWAP space at my private host.

I finally finished the installation following the tutorial: https://github.com/opf/openproject/blob/release/7.0/docs/installation/manual/README.md

I’m running on Ubuntu 16.04, but it’s working. It took me hours, and was necessary to solve a lot of dependency related problems, plus other errors that i even don’t know how to explain, Google helped me a lot. xD

Oliver,

Thank you for the response. Together, I’m sure we’ll help to improve the community experience.

First, the real problem was a misake I had made with git. I had checked out the 7.0.2 repository, then attempted to merge my configuration changes into it. However, this also somehow merged parts of the existing 6.x into 7.0.2, a fact I only discovered after great difficulty and careful replaying of steps.

2. why not use the packages? Simply put, it’s not a best-case upgrade path from an existing 6.x manual installation-base. While I might be better off using a new VM and installing it there, I was hoping to merely “git pull” from 6.x and re-deploy. Alas. Second, the number of new dependencies and upgrades from the existing package may and probably will break things running on the existing system. Third, while I realize this is a good use-case for docker, I’m not interested in running docker in production at this time — there are still too many challenges with using the docker framework on a small scale for production.

3. Node-modules stuff. Remove <op root>frontend/bower_components, <op root>/node_modules and <op root>/frontend/node_modules. I didn’t realized node_modules needed to be cleaned out. Thanks. This helped.

4. the manual instructions for 7.0 to which you linked refer to using Ruby 2.3. The Gemfile requires 2.4. (But the comment above it states “We do not yet support 2.4”) Whatever performance benefits the project may benefit, it’s highly ill-advised to require new versions of your compiler/interpreter. Regression should always be done with the oldest supported version available. If this will work on 2.2.5, then that’s what should be specified. If some included gem requires 2.4, a work-around should be considered, such as an older version of the gem used, etc. From what I can tell, OpenProject stable does work on ruby 2.3.

Updating the Gemfile meant that running ‘bundle install’ must be run the first time without the ‘—production’ flag, and then once again with. The existing lockfile needed to be removed. Very non-obvious steps for non-devs. :) The manual-install documentation doesn’t mention this thing with Gemfile.lock.

4. As for node-js, this is such a rapidly evolving technology, I can understand the need to abandon a 2-year-old release. (0.12.5 was release June 2015!). I experienced errors due to features made available only in version 5 (or was it 6?). Luckily, EPEL has made this available. Still, the release cycle here is so absurdly fast, any software built on it will be obsolete by the time it can be deployed! Moving forward, please try to be conservative in adapting bleeding edge versions of node

First, the real problem was a misake I had made with git. I had checked out the 7.0.2 repository, then attempted to merge my configuration changes into it. However, this also somehow merged parts of the existing 6.x into 7.0.2, a fact I only discovered after great difficulty and careful replaying of steps.

If you’re on a manual installation, either symlink your overriding configuration or keep a separate ‘source’ branch where you apply the configuration from. It’s easiest then to simply git reset --hard stable/X to upgrade to the latest version.

2. why not use the packages? Simply put, it’s not a best-case upgrade path from an existing 6.x manual installation-base.

I can’t think of an easier way to upgrade than with packages. You only need to upgrade the package source from the stable/6 to stable/7 and install the new package, followed by openproject configure. I have migrated most of our large customer installations that way, and it’s very easy.

While I might be better off using a new VM and installing it there, I was hoping to merely “git pull” from 6.x and re-deploy. Alas. Second, the number of new dependencies and upgrades from the existing package may and probably will break things running on the existing system.

We try to keep dependencies to other packages to a minimum. Some are required, but as long as you’re on one of the supported distributions, there should not be breaking dependencies, but we instead resort to the maintained versions on your distribution wherever possible. The only exception is imagemagick, which we embed on some distros.

3. Node-modules stuff. Remove <op root>frontend/bower_components, <op root>/node_modules and <op root>/frontend/node_modules. I didn’t realized node_modules needed to be cleaned out. Thanks. This helped.

I took note and I will improve the setup/upgrade path for manual installations, since that affects us developers as well.

4. the manual instructions for 7.0 to which you linked refer to using Ruby 2.3. The Gemfile requires 2.4. (But the comment above it states “We do not yet support 2.4”) Whatever performance benefits the project may benefit, it’s highly ill-advised to require new versions of your compiler/interpreter. Regression should always be done with the oldest supported version available. If this will work on 2.2.5, then that’s what should be specified. If some included gem requires 2.4, a work-around should be considered, such as an older version of the gem used, etc. From what I can tell, OpenProject stable does work on ruby 2.3.

It will most likely work with 2.2.5, since there are no breaking syntactic changes we use, however we’re a complex application so you’ll have to buy into some versions that we require you to use. Requiring a particular version such as 2.4.1 recently allows us to maintain a testable application, since we cannot run our 6+ hours testsuite on multiple ruby, node, and distribution versions.

Updating the Gemfile meant that running ‘bundle install’ must be run the first time without the ‘—production’ flag, and then once again with. The existing lockfile needed to be removed. Very non-obvious steps for non-devs. :) The manual-install documentation doesn’t mention this thing with Gemfile.lock.

Since we provide the Gemfile.lock, you’ll always get the same gem set when running bundle install , even without the deployment flag. The deployment flag is useful to freeze the current installation, but you need to unfreeze it with --no-deployment for updating the Gemfile. The reason is simple, a frozen gemset must never be updated. I would suggest we remove the --deployment flag in the installation guide, since it’s not necessary if installing locally.

4. As for node-js, this is such a rapidly evolving technology, I can understand the need to abandon a 2-year-old release. (0.12.5 was release June 2015!). I experienced errors due to features made available only in version 5 (or was it 6?). Luckily, EPEL has made this available. Still, the release cycle here is so absurdly fast, any software built on it will be obsolete by the time it can be deployed! Moving forward, please try to be conservative in adapting bleeding edge versions of node

I agree, I’m not a big fan of the nodejs stack we employ for the frontend, however since sprockets for Rails previously had no support for the technology we employ (TypeScript and angular1 with ES5 transpilation enable), the status-quo and near future is currently with webpack. It requires us however to embed the entire stack into our packages, resulting in huge inode usage only to be able to compile assets on your machine when modified (e.g., due to an additional plugin being installed).

Best,
Oliver