Example test runs: https://upshift.engineering.redhat.com/console/project/waiverdb-test/browse/pipelines

Wow, nice! This will be very useful.

Cool! +1
Will it be possible in the future to run it automatically?

@gnaponie Yes. I think Pagure should have hooks to help integrate with Jenkins and trigger builds whenever there is a new PR or commit.

This seems to be an image for a Jenkins slave. Would be nice to indicate this with some metadata.

This already seems to be available in docker 1.13 and above as the --init option for docker run. Isn't OpenShift already starting containers like this?

@csomh Thanks for the review.
For your first comment, what metadata do you recommend to have?
About your second comment, Yes, there are. But I couldn't find any options in a OpenShift/Kubernetes PodTemplate that passing the --init flag to Docker. I guess this might be related to an OCI change, and the Kubernetes community doesn't follow what Docker actually does.

Something like app: waiverdb-jenkins-slave could work; or any other key-value pair that indicates what the image is going to be used for.

I've just noticed that you are pulling from the internal OpenShift registry in the podTemplate. Probably it would be nice to use some other registry there (BuildConfigs can push to external registries, too) as currently there is no guarantee for data retention in UpShift - that is: the image for the slave can disappear without a notice.

Regarding the --init: I am fine with keeping tini :)

@csomh OK.
About the external registry, I remember that @mikeb said he recommends to use quay.io. Is this the way to go? Do you have more information about using quay.io?

Updated the container build and test parts.
Demo: https://upshift.engineering.redhat.com/console/project/waiverdb-test/browse/pipelines

I realized that this would be huge for review if I keep everything in a template XD.

Added container push build step.
After acquired a larger quota on new UpShift (paas.upshift.redhat.com), I've moved the pipeline to the new space: https://paas.upshift.redhat.com/console/project/waiverdb-test/browse/pipelines

Updated container/doc publish and usage.

Image push phase fails with the infamous "unknown blob" ("Error writing manifest: Error uploading manifest test to docker-registry.engineering.redhat.com/factory2/waiverdb: manifest blob unknown: blob unknown to registry"). We solve it by using retry block in Jenkinsfile.

This issue sometimes happens. I suspect it blames to the internal registry?

Lukas Holecek pagure@pagure.io=E4=BA=8E2018=E5=B9=B48=E6=9C=882=E6=97=A5 =
=E5=91=A8=E5=9B=9B=E4=B8=8B=E5=8D=887:26=E5=86=99=E9=81=93=EF=BC=9A

lholecek commented on the pull-request: WIP: Add dev pipeline to run CI/CD on OpenShift that you are following:
Image push phase fails with the infamous "unknown blob" ("Error writing manifest: Error uploading manifest test to docker-registry.engineering.redhat.com/factory2/waiverdb: manifest blob unknown: blob unknown to registry"). We solve it by using [retry block in Jenkinsfile](https://pagure.io/waiverdb/c/3ef1f4b2).

To reply, visit the link below or just reply to this email
https://pagure.io/waiverdb/pull-request/218

This issue sometimes happens. I suspect it blames to the internal registry?

Yes, you're right. It doesn't happen with Quay.

There is an issue for this in our internal JIRA (OSBS-4907).

Can you copy the commit message body to openshift/README.md? Would be a pity to have it just in the commit message. (Then maybe it doesn't have to be in the YAML file.)

Yes, please ... if it's possible. The YAML files are already hard to read.

@lholecek I'll move it to a separated Dockerfile during the tidying up. It's so bad that I can't split the Template itself into small files.

I think this is not valid anymore and it's possible to use declarative pipelines on that instance.

@csomh The Jenkins Kubernetes Plugin claims it requires Jenkins 2.66+ for Declarative Pipeline support.

Update: Tidying up
- Inline Dockerfiles were moved to separated files.
- Removed unused parameters and code blocks.

@lholecek @csomh Can you have a look at the latest update?
And please help add anything like:
1. ideas on how to avoid such a big patch like this for the pipeline work so that it can be easily reviewed.
2. anything I am missing before getting this PR merged.

How about dnf install origin-clients?

Why is this required?

Wouldn't tox already handly this when running the unit tests?

Let's use the fedora-28 image as a base!

It seems that this could be removed.

How does this credential end up being saved in Jenkins (when Jenkins is deployed on OpenShift)? Does it have to be manually added?

I kinda finished reviewing it, although the PR is somewhat overwhelming :)

Many thanks for this @rayson! :thumbsup:

@csomh Yes, I know. However I just changed it to Declarative style XD. Hopefully it is much easier for review.
Thanks for you patience.

@csomh
- installing oc with dnf: that is because oc provided by Fedora 27 repo is not new enough. I'll check if rad-slave based on Fedora 28 is working.
- base image of Jenkins slave: I'll have a look if Fedora 28 based rad-slave image is there.

I'll follow other comments later.
Btw, the steps are not changed when I moving to declarative pipeline.

The instructions to creating credentials are described in openshift/README.md. Credentials are actually stored as OpenShift Secrets with a special label. They will be automatically synced into Jenkins by OpenShift Sync Jenkins plugin (which is by default included in the integrated Jenkins).

For the question of adding the spec file, it's used to install RPM build dependencies. It could install some non-python packages and by so far I am not sure if they all can be handled by tox as you mentioned.

As discussed with @csomh and @mikeb yesterday, we may want to break the pipeline into smaller jobs for better management and review. Since we already spent time on review, I won't break the PR until it gets merged.

Commit c168b967 fixes this pull-request