we’re in the process of moving to JIRA as our new issue management software. One thing we’d like to be able to do, is to automatically set some properties of related JIRA issues, when running a build. For every changeset get the list of issues and for each issue assign the JIRA item as “testable” and also assign the “version/buildnumber”. This has the advantage, that the test-team knows exactly what issues can be tested and in which build the change was implemented.
We are looking into ContinuaCI’s events to call HTTP requests. However, we have not been able to get the list of changes here. Actually what would be needed is very similar to the changesets, that are available with notification templates.
We still need to verify, that it is actually possible to update JIRA items using this REST approach.
Any ideas how to achieve such a workflow are appreciated.
We don’t currently expose the issue ids as part of our object expressions. This is something that we can add soon.
The other problem however is that multiple issues can be related a build. As far as I can see, the JIRA API does not allow you to update multiple issues in one call, and there is currently no way to iterate through a collection of items and run one build event handler for each item. We have been brainstorming ways to improve on this today but any solution will take some time to implement.
We are also considering adding a similar generic HTTP request action to FinalBuilder, and possibly also replicating the event handler as an action in Continua CI. If we exposed the list of issue ids as an array, you could use the For Each action to iterate the issue ids and call such an action for each issue.
Meanwhile your only option would be to call out to an external program or script which does the REST API call you require.
To get things running we first need the issue-collection. It should include unique items only. Sorting is not relevant, though it might be an option. The collection could then be used to pass to a command line tool. This is something we can code ourselves. One way to pass the collection to the tool is by passing it as a string, which contains the issues as a comma-separated list. This solution will iterate the list itself and take care of appropriate action. Another option would be to have ContinuaCI iterate over the issue list and call the tool multiple times. Each time with one issue-item only.
Any feature that will support such action using ContinuaCI natively is welcome, of course. I don’t want another action in FinalBuilder, as we are trying to remove dependencies between the two tools.
We’ll make the issue ids available as a comma-delimited list which can be iterated using the For Each action. This will be in the next version release.
Our intention is that you keep using FinalBuilder with Continua CI. FinalBuilder has many actions and functionality that will never be added to Continua CI.
Excellent One question as i have not used the for each action with Continua before. What action will be executed for the for each action? Is it the next action right after the for each action?
To get this right: We don’t have plans to drop FinalBuilder. It is an important part of our tool chain. However, FinalBuilder has its strength, so has Continua. FinalBuilder is great to build my apps, setups & artifacts. But passing items from Continua to FinalBuilder just to have it execute something seems wrong. In my opinion it is better done in Continua, such as notifications and issue handling. All that information is available in Continua already.
One question as i have not used the for each action with Continua before. What action will be executed for the for each action? Is it the next action right after the for each action?