Request to host a new z/OS DevOps plugin in Jenkins Hub

[IBA-mainframe-dev]

Repository URL

https://github.com/IBA-mainframe-dev/zOS-DevOps-Jenkins-plugin

New Repository Name

zos-devops-plugin

Description

Jenkins zOS DevOps plugin - mainframes automation plugin, working through z/OSMF REST API and using ZOWE Kotlin SDK

The main goal of this plugin is to simplify communication between the Jenkins server and the mainframes, thereby allowing to create extensive automation and apply DevOps practices on them. Plugin uses the Kotlin programming language and also has the actual ZOWE Kotlin SDK connected inside. In order not to reinvent the wheel and not make some custom solutions, we use already implemented features from the ZOWE Kotlin SDK. At the moment, we are actively developing the plugin and we want to place the stable version of the plugin in the Jenkins hub, so that it is easy to find and just as easy to install.

Main plugin features:

• Secure and modern connection to the mainframes through the use of zOSMF REST API
• The functionality is based on the ZOWE Kotlin SDK methods, such as JCL jobs submission, download, allocate, write to the dataset, etc., with log collected upon finish
• Multiple connections to various mainframes - z/OS Connections List where you can save all the necessary systems and credentials in advance to access them, everything is hidden and safe, under the protection of Jenkins Credentials manager
• Agent-less solution
• Fast execution and functionality extensibility

Other similar plugin:

https://github.com/jenkinsci/aws-codebuild-plugin - a similar plugin, but works on a different principle (via FTP connection) and is aimed more at interacting with the mainframe version control system (SCLM) and only running JCL jobs.

GitHub users to have commit permission

@IBA-mainframe-dev @AnatolyKolbasin @Studenich

Jenkins project users to have release permission

iba_mainframe_dev

Issue tracker

GitHub issues

[jenkins-cert-app]

Security audit, information and commands

The security team is auditing all the hosting requests, to ensure a better security by default. This message informs you that the security team was notified about the request and will soon participate in this issue to assist. The team is usually starting by a quick superficial audit and if it's not sufficient, they are planning a deeper audit.

Commands

Security team only:

• /audit-ok => the audit is complete, the hosting can continue :tada:.
• /audit-skip => the audit is not necessary, the hosting can continue :tada:.
• /audit-required => the superficial audit was not sufficient, a deeper look is necessary :mag:.
• /audit-findings => the audit reveals some issues that require corrections :pencil2:.

Anyone:

• /audit-review => the findings from the audits were corrected, this command will ping the security team to review the findings :eyes:. It's only applicable when the previous audit required changes.

Only one command can be requested per comment.

(automatically generated message)

[github-actions[bot]]

Hello from your friendly Jenkins Hosting Checker

It appears you have some issues with your hosting request. Please see the list below and correct all issues marked Required. Your hosting request will not be approved until these issues are corrected. Issues marked with Warning or Info are just recommendations and will not stall the hosting process.

• :warning: Warning: No build system found (pom.xml, build.gradle)

You can re-trigger a check by editing your hosting request or by commenting /hosting re-check

[IBA-mainframe-dev]

Hi @NotMyFault, it seems that the Jenkins Hosting Checker did not recognize the build.gradle.kts file in the source repo, the build is carried out through it and by using the Gradle build system. Could you please advise on the next steps? First time trying to host a plugin - a little worried :D Thanks in advance!

[NotMyFault]

I just submitted https://github.com/jenkins-infra/repository-permissions-updater/issues/2905, nothing you need to worry about. We'll just need to check the automatic stuff by hand.

[NotMyFault]

Hey @IBA-mainframe-dev,

I took care of the hosting checker bot, given the comments above:

• [x] Please add a licenses block to your jenkinsPlugin block, see https://github.com/jenkinsci/gradle-jpi-plugin#configuration for an example

• [x] The gitHubUrl should point to the final destination, jenkinsci/zos-devops-plugin in this case.

• [x] The groupId in gradle.properties is deprecated, please use io.jenkins.plugins.

  • [x] The point above applies to packages and imports too, those should use the proper GAV coordinates as well https://github.com/IBA-mainframe-dev/zOS-DevOps-Jenkins-plugin/tree/main/src/main/kotlin/eu/ibagroup/zdevops

• [x] https://github.com/IBA-mainframe-dev/zOS-DevOps-Jenkins-plugin/tree/main/lib can this be removed? It's available on the central repository and implemented in the build script.

• [x] What's the reasoning behind using kapt over ksp? kapt is in maintenance only mode for some time in favor of ksp, which would be more future-proof to switch to.

A more in-depth read and security audit is still up to do.

[yaroslavafenkin]

Jenkins CERT will have a deeper look, tracked internally as JENSEC-1907.

[yaroslavafenkin]

/audit-required

[yaroslavafenkin]

Hi @IBA-mainframe-dev, we've had a deeper look at the plugin and have some feedback.

• SubmitJobStep#doFillConnectionNameItems needs a permission check.
• ZOSConnection#doFillCredentialsIdItems has a permission check but it seems incorrect. Given ZOSConnection is a part of global configuration Overall/Administer permission is more appropriate there.

Dependency scan with Snyk has also identified few issues in dependencies:

• CVE-2022-25647, affected path: "zOS-DevOps-Jenkins-plugin@1.0.0" > "com.squareup.retrofit2:converter-gson@2.9.0" > "com.google.code.gson:gson@2.8.5"
• https://github.com/square/okhttp/issues/6738, affected paths:
  • "zOS-DevOps-Jenkins-plugin@1.0.0" > "com.squareup.retrofit2:retrofit@2.9.0" > "com.squareup.okhttp3:okhttp@3.14.9"
  • "zOS-DevOps-Jenkins-plugin@1.0.0" > "com.squareup.retrofit2:converter-gson@2.9.0" > "com.squareup.retrofit2:retrofit@2.9.0" > "com.squareup.okhttp3:okhttp@3.14.9"
  • "zOS-DevOps-Jenkins-plugin@1.0.0" > "com.squareup.retrofit2:converter-scalars@2.9.0" > "com.squareup.retrofit2:retrofit@2.9.0" > "com.squareup.okhttp3:okhttp@3.14.9"

Please correct the first two issues and let us know so we can have another look. Regarding the dependency please check if you're affected or not.

[yaroslavafenkin]

/audit-findings

[IBA-mainframe-dev]

Hi @yaroslavafenkin, regarding permission check - we changed necessary permission from CONFIGURE to ADMINISTER in ZOSConnection.kt and added such check in SubmitJobStep.kt. About issue with CVE-2022-25647 we use latest version of "com.squareup.retrofit2:converter-gson:2.9.0", but inside of this lib, it references to "com.google.code.gson:gson@2.8.5" and we cannot do anything with it. But it doesn't affect plugin`s work. If you know how to fix such issue - it would be grate if you let us know, If not - what should we do next to pass this security check?

One more question regarding usage of ACL.SYSTEM2, @NotMyFault . Are there any good examples or any documentation on how to use it? Because we dig inside of Credentials architecture and discovered that in all places ACL.SYSTEM used under the hood. We also tried to find any plugin example with usages of ACL.SYSTEM2, but all the plugins we found (JIRA - https://github.com/jenkinsci/jira-plugin/blob/master/src/main/java/hudson/plugins/jira/CredentialsHelper.java, SSH - https://github.com/jenkinsci/ssh-plugin/blob/master/src/main/java/org/jvnet/hudson/plugins/CredentialsSSHSite.java#L69 and etc.) uses ACL.SYSTEM inside. And also it would be nice if you provide us any example of ksp usages (instead of kapt). Thanks in advance!

[yaroslavafenkin]

SubmitJobStep.kt#L55 should rather check for Job/Configure since it's a build step. Regarding dependencies, from your words I understand that you're not affected, so that issue can be ignored.

[IBA-mainframe-dev]

Hello @yaroslavafenkin, we fix this one, now SubmitJobStep.kt checks for Job.CONFIGURE permission. Please, take a look.

[yaroslavafenkin]

/audit-ok

[NotMyFault]

One more question regarding usage of ACL.SYSTEM2, @NotMyFault

@IBA-mainframe-dev Can be ignored, you're good to leave ACL.SYSTEM as-is.

[IBA-mainframe-dev]

Hello @NotMyFault, we've fixed all points from your requirements, but about the last point from your list (usage ksp instead of a kapt) - as we understand, sezpoz library is necessary to process @hudson.Extension annotation. But we don't see this library in list of ksp supported libraries. So can we leave it as is for now and continue with the hosting process? We understand that this is a nice to have thing and we will try to change it in the next updates. And if everything is in order, then we need to wait until the hosting issue will be resolved and create a Pull Request to the repository-permissions-updater repo with new .yaml from permissions dir , am I correct? Please, take a look and thanks in advance!

[NotMyFault]

And if everything is in order, then we need to wait until the hosting issue will be resolved and create a Pull Request to the repository-permissions-updater repo with new .yaml from permissions dir , am I correct? Please, take a look and thanks in advance!

No, this is done automatically. Thanks for addressing the open concerns, looks all good so far. You may want to add a Jenkinsfile to the root directory of the project, specifying buildPluginWithGradle() to build the plugin on the Jenkins infrastructure.

[NotMyFault]

/hosting host

[jenkins-infra-bot]

Hosting request complete, the code has been forked into the jenkinsci project on GitHub as https://github.com/jenkinsci/zos-devops-plugin

GitHub issues has been selected for issue tracking and was enabled for the forked repo.

Please remove your original repository (if there are no other forks) so that the jenkinsci organization repository is the definitive source for the code. If there are other forks, please contact GitHub support to make the jenkinsci repo the root of the fork network (mention that Jenkins approval was given in support request 569994). Also, please make sure you properly follow the documentation on documenting your plugin so that your plugin is correctly documented.

You will also need to do the following in order to push changes and release your plugin:

• Accept the invitation to the Jenkins CI Org on Github
• Create PR for upload permissions
• Releasing your plugin

In order for your plugin to be built by the Jenkins CI Infrastructure and check pull requests, please add a Jenkinsfile to the root of your repository with the following content: buildPlugin()

Welcome aboard!