J. Mash [16/Aug/16 06:23 PM] This is working beautifully, so thank you for getting it in so quickly -- I'll update further if we run into any issues, but so far so good!

J. Mash [08/Aug/16 05:12 AM] The downstream configurations in the pipeline need the shelved changes as well, that's what makes the restriction to manually triggered builds only so challenging. To get the shelved changes, most of the steps in the build pipeline has to be manually triggered where they are otherwise handled automatically by the promotions. That said, the efforts here are much appreciated and will benefit us greatly. Thank you.

Robin Shen [07/Aug/16 11:18 PM] You win, :) We will enable scheduled sheve support in next patch release (although I feel even with complex pipelines, manual triggering should not be complex as subsequent downstream configuration on the pipeline can still be scheduled).

J. Mash [07/Aug/16 10:42 PM] As I said before, these configurations consist of the entire CI/CD pipeline from dev to test, and there's a cadence there that cannot be broken. Some configurations are run every 15 minutes, some every couple hours, and some when a build has been flagged / recommended for promotion. Simply making a master configuration to trigger them all DOES NOTHING to help here, especially with regards to promotions. I understand you don't want to introduce a feature that can cause issues, that's why I'm asking you to make it OPTIONAL, by way of a new merge option. This forces it's use on no one, can easily be documented with whatever caveats you feel apropos (as is done in many other places that can be configured in QB), all while allowing those with the discipline and processes in place to make use of the added flexibility.

Robin Shen [07/Aug/16 10:13 PM] In your case, you have the discipline that no other developers should submit their shelved changes for build before shelved changes of another developer finishes building. But in a general case, this will introduce concurrent issues if one just shelve their change and go ahead to edit the repository setting to use that shelved changes before other shelved changes have been built. We do not want to introduce a feature that can easily causes issues. If I understand it correctly, most of your concern is that the build workflow is complex and there might exist dozens configurations to build to do the verification. But you can also create a master configuration to be triggered by your user, and this master configuration can go ahead to trigger other dozens of configurations. Many of our customers are already doing this way.

J. Mash [07/Aug/16 02:02 AM] This is not feasible. These configurations consist of the entire CI/CD pipeline from dev to test, so it's not the kind of thing we can simply just "create a master script" for. There's a cadence that must be adhered to, so that's a non-option. The case you mention where multiple developers need to do this simultaneously has never happened for us, mostly because we schedule out all our features and testing time to go live at different times. We rarely have multiple features go in at the same time. That said, if it were to occur, we could easily handle that case by simply changing the ownership of the shelved change list(s) to the admin build user. The majority of our build configurations execute Perl scripts, all of which use custom modules that are checked into source. Those Perl modules and scripts are used by both automated build system and developers alike, so they aren't the kind of thing we can just check in and hope they work. Thus, we shelve the changes and specify that information in the "Merge Changes" settings, and then the build system takes care of the rest. If a failure occurs and it's due to the shelved changes, we then have two options:   1. If the fix is simple, fix it quickly, shelve the fix, and let the next scheduled build pick it up (or trigger manually if needed).   2. If the fix is complicated or lengthy, remove the "Merge Changes" settings while we work on the fix, and let the next scheduled build pick it up (or trigger manually if needed). To be clear, this is exactly what we do now, but it incurs a heavy cost on the developer by requiring them to trigger dozens of configurations and babysit them all throughout the build pipeline. They cannot reasonably work on anything else until this is done, due tithe number of configurations we have and the frequency with which some of them run. -J. Mash

Robin Shen [07/Aug/16 01:21 AM] In this case each developer will need to have his/her own configuration. As if they work on shared configurations, it will definitely have issues if one developer modifies the configuration to build against one shelved change, and then another developer modifies it again to build another shelved change. Maintain a configuration per developer will be hard especially when you have different type of configurations. On the other hand, if the is manually triggered, QB can ask for shelved change number and developer credential when the user requests the build, and thus developers can work on shared configurations. Also if you do not want your developers to trigger many configurations manually, you can create a master configuration which triggers other dependent configurations. This is the reason why we do not think shelve support for scheduled builds does not make too much sense.

J. Mash [07/Aug/16 01:07 AM] I don't just randomly request features for completeness sake, I'm not sure where that came from. I explained earlier how we intended to use the feature:   - Developer does work, shelves it   - Developer enters shelve change list number for the "Merge Changes" feature   - Developer enters admin build user and password and specifies "Do Not Autosubmit"   - Dozens of Scheduled builds happen over the next few hours / days that use those shelved changes   - Developer submits when confident changes are tested and correct What more do you need/want? Thanks, -J. Mash

Robin Shen [07/Aug/16 12:41 AM] As I mentioned, it is a mistake at our side for conditions "if build is triggered manually", as we thought "scheduled shelved builds" does not make too much sense. To add shelve support for scheduled builds, I'd like to know the actual usage scenario, not just for reason of "completeness". So please describe how you will use shelve support for scheduled builds, like what value you will specify in shelved changes and user.

J. Mash [06/Aug/16 04:05 AM] Honestly, all we really want is to keep the feature exactly as it is now, but provide a means by which it can be applied to all builds. The idealist in me would probably consider making these changes:   1. Convert the existing 'Always' condition to mean always merge changes on all builds.   2. Convert the existing 'If build is manually triggered' condition to mean only merge changes on manually triggered builds.   3. Create a new 'If build is scheduled' condition to mean only merge changes if the build is triggered by the scheduler. Though, I realize that may be potentially problematic for anyone already using this feature under the assumption that 'Always' really means 'Always on manually triggered builds', so... This would suffice as well:   1. Create a new 'All builds' condition.   2. Create a new 'Scheduled Builds' condition.   3. Rename the 'Always' condition to 'Manual builds' to reflect what it actually does. The scenario you describe would likely prove to be entirely unworkable, simply because shelved changelists tend to be used as a dumping ground for half-finished work, prototypes, and who knows what else. TO unshelve everything without any sort of filter (either by changelist number or username) would almost certainly result in failed builds galore. So no, we don't need that. :) Thanks, -J. Mash

Robin Shen [06/Aug/16 01:26 AM] The merge condition of "If build is manually triggered" is a mistake as we intentionally prevented scheduled builds when implement this feature. Now discuss your usage scenario. If you want scheduled builds to pick up shelved changes for building periodically, I guess your intention is to check if there are newly shelved changes, and if there are, unshelve all of them (regardless from which developer they are) to merge with tip of the code, and then run builds against it for verification? If this is the case, at least the auto-submit feature will not work as QB has to know user/password of the developer who shelved the changes to submit the shelved changes.

J. Mash [05/Aug/16 04:50 AM] Interesting, though if that's truly the intention, then I'm not sure I understand the significance of the 'Merge Condition' setting? It seems to me, given the list of merge conditions, that this feature had to be intended to work on scheduled builds as well. I mean, if 'Always' really means 'Always on manually triggered builds', then why is 'If build is manually triggered' exist as an option in the dropdown? That said... My team is responsible for providing build frameworks, scripts, and tools to be used by both automated systems and developers. There are often cases where changes need to be made that have a high likelihood to introduce breakages or bugs and ultimately interfere with the developers ability to work. The idea we had was to make use of the proof build support to verify these changes prior to submitting them, but that has become a bit cumbersome due to the number of configurations that they need to manually trigger and keep track of in order for this to work. The ability to use the 'Merge Shelved Changes' feature on scheduled builds would allow us to shelve changes and allow the build system to unshelve them and run them through the entire gamut of our build configurations over the course of a couple hours / days. This would prove invaluable to us, and I was quite surprised it didn't just work (given the options in the 'Merge Condition' setting. Hopefully that helps explain our scenario, and would appreciate it if this could be enabled some way (even if by adding another condition to the 'Merge Condition' settings). Thanks, -J. Mash

Robin Shen [05/Aug/16 02:18 AM] Shelve support is only applicable for manual builds. That is, when a developer finishes the work, he/she shelves it and requests a manual build, and then QB picks up the developer's shelved work and run build against it to see if it is safe to submit to central depot. Any particular reason you want to unshelve some shelved changes in a scheduled build?