| << Back to previous view |
|
[QB-268] Be able to mark a repository so that its contents are always checked out from head version even in case of rebuild
|
|
| Status: | Resolved |
| Project: | QuickBuild |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major |
| Reporter: | Robin Shen | Assigned To: | Robin Shen |
| Resolution: | Won't Fix | Votes: | 0 |
| Remaining Estimate: | Unknown | Time Spent: | Unknown |
| Original Estimate: | Unknown | ||
| Description |
|
This request is orginally from Curtis' work flow described as below: I wanted to run another question by you regarding the workflow of quickbuild. In our build scheme, our products are built and then promoted to a QA area. Once they pass QA, they go to an RC level. At this point, some more artifacts need to be added (release notes, etc.) before the final version is ready to be promoted to the GA level for release. Basically, this means that the promotion to RC has additional steps (fetching release notes / other documentation) beyond just copying the build artifacts from the QA level. Since the release notes are usually not finished by the time the build reaches the RC level, we need a way to re-run the step of fetching documentation without disturbing the build artifacts that were promoted from QA. Our tentative solution right now is to hit "rebuild" in the RC configuration when the documentation is ready. This re-fetches the build artifacts and re-copies the documentation files to the artifacts directory. This only works because our documents are fetched via a straight file copy. If the documents were in fact in our version control system, this would not work, because the version fetched would be the exact same version that was used when the promotion to RC originally occurred. Is this the best way to go about it? The other idea I had was to make a separate documentation build at the RC level and then do a promotion from RC to GA that merges the documentation build with the promoted artifacts. I'm not entirely comfortable with that method because the two builds could get out of sync and cause problems. I guess it would nice maybe to be able to run arbitrary sets of steps on a build -- maybe have the ability to add custom buttons in addition to "rebuild" and "promote". Along with that, if the user could also control when a tagged version of files is checked out (like with "rebuild") and when the most recent version is checked out (like when triggering a regular build or promotion), it would make it possible to do the sort of things I described above. For example, I could make an "update documentation" button that checks out the original promoted build artifacts but fetches the most recent version of the documentation files. |