During our build process, managed by Jenkins, we actually update some files and commit them to the repository. Since this happens by our build account, I am easily able to ignore this account's commit so as not to trigger an additional build.
My problem is, I'd like to include the files we updated during the build in our change list for that build, but instead, Jenkins shows the changes in the commit that triggered the build AND the changes that happened during the last Jenkins build (via our build process).
That stinks. It'd be great if Jenkins included in the change list: 1. The change(s) that triggered the build 2. Any changes made during the build process, which would have been included in the end result.
Any way to make this happen? I don't see anything obvious. I can explain what is happening to our dev team, but it's still not an accurate picture for the change list to reflect content actually included in the previous build and not include changes made during this build.
I realize we could change our build process to not do these updates, but right now that is not an option.
Thanks!
Update: If I split the job into two parts this may work. First job does the repo change and commit, sets SVN_REVISION and triggers the second job. The second job does the actual build for the new revision. The second job should reflect the right changes (original commit trigger change and the repo changes performed by the first job). I need to test this out. Input from others is very welcome.