Details
-
Improvement
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
None
-
Platform: All, OS: All
Description
I have a need to be able to record the transaction number of the last change on
my build stream when I build so that if we later need to we can always rebuild
from that point, similar to the revision number already provided by the SVN tools.
It looks from the logs like this information is already queried, but is not made
available to the build scripts; alternately (and additionally) if the stream and
depot information were made available the build script could query for that
information on its own.
Ideally, all of this information would be available as environment variables to
the script.
Attachments
Activity
Scott Tatum
added a comment - Working on this now. These were trivial to add:
ACCUREV_DEPOT - depot name
ACCUREV_STREAM - stream name
ACCUREV_SERVER - server name
ACCUREV_WORKSPACE - workspace name, if set to use workspace
ACCUREV_SUBPATH - workspace subpath, if set
The one remaining piece you mentioned is the transaction number of the last
change, which is a bit more difficult. This should be the top entry in the
changelog, I just need to pull it out. Hopefully I'll be done with this
tomorrow. This will be in the next version of the plugin, 0.6.9.
If there's anything else you'd like me to add as variables, speak now.
Scott Tatum
added a comment - Working on this now. These were trivial to add:
ACCUREV_DEPOT - depot name
ACCUREV_STREAM - stream name
ACCUREV_SERVER - server name
ACCUREV_WORKSPACE - workspace name, if set to use workspace
ACCUREV_SUBPATH - workspace subpath, if set
The one remaining piece you mentioned is the transaction number of the last
change, which is a bit more difficult. This should be the top entry in the
changelog, I just need to pull it out. Hopefully I'll be done with this
tomorrow. This will be in the next version of the plugin, 0.6.9.
If there's anything else you'd like me to add as variables, speak now. 
taxilian
added a comment - The only other thing that would be cool (this should really be a different issue
#) is if there were some way to only trigger a build on a transaction # that
actually affected files in the project;
We have found that using accuwork, every time you change an issue it seems to
trigger a build of all related projects, which is very strange.
Having those variables in there will be a great help; also it looks like you've
fixed the unhandled exception with saving a custom job using accurev, so I'll
test that tomorrow and make sure it's working for us. We have 3 servers that I
had to roll back to .6 because I couldn't save a job that was using accurev.
thanks for working on this!
taxilian
added a comment - The only other thing that would be cool (this should really be a different issue
#) is if there were some way to only trigger a build on a transaction # that
actually affected files in the project;
We have found that using accuwork, every time you change an issue it seems to
trigger a build of all related projects, which is very strange.
Having those variables in there will be a great help; also it looks like you've
fixed the unhandled exception with saving a custom job using accurev, so I'll
test that tomorrow and make sure it's working for us. We have 3 servers that I
had to roll back to .6 because I couldn't save a job that was using accurev.
thanks for working on this! Scott Tatum
added a comment - The spurious trigger problem you mention is tracked as 3967, and I have a fix in
the works. Currently, the plugin captures all kinds of changes, including
"dispatch" changes, which are issue changes. I'm adding an option to only
trigger a build on "promote" changes, which should cut out all these extra
builds. I also use AccuWork here at work and it triggers builds constantly.
If you like, I can send you a snapshot build with both of these fixes and you
can test them out for me before the official release. Just let me know.
Sorry about the problems with 0.6.7. There was a period of a few months where
the plugin wasn't actively being maintained. It recently switched hands (to me),
and I plan to be quite active on it for the forseeable future. I also have some
unofficial support from folks at AccuRev, so things are looking up!
Scott Tatum
added a comment - The spurious trigger problem you mention is tracked as 3967, and I have a fix in
the works. Currently, the plugin captures all kinds of changes, including
"dispatch" changes, which are issue changes. I'm adding an option to only
trigger a build on "promote" changes, which should cut out all these extra
builds. I also use AccuWork here at work and it triggers builds constantly.
If you like, I can send you a snapshot build with both of these fixes and you
can test them out for me before the official release. Just let me know.
Sorry about the problems with 0.6.7. There was a period of a few months where
the plugin wasn't actively being maintained. It recently switched hands (to me),
and I plan to be quite active on it for the forseeable future. I also have some
unofficial support from folks at AccuRev, so things are looking up! Code changed in hudson
User: : statlor
Path:
trunk/hudson/plugins/accurev/src/main/java/hudson/plugins/accurev/AccurevSCM.java
http://fisheye4.cenqua.com/changelog/hudson/?cs=20177
Log:
[FIXED JENKINS-3222] Added these environment variables to the build:
ACCUREV_DEPOT
ACCUREV_STREAM
ACCUREV_SERVER
ACCUREV_WORKSPACE
ACCUREV_SUBPATH
ACCUREV_LAST_TRANSACTION
These will become available when 0.6.9 is released.
Reassigning all unresolved AccuRev issues to me.