How to checkout GitHub repo from Jenkins file in Subversion workspace?

Using Jenkins
1

Hi, we normally store our Jenkinsfiles with SVN. We have a need to monitor and respond to changes in a GitHub repo. My thoughts are to use a declarative pipeline, hosted in SVN, to checkout (clone?) the GitHub repo, monitor it for changes (manually - not using Jenkins polling) and to commit some changes according to the incoming changes.

So I need to be able to clone a GitHub repo from with a declarative pipeline. This StackOverflow answer suggests using this pipeline code:

node {   
def gradleHome

stage('Prepare/Checkout') { // for display purposes
    git branch: 'develop', url: 'https://github.com/WtfJoke/Any.git'

    dir('a-child-repo') {
       git branch: 'develop', url: 'https://github.com/WtfJoke/AnyChild.git'
    }

    env.JAVA_HOME="${tool 'JDK8'}"
    env.PATH="${env.JAVA_HOME}/bin:${env.PATH}" // set java home in jdk environment
    gradleHome = tool '3.4.1' 
}

stage('Build') {
  // Run the gradle build
  if (isUnix()) {
     sh "'${gradleHome}/bin/gradle' clean build"
  } else {
     bat(/"${gradleHome}\bin\gradle" clean build/)
  }
}
}

Could I do something similar in declarative syntax?
Or do you have any other suggestions please?

2

FWIW, I would highly recommend keeping Jenkinsfile with your code, else you are stuck perpetually balancing versions and branches with hard to predict results. If you have shared code between multiple repos, use a library repo, so that you get predictable versions.

As to your question - not sure of declarative syntax, it is probably possible to do it directly, but you also can always just run scripted steps inside declarative using script {} segment. Syntax generators are a great reference.

3

@mlasevich Thanks for your reply. The issue for me is that if I put my Jenkinsfile in the GitHub repo, which is on a 3rd party server, I may have a security risk. The Jenkinsfile could get hacked and provide a door into our system. Unless there is a way of mitigating against this?

4

If you do not trust the code, then you have a larger problem - even when your pipeline is trusted, chances are it executes a build system and/or installs 3rd party dependencies, etc - all of that can be used to execute code on your build agent. The pipeline will run in a sandbox, but it is still not something you can/should trust.