Bug 1565767

Summary: Jenkins pipeline build should inherit git http/https proxy from Jenkins Master \ Failed to build jenkins pipeline build from git repo behind http/https proxy
Product: OpenShift Container Platform Reporter: Vítor Corrêa <vcorrea>
Component: BuildAssignee: Gabe Montero <gmontero>
Status: CLOSED NOTABUG QA Contact: Wenjing Zheng <wzheng>
Severity: low Docs Contact:
Priority: unspecified    
Version: 3.5.0CC: aos-bugs, bparees
Target Milestone: ---   
Target Release: 3.10.0   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-10 20:20:30 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Vítor Corrêa 2018-04-10 17:53:21 UTC
Description of problem:

Failed to build jenkins pipeline build from git repo behind http/https proxy.
This case is similar to: https://bugzilla.redhat.com/show_bug.cgi?id=1405952
But, we'are able to see that the FIRST build fails. We can edit the git https proxy of the slave pod and if we run again it succeeds. 

"Per default, the 1st Jenkins build in a project creates a new Jenkins instance/pod in that project (if jenkins service does not exist) from a template, using standard image/configuration. This standard configuration does not contain any proxy definitions nor does the template.
Once the jenkins instance/pod has been setup in the project, one is able to configure a proxy via UI, so that the 2nd and further runs can use it. "

Steps to Reproduce:

Description of problem:
Failed to jenkins pipeline build from git repo on openshift cluster behind http/https proxy

Version-Release number of selected component (if applicable):
openshift v3.4.0.37+3b76456-1
kubernetes v1.4.0+776c994
etcd 3.1.0-rc.0

How reproducible:
Always

Steps to Reproduce:
1.Launch an openshift cluster behind http/https proxy
2.Create a project, create pipeline bc
 $ oc new-app https://raw.githubusercontent.com/openshift/origin/master/examples/jenkins/pipeline/samplepipeline.yaml
3.Edit bc to use git repo source, like below:
"source": {
            "type": "Git",
            "git": {
                "uri": "https://github.com/dongboyan77/jenkins-pipeline-ruby-test"
            }
        },
        "strategy": {
            "type": "JenkinsPipeline",
            "jenkinsPipelineStrategy": {
                "jenkinsfilePath": "jenkins/pipeline/Jenkinsfile"
            }
        },

4.Start a new pipeline build

Actual results:
Pipeline build failed, cannot git clone from git repo

Expected results:
Pipeline build succeed

Comment 1 Ben Parees 2018-04-10 18:49:18 UTC
I don't think there's actually anything we can do about this.

It sounds like the complaint is that the slave pod template doesn't define the proxy env vars.  That's not something we're going to fix, the slave pod templates provided are examples, it's up to you to modify or define new ones that work in your environment.  We provide numerous ways to inject your own slave pod template configurations.

(If we were going to do something in this space, it would need to be filed as an RFE)

Comment 2 Gabe Montero 2018-04-10 20:20:30 UTC
Yep Ben is correct, this is simply a matter of configuring the k8s pod template to pass the env  vars the jenkins git plugin needs.

And as Ben alluded, we have (way too many already) ways of injecting pod template config from openshift objects, as well as env vars, without having to go to the jenkins UI.

See 

https://docs.openshift.org/latest/using_images/other_images/jenkins.html#configuring-the-jenkins-kubernetes-plug-in

https://docs.openshift.org/latest/dev_guide/builds/build_strategies.html#jenkins-pipeline-strategy-environment

I see no need why an additional path specific to proxy env vars is needed.  And shipping an example out of the box is problematic because we don't ship a http proxy with openshift.

So I don't see a relevant RFE possibility.

If the customer has specific questions after reading those two doc links, repoen and we can go from there.