Re: Expiring project Giza dot org domain
|
Alvin Tan <khiamt@...>
Jack, 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.
----- 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...
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
|
|||||
|
|
|||||
"Jack-Tiefeng Jia" ---2019/11/22 02:36:40 PM---John, for sure. Currently when we test the Jenkins Library, which is a gradle build, the test starts