search

openshift / jenkins

Apache License 2.0
260 stars 447 forks source link

duplicated openshift-pipeline in /var/lib/jenkins/plugin folder #101

Closed rafabene closed 8 years ago

rafabene commented 8 years ago

I have dumped my desired Jenkins dependencies in a plugin.txt file.

Following the instructions of the s2i custom-build, I ended with two openshift-pipeline.hpi in /var/lib/jenkins/plugin folder

41 May 19 03:21 openshift-pipeline.hpi -> /usr/lib64/jenkins/openshift-pipeline.hpi 4124260 May 19 03:21 openshift-pipeline.jpi

This also happened with:

bparees commented 8 years ago

can you share the exact content of your plugin.txt and the buildconfig you used?

rafabene commented 8 years ago

Sure. The resources are here: https://github.com/redhat-helloworld-msa/jenkins

bparees commented 8 years ago

@gabemontero you might have some thoughts here since you've done more w/ installing plugins than i have.

rafabene commented 8 years ago

It seems that using openshift/jenkins-1-centos7 is fine. The problem seems to be in the latest rhel image.

gabemontero commented 8 years ago

A couple of thoughts (and possibly an answer):

For RHEL: /usr/lib64/jenkins/openshift-pipeline.hpi - this comes from the RPM install that @tdawson does for us /opt/openshift/plugins/openshift-pipeline.hpi - this is an ln from our RHEL Dockerfile for the Jenkins image

For Centos: /opt/openshift/plugins/openshift-pipeline.jpi

So I suspect the plugins.sh scirpt needs to do some special processing for the openshift-pipeline plugin where it

bparees commented 8 years ago

I do know from the work I did for the jenkins extended test on origin that user the "jpi" suffix is the way to override an existing plugin install with a new version.

if that's true, shouldn't it have taken precedence over the .hpi symlink? I can't remember from @rafabene's original problem if we knew which one took precedence or there was some conflict with both of them getting loaded? If the jpi is in fact taking precedence, it sounds like we're fine as is.

Special processing to handle all the .hpi files we might already included in the image is scary.

gabemontero commented 8 years ago

Well, perhaps I misread the doc I found, or it is incorrect :-) ... for reference, it is here

And looking back, with our centos image only having a .jpi file, perhaps was is happening with the jenkins extended test is that we are replacing the plugin file vs. having 2 copies and the jpi file overrides the hpi file.

Probably just need to try the theory out. We could make the change generic in plugins.sh, where it looks for any file with the same base file name with a .hpi suffix and remove it before copying over the .jpi file.

gabemontero commented 8 years ago

I circled back to this and believe I have a solution. My theory of having both the hpi and jpi files present seems to have been correct. A change to the rhel7 docker file's ln so that the destination file ends with jpi makes it copacetic with the plugins.sh script. That script's download and its replacing of the jpi file now works the same was as it does with the centos image, as we are only dealing with jpi files.

I'll submit a PR momentarily.

bparees commented 8 years ago

fyi i did a little research on hpi vs jpi when looking into this the other day and the answer is just that hpi is a hudson(ie the old name for jenkins) plugin extension and jpi is a jenkins plugin extension. so we should always be using jpi at this point, rather than calling something hpi and then trying to override it with a jpi.

all of which goes to say it sounds like your plan aligns w/ that anyway.