Hi,
after setting up my first projects with CI I have a few feature request:
- Action to read variables from stdout
- It should be shown at the dashboard if a project has a pending stage, waiting for manual promotion.
- It should be possible to cancel a build, if a stage is waiting for promotion. We want to use it for the last manual QA before the software is deployed. If our QA departure find a reason to stop the deployment, the build will stay in pending-state forever.
- Send a notification if a stage is waiting for promotion
- Action to send notification
- Custom error-messages for stage-conditions. A message like "The expression, '%MyVar%' equals '123', evaluated to False. '321' does not equal '123'." is not meaninful to a lot of users.
- Force prompting for single variables even on quickstart
- Variables in context of a stage. So they will be promted only if that stage is started.
- A Password store. There are a lot of scenarious where stages contains commandline actions with passwords (ftp, net use, etc.) It would be useful that these passwords could be configured and used like variables ($Passwords.MyPassword$). Those passwords must be hidden at the web-interface (logs, artifacts etc.)
- An error-stage, wich is executed if another stage fails.
And last but not least:
- The possibility to implement custom action-types.
Regards,
Michael
Hi Michael
- Action to read variables from stdout
On the todo list.
- It should be shown at the dashboard if a project has a pending stage, waiting for manual promotion.
This is implemented in Continua CI 1.5 Beta (stages are shown on the dashboard views).
- It should be possible to cancel a build, if a stage is waiting for promotion. We want to use it for the last manual QA before the software is deployed. If our QA departure find a reason to stop the deployment, the build will stay in pending-state forever.
Good suggestion and one that we have been discussing, although with the focus on making sure old build workspaces get cleaned up. This is defibnitely something we need to implement.
- Send a notification if a stage is waiting for promotion
On the todo list (along with a major reworking of notifications).
- Action to send notification
Won’t do, Actions are intended to be relatively high level and build focused. Notifications are a Server feature, actions are an Agent feature.
- Custom error-messages for stage-conditions. A message like “The expression, ‘%MyVar%’ equals ‘123’, evaluated to False. ‘321’ does not equal ‘123’.” is not meaninful to a lot of users.
Will have to think on this one, where would expect to define these? The expression errors can come from multiple places, and typically already have another message associated with them.
- Force prompting for single variables even on quickstart
Will discuss with the team. The whole idea of the quickstart was to be quick, ie start with the defaults.
- Variables in context of a stage. So they will be promted only if that stage is started.
I like this idea, will discuss with the team.
- A Password store. There are a lot of scenarious where stages contains commandline actions with passwords (ftp, net use, etc.) It would be useful that these passwords could be configured and used like variables ($Passwords.MyPassword$). Those passwords must be hidden at the web-interface (logs, artifacts etc.)
This is already on the todo list, however we have yet to come up with a good design that will only allow access to certain passwords, ie how to secure the password store!
- An error-stage, wich is executed if another stage fails.
Will have to think on this one. What do you envisage doing in this stage?
I can say that in FinalBuilder 8, we are removing the OnFailure ActionList and relying on try/catch/finally to do this, because it simplifies the workflow engine a lot, which has allowed us to implement other features (such as debugging included projects). So I’m not totally sold on this idea.
And last but not least:
- The possibility to implement custom action-types.
On the todo list. Most of the work done for 1.5 was a major code refactoring to make the extension points more consistent. We haven’t exposed them yet (we are using them internally), but we will do in a future version once we have bedded them down a bit more.
Thanks for the feedback,
Hi Vincent,
>> - Action to send notification
> Won’t do, Actions are intended to be relatively high level and build focused. Notifications are a Server feature, actions are an Agent feature.
If you do a major rework of the notifications, you could think about it, if there is an action wich triggers a notification via the server. Just with the possibility to select a custom template and a user or a group as reciepients.
>> - Custom error-messages for stage-conditions. A message like “The expression, ‘%MyVar%’ equals ‘123’, evaluated to False. ‘321’ does not
>> equal ‘123’.” is not meaninful to a lot of users.
> Will have to think on this one, where would expect to define these? The expression errors can come from multiple places, and typically already
> have another message associated with them.
I think stage-gates are a major place where builds fail, so this could be a good first place to start.
At the weekend I got one more request:
Better integration of issue-trackers. Actually CI shows the commit-message of the repository next to the issue-number. In a lot of issue-trackers there is an API which allows to get the issue shortdescription. Further it would be nice to set field-values or the status of an issue. So an issue could be marked as released and the build-no could be displayed in the issue.
Michael