Is the bug URL variable generated by the Issue Contector accessible for use during builds

Continua CI Discussion
1


I’ve added a custom Issue Connector for TFS and was hoping that I could utilise the resulting bug URL within our build so that it can be included when I update ‘slack’ through its API.
However I cannot find any predefined variable within ‘http://wiki.finalbuilder.com/display/continua/Expression+Objects’ that defines such a thing.

Does it actually exist? Is there some way of accessing the bug URL for my own gains?

Thanks,

Simon Kennedy

2

I just had a quick look, doesn’t appear to be exposed. I’ll see if this is possible and get back to you.

3


Thanks Vicent!

4

Turns out to be not so simple, it requires extending our expression syntax, and there are some challenges to do with addressing. Issues are attached to changesets, so we could expose for example :

$build.changsets[0].issues[0].url$
or
$build.changesets.first.issues.first.url$

but a problem arrises when there are no issues or when there are more than one issue. We could collect up all the issues

$build.issues.first.url$
or
$build.issues[0].url$

again, which issue are we addressing? If there are no issues, the parser will barf. The problem is the expression is evaluated from left to right to completion, so until it fails or we reach the end. So we need to make some major changes to the parser to accomodate the above and have it fail gracefully (ie just return and empty string). Since you really want to select an issue associated with a specific repository (remember you can have multiple repos on a config) addressing becomes tricky. I kinda wish we could just use something like linq :

$builds.issues.where(i => i.reponame = “trunk”).OrderBy(i => i.date).FirstOrDefault().Url$

but that’s a ton of work.

I’ll keep toying with this and see if I can find a syntax which makes sense and is not a major deal to implement. I can’t provide an eta on this I’m afraid, juggling too many balls at the moment with limited resources.

5

Actually, a cursory look suggests that the linq idea may have some legs. Investigating.

6


Hi Vincent,

I guess there is no ‘Count’ property that we could evaluate in a ‘If’ flow control action? Perhaps
simply add the ability to test for if a property/variable is defined?

I’m not sure how you handle the ‘Changesets’ property, what happens when there are no ‘Changesets’?

I’ll be interested to see what you come up with.

Thanks,

Simon Kennedy