Skip to content
This repository has been archived by the owner on Mar 1, 2019. It is now read-only.

Clicking "New Build" when looking at a specific build or a "Builds for branch" could autofill that branch #623

Open
3 tasks
huonw opened this issue Oct 11, 2018 · 3 comments

Comments

@huonw
Copy link

huonw commented Oct 11, 2018

For instance:

image

In that image, I'm on https://buildkite.com/.../builds?branch=feature%2Fsplit-pipeline, that is, the list of builds for the feature/split-pipeline branch. I clicked "New Build", and it suggested "develop". As suggested in the image, it could instead suggest the feature/split-pipeline branch. The same would be true if I was looking at a specific build of this branch (the build in the background of the image is number 324, so if I was on https://buildkite.com/.../builds/324).

If there's an expectation that most "New Builds" would be on the repo's default branch, alternatives could be:

  • radio boxes like:
    • develop (or whatever the default branch is)
    • feature/split-pipeline (if there's a current branch)
    • [Other] (as a text box, and clicking in it automatically checks the radio box)
  • autocompletion of branches buildkite knows about

(Or possibly all three: radio boxes, with the current branch chosen by default, along with autocompletion in the Other box!)

@plasticine
Copy link
Contributor

@huonw Awesome — I like this idea!

@keithpitt
Copy link
Contributor

So we've gone back and forth on this over the many years of Buildkite. For a period we had this exact behaviour (sans the radio boxes) and many people asked for it to be consistently the "default branch" (which in your case @huonw is develop). When we changed it to the one branch to rule them all, people wanted the other behaviour :)

We ended up sticking with the "just keep it the same" all the time to make it sink into muscle memory what the value is. If you use manual build creation quite a bit, you may forget that we do the magical branch-detection, and accidentally trigger a build with the wrong branch. As annoying as it is to change it when you need to, at least your brain remembers to change it.

More than happy to revisit this stuff if we can make it work better! Maybe the radio boxes would work better? Or some other UI where there are some pre-filled branches with a text box for "other" (where you have to make at least one selection)

If you'd like to see something now @huonw - one idea I had was for you to upload a custom Buildkite annotation that includes a link like this: https://buildkite.com/org/pipeline#new?message=blah&branch=foo&commit=da-commit (essentially making your own "New Build" button with your own defaults)

@huonw
Copy link
Author

huonw commented Oct 15, 2018

The current behaviour makes sense given people have muscle memory, and things changing unexpectedly/subtly is never good!

More than happy to revisit this stuff if we can make it work better! Maybe the radio boxes would work better? Or some other UI where there are some pre-filled branches with a text box for "other" (where you have to make at least one selection)

I guess the radio buttons could have the repo's default branch checked by default, but still offer the current one for quick access. That said, even some form of autocomplete/dropdown of known branches would be enough too.

one idea I had was for you to upload a custom Buildkite annotation that includes a link like this: https://buildkite.com/org/pipeline#new?message=blah&branch=foo&commit=da-commit (essentially making your own "New Build" button with your own defaults)

Unfortunately I don't think this quite handles what I was using "New Build" for: testing out some variations of a new CI feature (uploading and downloading a tarball of the download cache directories of a package manager (SBT), to avoid having to redownload them all individually) with some of its options controlled by environment variables, on a couple of different short lived branches.

This means I'd want more than one annotation and they're only useful for a short period, until the feature is finished (at which time, the optimal options get written directly into our pipeline/scripts and no manual builds of this form are needed).

(Thanks for the tip about the #new?... endpoint! That will be helpful for something else.)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants