Details
-
New Feature
-
Status: Open
-
Major
-
Resolution: Unresolved
-
1.0.3
-
None
Description
Each build definition should not work off of the same workspace as another build definition. Otherwise, the notion of overlapping schedules is meaningless.
This particularly affects configurations where several build definitions are defined for varying situations, such as a seperate one for continuous (five minute loop), one for a daily integration build, one to push the site nightly, and a "never" scheduled build (scheduled for 2061 or something) that can be used for full manually triggered builds, but will never build on its own. These four build defs have different purposes, and change in the source of one should imply change in the source of another. However, if they share a workspace, then change in the shared workspace would be masked by the five-minute-loop schedule, which would (presumably) succeed, thus impeding any other builds.
Also, the changes between the build at 5:30 and the build at 12:00am would be large, but if there were fifteen other builds in between because of continuous build schedules, then the "changes" listing in the build process will be masked by all those other changes. Having separate workspaces provides a clean solution to many of the above issues, and allows problems to be examined in isolation.
Attachments
Issue Links
- is depended upon by
-
CONTINUUM-564 Change focus of build from projects to Build Definitions
-
- Open
-
- is related to
-
CONTINUUM-1507 Build are always done when it exists several build definitions for the same project group
-
- Open
-
-
CONTINUUM-1724 Queue build definitions separately
-
- Open
-
-
CONTINUUM-509 Ability to process scheduled builds the same as forced builds.
-
- Open
-
- relates to
-
CONTINUUM-685 Make builds optionally build even when there are no changes
-
- Closed
-