"Custom settings" feature requests

I have a few related feature requests, so I figured I'd throw them up here in one post for discussion (and additions?) from the community.

1) Custom build trigger settings.
a. Not *every* commit I push needs to be built (in fact, most of them don't). Allow us to set some sort of trigger - possibly a setting where only commits with the string '[BUILD]' in their commit message trigger a build? Maybe someone with more experience with version control systems can chime in on what the 'proper' way to do something like this would be.
b. Allow us to set a X minute waiting period after Pushing, during which time we can push again when we realize we forgot something. I know we can sort of do this now and it will just restart the build - but I think this suggestion is more for making server side optimization easier on you guys than it is for me. I know an extra 5 minutes would make no difference on my workflow (if I need a build in a hurry, I'm going to just build directly to the device, or failing that, I'll go to the UCB website and hit 'Start New Builds'), and if it helps your servers run faster overall, everyone reaps the benefits.
c. Allow nightly builds at a time I specify. (This one has been mentioned several times before by others, so I know it'd be a popular option.)
d. Perhaps a "smart nightly" build. Let me specify a time range (e.g. 5PM to 8PM). If I push a commit during this time, UCB assumes this is the final commit of the day and kicks off a build; if not, it kicks off a build at the end of the time range (assuming something on the repository has changed since the last build, of course).

2) Email settings
a. First and foremost, give us any settings at all WRT emails sent!
b. Similar to 1a, allow us to mark a build as "important enough to send an email" versus one that just happens in the background.
c. ...Better yet if said system could distinguish between levels of testers. [DEV] might send an email to me and other developers that it's done, [TEAM] could send one to the rest of the team including artists, [BETA] could go out to our beta tester list, etc.
d. ...Better still, allow us to create and name our own lists, and add/remove people to any number of those lists.
e. Allow users to select which platform they would like to receive email notifications about. (Good default: initially, send all platforms as a single batched email ["MyAwesomeGame #1 has been built for iOS, Web player, and Android"] after all platforms are finished, and afterwards, use the platforms that user installs for to determine which email to send.)

3) Stats - The one stat that is provided is kind of useless.
a. In the email announcing the build and/or on the website afterwards, allow users to leave feedback. This could be both a text field, and a multiple-choice (e.g. "Good", "Minor Issues", "Unplayable"). Like with 2d, allow us to create our own list of multiple-choice questions, and aggregate these responses into our stats window.

4) Build settings
a. This was mentioned in another thread and apparently it's on the roadmap, but giving us more control over how things are built - e.g. multiple customizable builds, not just one per platform (client side & server side, hi res and low res, etc etc).
b. Automatic version number incrementing - UCB could mutate the version string just before building. For example, if the source control has the version string set to "0.5", each build will be built with 0.5b1, 0.5b2, 0.5b3, etc etc. (Alternately, maybe tag it with the revision hash instead - 0.5rev20b131b01d or whatever.) This could be handy when using the version number for any sort of analytics - if revision 20b131b01d has a dramatically lower framerate when reported to the analytics package, then I know there's something changed in that rev that's killing the framerate on device (which may not have shown up in the editor), and it keeps that rev from dragging down the average framerate of all 0.5 builds.

 

Cool, thanks!

 

Added a "Build settings" item to the list.