Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-60365

Environment variables not being set on post-submit

    Details

    • Similar Issues:

      Description

      I just started a new Jenkins, created a repo in GerritHub and set it up. When Jenkins builds the open changes, all the environment variables are being created and exposed accordingly. However, in a build of the branch such as master, none of these variables are set (only PROJECT, API_URL and CREDENTIALS_ID). 

      I suppose this is what causes the gerritReview step to fail when trying to post comments on a merged change. (When using plain Pipeline with Gerrit Trigger, the gerritReview step works fine on post-submit changes).

        Attachments

          Activity

          Hide
          lucamilanesio Luca Domenico Milanesio added a comment -

          True, change-related variables on a regular branch are not set.

          That is due to the fact that Gerrit doesn't know what is the associated change because the branch is not pointing to a change ref.

          Jenkins is typically used with Gerrit for allowing pre-commit validation. What is your use-case on a regular branch?

          Show
          lucamilanesio Luca Domenico Milanesio added a comment - True, change-related variables on a regular branch are not set. That is due to the fact that Gerrit doesn't know what is the associated change because the branch is not pointing to a change ref. Jenkins is typically used with Gerrit for allowing pre-commit validation. What is your use-case on a regular branch?
          Hide
          felipecassiors Felipe Santos added a comment - - edited

          That's right.

          My use case: 

          • We produce a docker image for our repo on every commit and push it. For pre-submit commits, we tag it with the commit hash and the Gerrit change number. For post-submit we also does, alongside we also tag as :latest. In the end of the pipeline, we post comments on the change (gerritReview step) with a snippet for the docker pull command of that image matching the revision of the patchset. 

          This comment is useful to be posted also for post-submit commits, due to the fact that the commit author can have the image name of that desired commit without having to search (not every time the last patch-set (after hitting Submit) is the same of the latest one after pushing, because it gets rebased).

          However, there is another possibility the lack of these variables is depriving me:
          I want to tag my docker images with the Gerrit change number even after it gets merged, and for this I need the variable GERRIT_CHANGE_NUMBER and/or GERRIT_PATCHSET_NUMBER to be set.

          So far I have not found any no workaround.

          Show
          felipecassiors Felipe Santos added a comment - - edited That's right. My use case:  We produce a docker image for our repo on every commit and push it. For pre-submit commits, we tag it with the commit hash and the Gerrit change number. For post-submit we also does, alongside we also tag as :latest. In the end of the pipeline, we post comments on the change (gerritReview step) with a snippet for the docker pull command of that image matching the revision of the patchset.  This comment is useful to be posted also for post-submit commits, due to the fact that the commit author can have the image name of that desired commit without having to search (not every time the last patch-set (after hitting Submit) is the same of the latest one after pushing, because it gets rebased). However, there is another possibility the lack of these variables is depriving me: I want to tag my docker images with the Gerrit change number even after it gets merged, and for this I need the variable GERRIT_CHANGE_NUMBER and/or GERRIT_PATCHSET_NUMBER to be set. So far I have not found any no workaround.
          Hide
          lucamilanesio Luca Domenico Milanesio added a comment -

          If we want to get those variables, we need to try to understand what is the change associated with a SHA1: it is feasible I believe, because Gerrit would be able to find the change number based on the SHA1 of the commit.

          Changed the issue to improvement and will put it in my backlog.

          Thanks for sharing your use-case.

          Show
          lucamilanesio Luca Domenico Milanesio added a comment - If we want to get those variables, we need to try to understand what is the change associated with a SHA1: it is feasible I believe, because Gerrit would be able to find the change number based on the SHA1 of the commit. Changed the issue to improvement and will put it in my backlog. Thanks for sharing your use-case.
          Hide
          felipecassiors Felipe Santos added a comment -

          The approach you suggested makes a lot of sense. I might try to contribute to the code, I will have a look when I get some time. Thanks!

          Show
          felipecassiors Felipe Santos added a comment - The approach you suggested makes a lot of sense. I might try to contribute to the code, I will have a look when I get some time. Thanks!

            People

            • Assignee:
              lucamilanesio Luca Domenico Milanesio
              Reporter:
              felipecassiors Felipe Santos
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: