This is something that often annoys me, I’ll be looking at a build from a branch and then go to click the “New build” button and the form will default to “master” for the branch.
It would be great if it could “smartly” select the branch based on the context of the page you’re on.
Also it would be great if “Message” was an optional field that could be populated from the commit message if omitted.
I have wanted this too, many times. IMO the default commit message should be 
.
@navitronic thanks for the suggestion! Here’s another similar feedback issue that has some more context on where we sit on it:
One thing we could do is something like this…
…and have a quick link to use the current branch.
I am wondering though, when you do hit “New Build” and want to use the current branch, I assume you’re using HEAD? And the commit message is something random? i.e. is the action you want to perform a “just trigger a build on the latest HEAD the current branch” kinda thing?
Is your workflow perhaps:
I’m testing a new BK pipeline setup and I’m iterating on it. Hitting Rebuild uses the current commit, but ideally it’d just trigger a build using HEAD on the current branch
Thanks for the thoughtful consideration @keithpitt
Yes, you pretty much nailed my workflow. I’ve been through the process of setting up pipelines across a couple of companies now and maybe have used the new build button a few more times than your average user.
I like the idea of a context sensitive quick link. I think it makes things a bit easier for users in my position, without “moving the cheese” of users expecting a master build (which I guess a few people might use to trigger a build -> deploy on master in continuous deployment environments).
I just did a dirty mockup locally (just an image at this point, it doesn’t actually work) and I wonder if something this would solve the problem?
So when you click “Rebuild”, it’d offer you this context menu allowing you to do different things. In your case, you’d want the second option. The first option is the current behaviour. The third option would open the “New Build” box with everything ready to go (allowing you to make changes just like custom env)
Would something like this be a good solution? (or maybe putting it behind “Rebuild” is a little confusing?)
Or another take, we just add a “Copy” like button in the “New Build” dialog:
I’m kinda leading towards this one now to be honest, because I think mixing “Rebuild” with “Not really rebuild” is probably a bit confusing.
I love the idea behind this button, but figuring out how to apply it to the “New Build” button, rather than the “Rebuild”, as rebuild feels like it should always be a repeat of the build you’re on.
The “Copy from” link seems like it could be troublesome, as it might be tricky to get context of what “Build #123” might represent when the form is in a modal.
Appreciate the effort regardless.
Totally (I mocked those images up very late last night, and I don’t think they solve the problems well). Hopefully the process of working through this is helpful! (It’s a nice experiment being way more transparent about how to solve the problem, and keeping you involved, let me know if you find it annoying 
)
So the other idea I had this morning is that we embrace what you’re trying to do, and provide specific buttons for it. i.e. what if pipelines started out in “setup” mode. When a pipeline is in this mode, there’d be a big “create new build on HEAD” type button above all the builds you’re looking at. Since we know what you’re trying to do, it makes sense that we call it out.
Once you’ve got the pipeline up and running and builds are green, we can have a “I’m done setting up this pipeline” button, which removes the “Trigger on HEAD” button, and a cool optional step - reset the pipeline back to Build #1, and remove all the old crappy ‘testing this’ commit messages.
What about something like that?
I really like the idea of the setup mode for a pipeline the more I think about it, but not sure it helps with the original issue of being on a branch and the New Build button being slightly unhelpful with being pre-populated with master. Although my brain is now struggling to remember why I was clicking on “New Build” on a branch so often to warrant this topic. 
Here’s a step in the right direction that I’ve shipped:
“Message” is now optional, and will be replaced with the actual commit message when the build starts. This should make quick “New Builds” a little bit faster!
What about something like this, that shows (at most) the last 3 branches you personally created/pushed a build on, for that pipeline:
If you were testing a branch over-and-over again, it’d mean you tap “New Build”, tap the dropdown button, tap the branch name, tap “Create Build”.
Versus the current process, which is to have the branch name copy+pasted somewhere each time (or you forget to copy the branch name, close the dialog, copy it, reopen the new build dialog, and paste it in)
I like that 
I was just about to post a new feature request for auto-completing branch names in the New Build UI. What you’ve mocked up is exactly what I’d love to see added!
That works for us!
Any of these solutions would be an improvement on the current behavior. What’s the status of this feature? It’s been a couple years 
Hey @mycarrysun, this one has been around for a while! I’ve reached out to the team to see where things are at, and we’ll be sure to update this thread once we have an update.
