Questions :)

[peterbaouoft]

To track questions I encounter / may encounter in this issue :p

1: "$GITHUB_TOKEN" refers to the github token we got from github I assume?

2: I am not too familiar with openshift CLI syntax, but I got the following error while following instructions: they seem to not recognize dc and bc as resources, which is very weird. Can't seem to find a solution online either :(. But it might be the version difference + mismatch tho. (3.9 vs 3.6.1)

[root@localhost jenkins]# oc rollout latest dc/jenkins
the server doesn't have a resource type "dc"
[root@localhost jenkins]# oc logs --follow bc/paci-jenkins
the server doesn't have a resource type "bc"

[root@localhost jenkins]# oc version
oc v3.9.0+191fece
kubernetes v1.9.1+a0ce1bc657
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://127.0.0.1:8443
openshift v3.6.1+269e828-9
kubernetes v1.6.1+5115d708d7

3: If I acciedentally run oc start-build paci-jenkins multiple times,would the image just simply get rebuilt, is the effect cumulative for starting multiple jobs? (and no side effects should happen I guess :p? )

The logs of oc status is attached below:

[root@localhost jenkins]# oc status
In project projectatomic-ci on server https://127.0.0.1:8443

https://jenkins-projectatomic-ci.127.0.0.1.nip.io (redirects) (svc/jenkins)
  dc/jenkins deploys istag/paci-jenkins:latest <-
    bc/paci-jenkins source builds https://github.com/projectatomic/projectatomic-ci-infra#master on istag/jenkins:stable 
      build #3 new for 30 seconds
      build #2 new for 4 minutes
      build #1 succeeded 3 minutes ago - 0889a6a: jenkins/papr: more PAPR integration improvements (Jonathan Lebon <[email protected]>)
    deployment #1 deployed 3 minutes ago - 1 pod

svc/jenkins-jnlp - 172.30.105.43:50000
  dc/jenkins deploys istag/paci-jenkins:latest <-
    bc/paci-jenkins source builds https://github.com/projectatomic/projectatomic-ci-infra#master on istag/jenkins:stable 
      build #3 new for 30 seconds
      build #2 new for 4 minutes
      build #1 succeeded 3 minutes ago - 0889a6a: jenkins/papr: more PAPR integration improvements (Jonathan Lebon <[email protected]>)
    deployment #1 deployed 3 minutes ago - 1 pod

bc/job-builder is a Jenkins Pipeline
  not built yet

bc/paci-jenkins-slave docker builds https://github.com/projectatomic/projectatomic-ci-infra#master
  -> istag/paci-jenkins-slave:latest
  not built yet

bc/papr docker builds https://github.com/projectatomic/papr#master
  -> istag/papr:latest
  not built yet

3 warnings identified, use 'oc status -v' to see details.

[jlebon]

Thanks for trying this out Peter! :)

1: "$GITHUB_TOKEN" refers to the github token we got from github I assume?

This is the GitHub access token to use if you want PAPR to actually update GitHub as it tests commits. You can create your own token at https://github.com/settings/tokens. Make sure to keep it as safe as your password if you do. You'll want to enable the "repo" and "user:email" scopes. But note that you don't have to have a token. You can remove the github key from the ConfigMap here:

paci/jenkins/paci-jenkins.yaml

Line 152 in 0889a6a

github:

. In that case, PAPR won't actually try to update GitHub. Similarly for AWS keys. See: https://github.com/projectatomic/papr/blob/ocp/docs/sample.site.yaml.

2: I am not too familiar with openshift CLI syntax, but I got the following error while following instructions: they seem to not recognize dc and bc as resources, which is very weird. Can't seem to find a solution online either :(. But it might be the version difference + mismatch tho. (3.9 vs 3.6.1)

Yeah, I think this was deprecated in the new version. You can try using just oc rollout latest jenkins. For buildconfigs, you can use start-build --follow instead.

3. If I acciedentally run oc start-build paci-jenkins multiple times,would the image just simply get rebuilt,? (and no side effects should happen I guess :p? )

It will build the image, and then redeploy Jenkins. But you won't lose any state. (Hence the instructions to delete the PVC if you do want to wipe all Jenkins state).

[peterbaouoft]

Thanks, those made sense, and I think I have completed the setup \o/. But I have a few more questions 😄.

1: How is image location https://jenkins-projectatomic-ci.127.0.0.1.nip.io/ determined? Is it defined like that by default?

2: When the webhook from github gets forwarded by ultrahook to the image/hook location. i.e https://jenkins-projectatomic-ci.127.0.0.1.nip.io/{github-webhook/, ghprbhook/}. how were those hook locations created in the first place? Or, why do forwarding to these locations can trigger events?

3:

When GitHub webhooks are received, the GHPRB jobs trigger PAPR tests using the papr-trigger.py script

I want to clarify a bit :p, can we conclude the above sentence into the following steps?

• User types bot related commands like bot, retest this please
• The webhook forwarded to the ghprbhook location
• Then a job builder gets created, and scripts in the builder gets called
• papr_trigger.py then finally get called?

Does that sound right for the steps?

4: It kinda felt a bit odd/suprising to me that all the steps can be done in a single host. I searched a bit online and it seems like Jenkins master & slave architecture was more targetting a distributed build case. Wouldn't that(distributed build) usually require multiple machines/VMs to complete then? I might miss/misunderstood some important info/knowledge here tho :p.

[cgwalters]

1: How is image location https://jenkins-projectatomic-ci.127.0.0.1.nip.io/ determined? Is it defined like that by default?

That's a route - the name is "appname + namespace + cluster address".

how were those hook locations created in the first place? Or, why do forwarding to these locations can trigger events?

Those requests get routed to jenkins which has a plugin to handle them.

It kinda felt a bit odd/suprising to me that all the steps can be done in a single host.

Yeah, but a single physical machine can spawn multiple containers or VMs. Being able to test it all locally is very useful of course. This whole thing is the reason of course why we have both oc cluster up as well as production OpenShift installs. And a similar thing exists for OpenStack in "packstack" vs their installer, etc.

[jlebon]

As for the last question:

Does that sound right for the steps?

Almost! When GHPRB receives the webhook event, it triggers the associated papr-trigger-$repo job. That job then runs papr_trigger.py to actually create the parent PAPR pod.