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.
Since I absolutely know some other poor fool is going to encounter this problem, this is the workaround I've come up with:
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:
Wayne Warren 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.