|
If you were logged in you would be able to see more operations.
|
|
|
QuickBuild
Created: 05/Nov/12 10:57 PM
Updated: 17/Nov/14 07:03 AM
|
|
| Component/s: |
None
|
| Affects Version/s: |
4.0.76
|
| Fix Version/s: |
None
|
|
|
Original Estimate:
|
Unknown
|
Remaining Estimate:
|
Unknown
|
Time Spent:
|
Unknown
|
|
Environment:
|
linux
|
|
|
Sometimes developers and release engineers can't come up with a good way to ensure that all files modified by the build are under a common root within the workspace. But modern SCM systems give us the capability to report on the status of files within a given working copy. Improving the integration with SCM systems to restore the Destination path specified in a Repository object to its pristine state would give us extra piece of mind that our build workspace is fresh and clean when we want it to be. Sometimes a build may fail catastrophically before the step the runs our cleanup target. I don't want to delete the whole workspace because then it's a full checkout for the next build.
I primarily use SVN so naturally I would like to see this level of integration in the Subversion plugin. But I imagine people using other tools would like the same.
|
|
Description
|
Sometimes developers and release engineers can't come up with a good way to ensure that all files modified by the build are under a common root within the workspace. But modern SCM systems give us the capability to report on the status of files within a given working copy. Improving the integration with SCM systems to restore the Destination path specified in a Repository object to its pristine state would give us extra piece of mind that our build workspace is fresh and clean when we want it to be. Sometimes a build may fail catastrophically before the step the runs our cleanup target. I don't want to delete the whole workspace because then it's a full checkout for the next build.
I primarily use SVN so naturally I would like to see this level of integration in the Subversion plugin. But I imagine people using other tools would like the same. |
Show » |
|
New Feature
Closed
Major
Option to restore the SCM destination to its pristine state at either start or end of build
In the case of Perforce, it's not necessarily sufficient to simply revert open changelists. Files can be deleted from disk without first opening them for delete, and files can be changed on disk without opening them for edit. Also, many files can be created as part of the build, and these will likely not be opened for add, but should be deleted as part of this feature.
The challenge that I see with this, at least with some configurations that I've "inherited" from somebody else, is that we sometimes have multiple repositories being synced to the same root directory (i.e. the workspace directory). We might be able to change this in some cases, but not in all cases. It might be possible to interrogate all repositories for each file to see which repositories claim to own the file, and to only delete it if none of the repos claim the file. If only one repository claims ownership, and that repo says that the file needs to be re-synced, you could re-sync that file. And if multiple repos claim ownership, maybe that's an error.
Maybe my use case is so specific that this feature can ignore it. Most people probably have a single repository or, if they use multiple repos, they probably keep them isolated in separate subdirectories of the workspace. Those would be reasonable choices.
I've actually started working on a custom step to handle this for Perforce repos (since that's the most common type that we have here), but the current (well, 5.1.22) base Repository class makes it hard to create a general solution. It would need to support this notion of "what steps would need to be taken to revert this repo to a 'clean' state", which I don't believe is currently there (there is a "revertLocalChange" method, but that appears to be specifically for proof build support and doesn't handle the Perforce-specific cases that I outlined above).