Source Code Management(SCM) with Pipeline in Jenkins

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