• Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • subversion-plugin
    • None

      I have attached a patch which exposes SVN_AUTHOR and SVN_COMMIT_MSG environment variables (and _n versions for multi-module projects) in the same way that SVN_REVISION and SVN_URL are exposed.

      This patch is made against trunk@39940, and it would be great to get it into the 1.33 release.

      As per my previous patch, I'm afraid I cannot get the test suite to run ("mvn clean install" fails the tests), so I haven't written any tests for this patch, and cannot validate that it doesn't break any existing tests. I've done "real life" testing, and it seems good.

          [JENKINS-11111] Add SVN author and commit message env vars

          Danny Yates added a comment -

          Hi,

          I spent 4 hours last night trying to get tests running, and got nowhere. I'm a big fan of TDD, so I'm happy to have another go. I'll try and run the tests again and open another ticket with any issues I have.

          You're right, that it doesn't handle multiple authors/messages, but that's exactly the same behaviour you get with the current SVN_REVISION variable. It just tells you the latest revision that you're building. The SVN_AUTHOR and SVN_COMMIT_MSG variables do the same thing.

          Danny

          Danny Yates added a comment - Hi, I spent 4 hours last night trying to get tests running, and got nowhere. I'm a big fan of TDD, so I'm happy to have another go. I'll try and run the tests again and open another ticket with any issues I have. You're right, that it doesn't handle multiple authors/messages, but that's exactly the same behaviour you get with the current SVN_REVISION variable. It just tells you the latest revision that you're building. The SVN_AUTHOR and SVN_COMMIT_MSG variables do the same thing. Danny

          Danny Yates added a comment -

          OK, I've spent several more hours on this. The tests are really hard to work with because they take so long to run because they work with real external repositories. What my ISP bandwidth limits are looking like this month, I dread to think!

          Attached is a second patch which adds testing for the first patch!

          When I run "mvn clean install" on the head of trunk, I get a single test failure. With my patched tests, I get more failures (because the implementation isn't there), and when I add my patched implementation, I get back to having a single test failure the same as on head. That's the best I can do without figuring out why head won't pass tests for me!

          I hope that's OK.

          Danny

          Danny Yates added a comment - OK, I've spent several more hours on this. The tests are really hard to work with because they take so long to run because they work with real external repositories. What my ISP bandwidth limits are looking like this month, I dread to think! Attached is a second patch which adds testing for the first patch! When I run "mvn clean install" on the head of trunk, I get a single test failure. With my patched tests, I get more failures (because the implementation isn't there), and when I add my patched implementation, I get back to having a single test failure the same as on head. That's the best I can do without figuring out why head won't pass tests for me! I hope that's OK. Danny

          kutzi added a comment -

          > You're right, that it doesn't handle multiple authors/messages, but that's exactly the same behaviour you get with the current SVN_REVISION variable. It just tells you the latest revision that you're building. The SVN_AUTHOR and SVN_COMMIT_MSG variables do the same thing.

          Yes, but that doesn't mean that's the right thing to do.

          > Attached is a second patch which adds testing for the first patch!

          Great!

          kutzi added a comment - > You're right, that it doesn't handle multiple authors/messages, but that's exactly the same behaviour you get with the current SVN_REVISION variable. It just tells you the latest revision that you're building. The SVN_AUTHOR and SVN_COMMIT_MSG variables do the same thing. Yes, but that doesn't mean that's the right thing to do. > Attached is a second patch which adds testing for the first patch! Great!

          Danny Yates added a comment -

          > > You're right, that it doesn't handle multiple authors/messages, but that's exactly the same behaviour you get with the current SVN_REVISION variable. It just tells you the latest revision that you're building. The SVN_AUTHOR and SVN_COMMIT_MSG variables do the same thing.

          > Yes, but that doesn't mean that's the right thing to do.

          I agree. But my goal here is simply to provide a little more information to the build. Right now, SVN_REVISION tells you the latest revision in the case that your poll picked up multiple revisions. That's a good thing to know - you can stamp the built binaries with it, etc. Knowing all the interim revisions is probably not useful.

          If someone thought that providing all the interim revision numbers/authors/commit messages would be useful, they could raise an enhancement request and/or submit a patch for it. For me, having this information will be useful and will prevent me from having to screw around with direct SVN calls to retrieve it from within our ant scripts. Which, of course, is entirely evil.

          Danny Yates added a comment - > > You're right, that it doesn't handle multiple authors/messages, but that's exactly the same behaviour you get with the current SVN_REVISION variable. It just tells you the latest revision that you're building. The SVN_AUTHOR and SVN_COMMIT_MSG variables do the same thing. > Yes, but that doesn't mean that's the right thing to do. I agree. But my goal here is simply to provide a little more information to the build. Right now, SVN_REVISION tells you the latest revision in the case that your poll picked up multiple revisions. That's a good thing to know - you can stamp the built binaries with it, etc. Knowing all the interim revisions is probably not useful. If someone thought that providing all the interim revision numbers/authors/commit messages would be useful, they could raise an enhancement request and/or submit a patch for it. For me, having this information will be useful and will prevent me from having to screw around with direct SVN calls to retrieve it from within our ant scripts. Which, of course, is entirely evil.

          Tom Canova added a comment -

          Any plans to include this in release? I'm also interested in this. I have to be able to get to the subversion commit comments from my script so I can do some things (such as update TFS work items which are referenced in the commit comments). If the subversion plugin doesn't provide an environment varaible with the set of authors and commit comments, I'll need to do extra work in the script to get the commit messages from the multiple projects I'm using, which could obviate the need for the jenkins subversion plugin. I'd rather this be done in Jenkins, however.

          Tom Canova added a comment - Any plans to include this in release? I'm also interested in this. I have to be able to get to the subversion commit comments from my script so I can do some things (such as update TFS work items which are referenced in the commit comments). If the subversion plugin doesn't provide an environment varaible with the set of authors and commit comments, I'll need to do extra work in the script to get the commit messages from the multiple projects I'm using, which could obviate the need for the jenkins subversion plugin. I'd rather this be done in Jenkins, however.

          Tim Nolte added a comment -

          What's the blocker on this being implemented. I was really hoping something like this would be available so that I could send out build notifications only to the SVN committer.

          Tim Nolte added a comment - What's the blocker on this being implemented. I was really hoping something like this would be available so that I could send out build notifications only to the SVN committer.

          Raza Ahmed added a comment -

          Is this suppose to work with 1.553 release but I tried but seems not working. I would like to use this to send out build notifications only to the SVN committer.

          Raza Ahmed added a comment - Is this suppose to work with 1.553 release but I tried but seems not working. I would like to use this to send out build notifications only to the SVN committer.

          This enhancement is almost 4 years old now. Will it ever be implemented? What is the blocker? I would love to have these variables available!

          Scott Bradshaw added a comment - This enhancement is almost 4 years old now. Will it ever be implemented? What is the blocker? I would love to have these variables available!

          Timot Tarjani added a comment -

          I also think it would be useful. Please implement it!

          Timot Tarjani added a comment - I also think it would be useful. Please implement it!

          Devilsbane added a comment - - edited

          Still waiting for this to be implemented. I'm calling Ansible from Jenkins and Ansible needs the user ID of the person who checked in the build.

           

          Short of getting this patch included (which I'm not holding my breath for since it it has been in the works for coming on 9 years) what are my other options? I use a nant plugin to run a powershell script. I could collect the name in my script, but how can I pass this back to Jenkins as an environment variable?

          Devilsbane added a comment - - edited Still waiting for this to be implemented. I'm calling Ansible from Jenkins and Ansible needs the user ID of the person who checked in the build.   Short of getting this patch included (which I'm not holding my breath for since it it has been in the works for coming on 9 years) what are my other options? I use a nant plugin to run a powershell script. I could collect the name in my script, but how can I pass this back to Jenkins as an environment variable?

            Unassigned Unassigned
            danny Danny Yates
            Votes:
            6 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated: