This is a description for how I wish Continua would deal with branches. I hesitate to call it a feature request because I realize how much work this would be to implement, and what a big change it would be to the UI.
Right now in Continua, each Configuration shows the status only of the most recent build. If our master branch finishes successfully, the Configuration turns green. The problem is that we have multiple branches, only one of which may be failing. If our develop branch is failing, it gets hidden each night when we automatically trigger a master branch build. We don’t notice that “develop” didn’t build because the home page is all green. (A notification is emailed out, but truthfully everyone just filters these into the trash).
It would be nice if Continua would show build status for each branch. If only a single feature branch is broken, we should see that branch as failed and shows up red until it’s fixed, but the rest of the branches remain green. I attached a mock of a VERY rough idea of what the home page might look like. On the left are all the configurations; if they have any failed branches, they’re red. If all branches last built successfully, they’re green. If they’re building, they’re blue. On the right is a box per failed branch. Maybe building branches could show up on the right also? I’m not sure.
If the branch is removed from SCM, the branch would no longer show as failed in Continua. This way, an abandoned branch can be removed from Continua’s display.
I don’t want to create a new Configuration for each branch because we create lots of branches, so it would be a pain to add new Configurations and filter them to only build specific branches.
I realize this would be a pretty major change, and I also recognize I’ve only considered how this would interact with Git and not the other SCMs that Continua supports. But it sure would be nice.
Hi Stephen
Interesting idea, but it would need a lot more thought. A quick 5 minute discussion with the team identified a number of issues with this (but also generated some other ideas we will investigate).
Some of the issues :
1) Configurations can (and often do) have multiple repositories associated with them, which begs the question, would branches from all repos be used? Or perhaps we need a way to specify the ‘main’ repository for the config (something we have considered before, but hadn’t made a decision on).
2) Determining when branches are closed or deleted is not simple… most of our branch detection is based on changesets. This is already on our todo list for other reasons so it’s not impossible (depends on the repo type).
3) Limited real estate. There’s only so much room for each configuration, so it’s not practical to show all branches. We could I guess allow you to configure which branches are shown, but still the idea with the Tile view is to show as many configurations as possible.
One of the ideas that came from the discussion was to have a Branches tab in the Configuration view which would be similar to the Activity tab but show the most recent build per branch (assuming (1) & (2) are implemented).
Suffice to say we do plan to improve the status views in the future and we do welcome suggestions like this. What we end up with might not be the same thing, but we get the gist of what you are trying to achieve and will defintely take it into account.
For (1), I can see how this would be tough to solve well without having a “main” repository. I would think most projects have a main repository and maybe other helper repos, not usually two equally-important repos. Maybe a branch gets added to a Configuration if a repository trigger starts a build? But it’s still not clear how to deal with time-based triggers or manually-started builds.
For (3), perhaps a failed build gets a normal-sized tile, but the list of all configurations has much smaller tiles. They could be much shorter so they fit on the screen better. My thought is that the failed and active builds are the ones your eye should be drawn to, and I think usually there are much fewer of them. The “all configurations” is more of an overview of everything, and successful builds aren’t as important to see. But, that’s just us; I’m sure other teams work differently.
Attachment unavailable
My ‘beef’ with that would be the whole ‘moving cheese’ problem… since we also use these status views to navigate to configurations, if they are moving around based on their state that would probably get quite annoying. I think the trick will be to make the status views more dashboard like where you can configure what gets displayed. This was part of our original design, but shelved it in favor of simplicity for v1 (and due to technical issues).