Bug 1034175 - Jenkins build will reinstall existing package for ruby-1.8/1.9 app
Summary: Jenkins build will reinstall existing package for ruby-1.8/1.9 app
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: OpenShift Online
Classification: Red Hat
Component: Image
Version: 2.x
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
: ---
Assignee: Michal Fojtik
QA Contact: libra bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-25 12:00 UTC by Lei Zhang
Modified: 2015-05-15 00:35 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-11-26 01:59:20 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Lei Zhang 2013-11-25 12:00:12 UTC
Description of problem:
Create  ruby-1.9 app embedded with jenkins client, build twice, found jenkins build will reinstall existing package in the second time.  

Version-Release number of selected component (if applicable):
devenv_4067

How reproducible:
always

Steps to Reproduce:
1.Create one ruby-1.9 app with jenkins-client
#rhc app create myruby19 ruby-1.9 --enable-jenkins
2.Add Gemfile and Gemfile.lock, and then git push
# cat Gemfile
source 'https://rubygems.org'

gem 'ref'
gem 'rack'
#cat Gemfile.lock
GEM
  remote: http://rubygems.org/
  specs:
    rack (1.5.2)
    ref (1.0.5)

PLATFORMS
  ruby

DEPENDENCIES
  rack
  ref


3.Change some thing in local repo and git push again
#

Actual results:
Found jenkins build will reinstall existing package again

Expected results:
Jenkins build should not install existing package again

Additional info:

Comment 1 Lei Zhang 2013-11-25 12:01:54 UTC
+ gear build
Building git ref 'origin/HEAD', commit 4ee078e
Building Ruby cartridge
Bundling RubyGems based on Gemfile/Gemfile.lock to repo/vendor/bundle with 'bundle install --deployment'
Fetching gem metadata from http://rubygems.org/..........
Installing rack (1.5.2) 
Installing ref (1.0.5) 
Using bundler (1.1.4) 
Your bundle is complete! It was installed into ./vendor/bundle
+ /usr/libexec/openshift/cartridges/jenkins/bin/git_ssh_wrapper.sh 5293366c2587c8a39b00022d.rhcloud.com 'gear stop --conditional --exclude-web-proxy --git-ref 4ee078e694e439d0efcfe061bba22e1eb3ec697b'
Stopping gear...
Stopping Ruby cartridge
Waiting for stop to finish
++ /usr/libexec/openshift/cartridges/jenkins/bin/git_ssh_wrapper.sh 5293366c2587c8a39b00022d.rhcloud.com 'gear create-deployment-dir'
+ deployment_dir=2013-11-25_06-44-48.990
+ rsync --delete-after -az -e /usr/libexec/openshift/cartridges/jenkins/bin/git_ssh_wrapper.sh /var/lib/openshift/5293377e2587c8a39b00024a//app-deployments/current/metadata.json 5293366c2587c8a39b00022d.rhcloud.com:app-deployments/2013-11-25_06-44-48.990/metadata.json
+ rsync --delete-after -az -e /usr/libexec/openshift/cartridges/jenkins/bin/git_ssh_wrapper.sh --exclude .git /var/lib/openshift/5293377e2587c8a39b00024a/app-root/runtime/repo/ 5293366c2587c8a39b00022d.rhcloud.com:app-root/runtime/repo/
+ rsync --delete-after -az -e /usr/libexec/openshift/cartridges/jenkins/bin/git_ssh_wrapper.sh /var/lib/openshift/5293377e2587c8a39b00024a/app-root/runtime/build-dependencies/ 5293366c2587c8a39b00022d.rhcloud.com:app-root/runtime/build-dependencies/
+ rsync --delete-after -az -e /usr/libexec/openshift/cartridges/jenkins/bin/git_ssh_wrapper.sh /var/lib/openshift/5293377e2587c8a39b00024a/app-root/runtime/dependencies/ 5293366c2587c8a39b00022d.rhcloud.com:app-root/runtime/dependencies/
+ /usr/libexec/openshift/cartridges/jenkins/bin/git_ssh_wrapper.sh 5293366c2587c8a39b00022d.rhcloud.com 'gear remotedeploy --deployment-datetime 2013-11-25_06-44-48.990'
Preparing build for deployment
Deployment id is ef801585
Activating deployment
Starting Ruby cartridge
Archiving artifacts
Finished: SUCCESS

Comment 2 Michal Fojtik 2013-11-25 14:25:26 UTC
After some investigation, I think this is not a bug... The problem here is that $REPO_DIR/vendor is not in 'ruby' cartridge, so we can't use 'dependency_dirs' in managed_files to keep these dependencies.

Users can replace the 'vendor' directory with their own versions of gems, and for that we need to install them all the time. I don't think this is ideal...

Lei Zhang: Is this a regression or something? I mean did this work before?

Comment 4 Michal Fojtik 2013-11-25 15:56:05 UTC
It might be a regression, as we had some customizations for Ruby cartridge in jenkins script:

https://github.com/openshift/origin-server/blob/a0d52b785e7317a1da7c466fc0e4e02b0c5967a9/cartridges/openshift-origin-cartridge-ruby/metadata/jenkins_shell_command.erb#L9

Comment 5 Michal Fojtik 2013-11-25 17:02:33 UTC
A Trello card has been created for this bug:

https://trello.com/c/bafgWN1Z/79-support-cartridge-specific-jenkins-hooks-that-runs-during-the-jenkins-build

Adding UpcomingRelease as this is not a blocker and I think we should fix this properly for all carts instead of hacking something up for Ruby ;-)

Comment 6 Dan McPherson 2013-11-26 01:59:20 UTC
We are going to live with this limitation for jenkins builds with ruby apps.


Note You need to log in before you can comment on or make changes to this bug.