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

Changeset for first run of generated job is empty

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Minor Minor
    • None
    • jenkins 2.46.2, github-branch-source-plugin 2.0.4

      When a job is generated (whether it be a branch or pull request build), the only "Change" (in the UI) is a Branch event. When manually querying the changesets, the first run is always an empty list. This doesn't include information about who contributed to a build. Any plugin that uses changesets in a meaningful way does not work for the first run.

      My initial use case is sending emails to culprits for a failed build. This list is correctly populated on the next build, but should be available on the initial build. This would also block changeset introspection (e.g. searching for particular changelists).

          [JENKINS-44849] Changeset for first run of generated job is empty

          Wayne Warren added a comment - - edited

          This is a pretty serious problem that significantly impairs the functionality of the `changeset` directive in declarative pipeline. I would go as far as to say that the `changeset` directive is worthless because of its counter intuitive and inconsistent behavior. It's led myself and a teammate to make several meaningless changes to our `changeset` usages to see if that would make the job run the conditional stages; of course whenever we made such changes within a PR the next build would actually run so we mistakenly thought we had fixed something, even though in reality all we had done was satisfy the condition under which Jenkins would actually acknowledge that changes are present in the PR as described in this ticket.

           

          Since I absolutely know some other poor fool is going to encounter this problem, this is the workaround I've come up with:

          +          expression {
          +            sh(returnStatus: true, script: 'git diff  origin/master --name-only | grep "^auth.*" > /dev/null') == 0
          +          }

           

          Wayne Warren added a comment - - edited This is a pretty serious problem that significantly impairs the functionality of the `changeset` directive in declarative pipeline. I would go as far as to say that the `changeset` directive is worthless because of its counter intuitive and inconsistent behavior. It's led myself and a teammate to make several meaningless changes to our `changeset` usages to see if that would make the job run the conditional stages; of course whenever we made such changes within a PR the next build would actually run so we mistakenly thought we had fixed something, even though in reality all we had done was satisfy the condition under which Jenkins would actually acknowledge that changes are present in the PR as described in this ticket.   Since I absolutely know some other poor fool is going to encounter this problem, this is the workaround I've come up with: +          expression { +            sh(returnStatus: true , script: 'git diff  origin/master --name-only | grep "^auth.*" > /dev/ null ' ) == 0 +          }  

          uuaynr absolutely agreed - changeset is useless in any type of advanced use case. Thank you for the workaround!

          Stepan Mazurov added a comment - uuaynr absolutely agreed - changeset is useless in any type of advanced use case. Thank you for the workaround!

          benoit guerin added a comment -

          Same on bitbucket-branch-source-plugin here : JENKINS-48687

          It goes down to the git plugin itself, not computing the changelog for the first build of a new branch : JENKINS-14138

          benoit guerin added a comment - Same on bitbucket-branch-source-plugin here :  JENKINS-48687 It goes down to the git plugin itself, not computing the changelog for the first build of a new branch :  JENKINS-14138

          Nathan Mische added a comment -

          I just ran into this today. Any update on this issue?

          Nathan Mische added a comment - I just ran into this today. Any update on this issue?

          uuaynr your workaround works only if you are always branching from master. In our team developers often branch from other developers branch or from a develop branch. And with Git there is no way to really know from which branch a branch as been created (they are only tags).

          I really wish Jenkins will be able to tell me which commit are affected on the first build. But apparently this issue has been open for years without any progress.

          Nicolas Forney added a comment - uuaynr your workaround works only if you are always branching from master. In our team developers often branch from other developers branch or from a develop branch. And with Git there is no way to really know from which branch a branch as been created (they are only tags). I really wish Jenkins will be able to tell me which commit are affected on the first build. But apparently this issue has been open for years without any progress.

            Unassigned Unassigned
            rpocase Robby Pocase
            Votes:
            13 Vote for this issue
            Watchers:
            24 Start watching this issue

              Created:
              Updated:
              Resolved: