Category: Jenkins

bookmark_borderSource Code Management(SCM) with Pipeline in Jenkins

Posted on by Jay Jo

https://www.jenkins.io/doc/pipeline/steps/workflow-scm-step/

  • Git Parameter Plug-In
def gitUrl = "https://github.com/jayjodev/k8s-gitops"

pipeline {
    environment {
        PATH = "$PATH:/usr/local/bin/"  //maven, skaffold, argocd,jq path
    }
    agent any

    stages {
        stage('Build') {
            steps {
                checkout scm: [
                    $class: 'GitSCM',
                    userRemoteConfigs: [[url: "${gitUrl}", credentialsId: 'github' ]],
                     branches: [[name: "refs/tags/${TAG}"]]],
                     poll: false
            }
        }
    }
}

$class: 'GitSCM'

  • userRemoteConfigs Specify the repository to track. This can be a URL or a local file path. Note that for super-projects (repositories with submodules), only a local file path or a complete URL is valid. The following are examples of valid git URLs.
    • ssh://git@github.com/github/git.git
    • git@github.com:github/git.git (short notation for ssh protocol)
    • ssh://user@other.host.com/~/repos/R.git (to access the repos/R.git repository in the user’s home directory)
    • https://github.com/github/git.git
    • git://github.com/github/git.git
      If the repository is a super-project, the location from which to clone submodules is dependent on whether the repository is bare or non-bare (i.e. has a working directory).
    • If the super-project is bare, the location of the submodules will be taken from .gitmodules.
    • If the super-project is not bare, it is assumed that the repository has each of its submodules cloned and checked out appropriately. Thus, the submodules will be taken directly from a path like ${SUPER_PROJECT_URL}/${SUBMODULE}, rather than relying on information from .gitmodules.For a local URL/path to a super-project, git rev-parse –is-bare-repository is used to detect whether the super-project is bare or not.
      For a remote URL to a super-project, the ending of the URL determines whether a bare or non-bare repository is assumed:
    • If the remote URL ends with /.git, a non-bare repository is assumed.
    • If the remote URL does NOT end with /.git, a bare repository is assumed.
    • +url
    • +name
    • +refspec
    • +credentialsId
  • branches
    • -nameSpecify the branches if you’d like to track a specific branch in a repository. If left blank, all branches will be examined for changes and built.The safest way is to use the refs/heads/<branchName> syntax. This way the expected branch is unambiguous.If your branch name has a / in it make sure to use the full reference above. When not presented with a full path the plugin will only use the part of the string right of the last slash. Meaning foo/bar will actually match bar.If you use a wildcard branch specifier, with a slash (e.g. release/), you’ll need to specify the origin repository in the branch names to make sure changes are picked up. So e.g. origin/release/Possible options:
      • <branchName>
        Tracks/checks out the specified branch. If ambiguous the first result is taken, which is not necessarily the expected one. Better use refs/heads/<branchName>.
        E.g. master, feature1, …
      • refs/heads/<branchName>
        Tracks/checks out the specified branch.
        E.g. refs/heads/master, refs/heads/feature1/master, …
      • <remoteRepoName>/<branchName>
        Tracks/checks out the specified branch. If ambiguous the first result is taken, which is not necessarily the expected one.
        Better use refs/heads/<branchName>.
        E.g. origin/master
      • remotes/<remoteRepoName>/<branchName>
        Tracks/checks out the specified branch.
        E.g. remotes/origin/master
      • refs/remotes/<remoteRepoName>/<branchName>
        Tracks/checks out the specified branch.
        E.g. refs/remotes/origin/master
      • <tagName>
        This does not work since the tag will not be recognized as tag.
        Use refs/tags/<tagName> instead.
        E.g. git-2.3.0
      • refs/tags/<tagName>
        Tracks/checks out the specified tag.
        E.g. refs/tags/git-2.3.0
      • <commitId>
        Checks out the specified commit.
        E.g. 5062ac843f2b947733e6a3b105977056821bd352, 5062ac84, …
      • ${ENV_VARIABLE}
        It is also possible to use environment variables. In this case the variables are evaluated and the result is used as described above.
        E.g. ${TREEISH}, refs/tags/${TAGNAME}, …
      • <Wildcards>
        The syntax is of the form: REPOSITORYNAME/BRANCH. In addition, BRANCH is recognized as a shorthand of */BRANCH, ‘*’ is recognized as a wildcard, and ‘**’ is recognized as wildcard that includes the separator ‘/’. Therefore, origin/branches* would match origin/branches-foo but not origin/branches/foo, while origin/branches** would match both origin/branches-foo and origin/branches/foo.
      • :<regular expression>
        The syntax is of the form: :regexp. Regular expression syntax in branches to build will only build those branches whose names match the regular expression.
        Examples:
        • :^(?!(origin/prefix)).*
          • matches: origin or origin/master or origin/feature
          • does not match: origin/prefix or origin/prefix_123 or origin/prefix-abc
        • :origin/release-\d{8}
          • matches: origin/release-20150101
          • does not match: origin/release-2015010 or origin/release-201501011 or origin/release-20150101-something
        • :^(?!origin/master$|origin/develop$).*
          • matches: origin/branch1 or origin/branch-2 or origin/master123 or origin/develop-123
          • does not match: origin/master or origin/develop
      • Type: String
  • changelog (optional)
    • Type: boolean
  • poll (optional)
    • Type: boolean
ANOTE.DEV