@pabrahamsson ; am sure this is already on your radar but this is to just track the work.

Also, i know its been talked about on the weekly calls, but has it been decided on how someone can view/edit the prow config?

pending rht-labs/labs-ci-cd#73

When I try to call the binaryBuild function I am getting this error.

[logs:build/human-review-backend-245] Receiving source from STDIN as file human-review-backend-1.0-SNAPSHOT.jar
==================================================================
Starting S2I Java Build .....
S2I source build with plain binaries detected
Copying binaries from /tmp/src to /deployments ...
... done

Pushing image docker.artifactory.apps.mgt.devsecops.gov/yellowdog/human-review-backend:latest ...
Pushed 5/6 layers, 84% complete
Pushed 6/6 layers, 100% complete
Push successful

Error running logs on at least one item: [Uploading file "target/human-review-backend-1.0-SNAPSHOT.jar" as binary input for the build ..., build/human-review-backend-245];
{reference={}, err=, verb=logs, cmd=oc --server=https://172.30.0.1:443 --certificate-authority=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt --namespace=yellowdog --token=XXXXX logs Uploading file "target/human-review-backend-1.0-SNAPSHOT.jar" as binary input for the build ... -f , out=error: expected 'logs (POD | TYPE/NAME) [CONTAINER_NAME]'.
POD or TYPE/NAME is a required argument for the logs command
See 'oc logs -h' for help and examples., status=1}

@sabre1041 https://github.com/redhat-cop/image-scanning-signing-service

Seems like this issue still occurs. If I add some sort of wait/delay it seems to work but otherwise the loop does not get entered and the pipeline stalls in the state pictured below.

The verify deployment function is running immediately after I deploy the application.

As we are starting to get some real contributions to his repo, I'm noticing that the PR review process is fairly slow. Part of this, I think, is because we don't have a good test strategy in place. CI would be great, but I think there's probably a more MVP solution to making reviews run more smoothly.

What I'm picturing is a standard Applier inventory that spins up a jenkins server with this library baked in (we already have the s2i build), plus a test directory for each contribution, containing a jenkinsfile that can be run to exercise the new functionality.

We should document the things that we expect from a contribution, which should include tests

@pabrahamsson @syvanen @sabre1041 @springdo

I have a Maven Multi-Module project (https://github.com/rhoar-shootout/rhoar-vertx) and I am wondering how to wire up a multimodule Maven project into Jenkins for building several containers for OpenShift. In my example, there are 4 different images which should be built and deployed. Should it be done with a single Jenkinsfile at the top level? One for each service? I will be experimenting with different options and report back here if I do not get other feedback.

@redhat-cop/developer-workflow

@redhat-cop/developer-workflow

@redhat-cop/developer-workflow

For Maven builds, support sonar:sonar and dependency-check:check targets for SonarQube and OWASP Dependency Check

For NPM, add sonar-scanner and CLI version of OWASP Dependency Check to build slave and add commands to the Jenkinsfile

need to apply filter tags from pipeline via applier() call. would be a single parameter with comma delimited list of tags.

We have been having issues on one of our clusters where the certificate has expired (yes, we need to update the cert). However, from the app teams perspective, this makes their pipeline fail on verifyDeployment. The upgrade of the certificate is not very high on our priority because releasing a later version of OpenShift is greater than improving this cluster.

Update pom to release version:

• https://github.com/redhat-cop/pipeline-library/blob/master/pom.xml#L8

Create github release:

• https://github.com/redhat-cop/pipeline-library/releases

This block in applier.groovy:

        openshift.withCluster() {
            def secretData = openshift.selector("secret/${input.secretName}").object().data
            def encodedToken = secretData.token
            env.TOKEN = sh(script:"set +x; echo ${encodedToken} | base64 --decode", returnStdout: true)
        }

Assumes that Jenkins is running on openshift. I think that's not a great assumption.

Change to something like this:

node {
  withCredentials([string(credentialsId: 'mytoken', variable: 'TOKEN')]) {
    sh /* WRONG! */ """
      set +x
      curl -H 'Token: $TOKEN' https://some.api/
    """
    sh /* CORRECT */ '''
      set +x
      curl -H 'Token: $TOKEN' https://some.api/
    '''
  }
}

from: https://jenkins.io/doc/book/pipeline/jenkinsfile/#handling-credentials

It gets away from that assumption and can still get the secret needed. All you need to know is that you are running on Jenkins. The OCP sync plugin will handle the syncing of an openshift secret to Jenkins (wherever it may live) and then we don't have to worry about knowing that Jenkins is running on Openshift. Jenkins could literally be running wherever and execute this applier.groovy

this variable is called registryUrl which makes it sound like an image registery, but really it is the OCP master API url. Is there a reason for the term confusion?

I believe @syvanen had a way to do this?

@redhat-cop/developer-workflow

This commit upgrades version from v1.5 to v1.6
Currently there is no v1.6 (only 1.6)

redhat-cop/container-pipelines@5b98095

The example has projectname. The shared lib is actually projectName

https://github.com/redhat-cop/pipeline-library/blob/master/vars/binaryBuild.txt#L20

this repo uses prow to test the pipeline lib by deploying Jenkins and creating jobs. those bits are very OCP specific (BuildConfigs etc). need to define how we do builds for OCP bits or what the strategy is to build without any dependency on OCP

• redhat-cop/org#459

@redhat-cop/developer-workflow

As this starts to become more used, documentation for the user base will be nice. What functions are currently supported, the parameters that users are able to pass to the functions, etc. I am thinking an asciidoc or something like that so each company can expose the documentation internally.

https://github.com/redhat-cop/pipeline-library/blob/master/vars/verifyDeployment.groovy#L29:L60

It appears this takes a look at one "podSelector list" in time that may not have the pods we are looking to watch, and hence gets stuck in an infinite loop.