John, for sure. Currently when we test the Jenkins Library, which is a gradle build, the test starts with gradle test command, it will try to test several functionalities in the library. It's generally integration tests since when the code runs under Jenkins, it may behave differently when we run under JRE. Jenkins pipeline workflow plugin will convert the code into CPS https://github.com/cloudbees/groovy-cps/blob/master/doc/cps-basics.md.

 

For each major functionality, we will create a test Jenkins job on-the-fly with Jenkinsfile, and/or start the build with different parameters. The job could be a simple Pipeline, or a Multibranch Pipeline depends on the feature the test case is testing. For multibranch pipeline, we will also trigger a scan job to find the branches.

 

With current LF Jenkins setup, we don't have these permissions:

- create a job on-the-fly (or through Jenkins API)

- start a scan on Multibranch Pipeline job (or through Jenkins API)

- start a job on Jenkins (or through Jenkins API)

- start a job with parameters on Jenkins (or through Jenkins API)

- delete the temporary test job when the test is done

 

So we have to figure other ways to perform the tests.

 

For the permission of starting a job with parameters on Jenkins, we do rely a lot on this with our own Jenkins. Few scenarios like:

- start a smoke test on any build we produced,

- or start a smoke test on a different testing server.

- parameters to decide if/how we want to release.

 

For all the permission limitations, I believe we can have workarounds, just not ideal. Like we have to create dummy branches/commits to the github to trigger a build. The dummy commits eventually will end up to many merging conflicts, which is minor but have to deal with. To create workaround on testing Jenkins Library, we will need to change a lot on the way how we start our test.

 

FYI, another workaround we have already added is building in docker containers. The Jenkins has docker support VM agent, but the agent is not reusable. We can start the container with the build, but every build it will need to download the base build image again.  For example, https://jenkins.zowe.org/job/zowe-docs-site/job/users%252Fjack%252Flf-jenkins/6/execution/node/8/log/. Currently the base image is 1.24G, which create extra overhead to the build and server traffic. We may be able to try to make the base image slightly smaller, but I think with JDK8 and node.js v8 or v12 pre-installed, it will be still about 600M to 900M.

 

Hope this explains the issues we are having.

Thanks,   Jack (T.) Jia Software Developer IBM Z Management Software IBM Systems

Phone: 1-905-413-3195 E-mail: jack-tiefeng.jia@...	8200 Warden Ave Markham, ON L6G 1C7 Canada

 

 

----- Original message -----
From: "John Mertic" <jmertic@...>
Sent by: zowe-dev@...
To: zowe-dev@..., Andrew Grimberg <agrimberg@...>, Daniel Pono Takamori <dtakamori@...>
Cc:
Subject: [EXTERNAL] Re: [zowe-dev] Expiring project Giza dot org domain
Date: Fri, Nov 22, 2019 11:34 AM
 

Hey Jack!

 

Adding +Andrew Grimberg and +Daniel Pono Takamori to this thread...

 

I will keep investigating the possibilities of migrating everything to LF Jenkins. One difficulty we have is the "Jenkins Library" build which will fail on LF Jenkins due to the permission limitation we have. Will see what we can do. The tests for Jenkins Library code is suggested because if it fails, it may indicate every other builds using that branch will fail. The test has to be performed against a real Jenkins server, not a virtual JVM environment because Jenkins handles Groovy scripts differently. The way of testing Jenkins Library is it will try to create a job through Jenkins API and start the build and check result, which is against the permission scheme we have on LF Jenkins.

 

Can you elaborate on the permissions issues? I thought we had built the environment to align with the existing practices, but wondering if something changed from discovery to implementation.

 

Thanks!

 

John