[JIRA] (JENKINS-59210) Extract commit SHA of Jenkinsfile

11 views
Skip to first unread message

varsho@yahoo.com (JIRA)

unread,
Sep 3, 2019, 3:11:21 PM9/3/19
to jenkinsc...@googlegroups.com
Oleg Varshavsky created an issue
 
Jenkins / Bug JENKINS-59210
Extract commit SHA of Jenkinsfile
Issue Type: Bug Bug
Assignee: Mark Waite
Components: git-plugin
Created: 2019-09-03 19:10
Environment: Jenkins ver. 2.121.3

- [git, '3.8.0']
- [git-client, '2.7.1']
- [git-server, '1.7']
- [github, '1.29.0']
- [github-api, '1.90']
- [github-branch-source, '2.3.3']
- [github-organization-folder, '1.6']
Priority: Major Major
Reporter: Oleg Varshavsky

We need to make sure that commit SHA that triggered the build via webhook is the same SHA that the repo is being checkout out.

 

Use case:

Dev-1 merges changes to repo 'a'. Within seconds, Dev-2 merges changes to repo 'a'.

 

Expectation:

Each commit triggers a separate build based on the webhook SHA that triggered the build.

 

Current result:

SHA of Jenkinsfile might be not the same as checkout code, since the merges might happen within seconds of each other.

 

 

Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

mark.earl.waite@gmail.com (JIRA)

unread,
Sep 3, 2019, 6:05:02 PM9/3/19
to jenkinsc...@googlegroups.com
Mark Waite updated an issue
Change By: Mark Waite
We need to make sure that commit SHA that triggered the build via webhook is the same SHA that the repo is being checkout out.

 

h4. Use case:


Dev-1 merges changes to repo 'a'. Within seconds, Dev-2 merges changes to repo 'a'.

 

h4. Expectation:


Each commit triggers a separate build based on the webhook SHA that triggered the build.

 

h4. Current result:


SHA of Jenkinsfile might be not the same as checkout code, since the merges might happen within seconds of each other.

mark.earl.waite@gmail.com (JIRA)

unread,
Sep 3, 2019, 6:05:03 PM9/3/19
to jenkinsc...@googlegroups.com
Mark Waite commented on Bug JENKINS-59210
 
Re: Extract commit SHA of Jenkinsfile

Please provide detailed steps that will allow someone else to duplicate the problem. Based on your description, I can't tell the answers to the following questions (and likely others related to them):

  • Which syntax are you using, declarative or scripted?
  • How is the checkout performed in your Pipeline, as the implicit checkout of a declarative Pipeline or as an explicit checkout from a scripted Pipeline?
  • If using an explicit checkout, what arguments are you providing to the explicit checkout?
  • Are multiple repositories used in your Pipeline?
  • What system is generating the webhook (GitHub, Bitbucket, Gitlab, Gitea, ...)?
  • How does the webhook provide the SHA in its payload (name of variable, etc.)?
  • Is your Pipeline definition stored in the git repository or in Jenkins?
  • Is your Pipeline running in a multibranch Pipeline or as a single Pipeline job?

Please provide more details describing your Pipeline definition and how you see the problem.

mark.earl.waite@gmail.com (JIRA)

unread,
Sep 3, 2019, 6:07:02 PM9/3/19
to jenkinsc...@googlegroups.com
Mark Waite assigned an issue to Unassigned
 
Change By: Mark Waite
Assignee: Mark Waite

mark.earl.waite@gmail.com (JIRA)

unread,
Sep 3, 2019, 6:09:05 PM9/3/19
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-59210
Please provide detailed steps that will allow someone else to duplicate the problem.  Based on your description, I can't tell the answers to the following questions (and likely others related to them):

* Which syntax are you using, declarative or scripted?
* How is the checkout performed in your Pipeline, as the implicit checkout of a declarative Pipeline or as an explicit {{checkout}} from a scripted Pipeline?
* If using an explicit checkout, what arguments are you providing to the explicit checkout?
* Are multiple repositories used in your Pipeline?
* What system is generating the webhook (GitHub, Bitbucket, Gitlab, Gitea, ...)?
* How does the webhook provide the SHA in its payload (name of variable, etc.)?
* Is your Pipeline definition stored in the git repository or in Jenkins?
* Is your Pipeline running in a multibranch Pipeline or as a single Pipeline job?
* Are you expecting that Dev-1 change will be built even if the Jenkins query for the tip of the branch finds the more recent Dev-2 change?

Please provide more details describing your Pipeline definition and how you see the problem.

mark.earl.waite@gmail.com (JIRA)

unread,
Sep 3, 2019, 6:22:02 PM9/3/19
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-59210
Please provide detailed steps that will allow someone else to duplicate the problem.  Based on your description, I can't tell the answers to the following questions (and likely others related to them):

* Which syntax are you using, declarative or scripted?
* How is the checkout performed in your Pipeline, as the implicit checkout of a declarative Pipeline or as an explicit {{checkout}} from a scripted Pipeline?
* If using an explicit checkout, what arguments are you providing to the explicit checkout?
* Are multiple repositories used in your Pipeline?
* What system is generating the webhook (GitHub, Bitbucket, Gitlab, Gitea, ...)?
* How does the webhook provide the SHA in its payload (name of variable, etc.)?
* Is the webhook providing an authentication token as part of its payload?
* Is
your Pipeline definition stored in the git repository or in Jenkins?

* Is your Pipeline running in a multibranch Pipeline or as a single Pipeline job?
* Are you expecting that Dev-1 change will be built even if the Jenkins query for the tip of the branch finds the more recent Dev-2 change?

Please provide more details describing your Pipeline definition and how you see the problem.

varsho@yahoo.com (JIRA)

unread,
Sep 3, 2019, 8:42:01 PM9/3/19
to jenkinsc...@googlegroups.com

Hi Mark,

Sorry, for incomplete picture. Here are the details you are asking.:

  • It is a scripted pipeline
  • Explicit checkout from a scripted Pipeline
  • Pipeline snippet:
    • checkout([$class: 'GitSCM',
      branches: [[name: "*/${GIT_BRANCH}"]],
      browser: [$class: 'GithubWeb', repoUrl: "https://${GIT_HOST}/${GIT_OWNER}/${GIT_REPOSITORY}"],
      doGenerateSubmoduleConfigurations: false,
      extensions: [
      [$class: 'RelativeTargetDirectory', relativeTargetDir: "${GIT_REPOSITORY}"],
      [$class: 'LocalBranch', localBranch: "${GIT_BRANCH}"],
      [$class: 'GitLFSPull']
      ],
      submoduleCfg: [],
      userRemoteConfigs: [
      [
      credentialsId: '***********************',
      url: "git@${GIT_HOST}:${GIT_OWNER}/${GIT_REPOSITORY}.git"
      ]
      ]
      ])
  • Enterprise GitHub webhook provider
  • No  authentication token as part of its payload
  • Pipeline definition stored in the git repository
  • Single Pipeline job
  • I am expecting that Dev-1 change will be built separately, even if the Jenkins query for the tip of the branch finds the more recent Dev-2 change.

 

The actual use case is that our developers provide bug id(s) in commit messages. Once the build is done, we update corresponding bug(s) with the corresponding build information, including:

  • source files changes
  • generated output
  • link to Jenkins build
  • Git SHA of the corresponding commit
  • etc.

We have a requirement to be able to trigger builds on each commit to insure that only relevant information is inserted into each bug.

What happens now when commits from 2 developers happen too close to each other, is that once Jenkins queries the specified tip of the branch, it picks up additional changes from Dev-2, which may not be related to changes from Dev-1.

Ideally, I should be able to find out the SHA of the Jenkinsfile, that triggered the build and use that to do the checkout of the source code.

Please let me know if I can provide any additional info. 

 

mark.earl.waite@gmail.com (JIRA)

unread,
Sep 3, 2019, 10:04:02 PM9/3/19
to jenkinsc...@googlegroups.com

The git plugin is designed to take the most recent commit from the tip of the branch it is monitoring. You want to build a specific commit which may not be the latest commit. There isn't a way to do that directly.

You could consider creating a parameterized job which takes a SHA1 as an argument. You could give it a default value of HEAD and then invoke it with the SHA1 value that you want to build. You'll need to find some way to get the SHA1 from the repository and assign it as a parameter value when that job is run.

Reply all
Reply to author
Forward
0 new messages