Is there some kind of strict mode for applying commands?
Hi,
we've just had a problem with an Build Server Integration that tried to apply a state that didn't exist anymore.
If it would just have failed, it wouldn't be too much of a problem, but instead the command was interpreted. The word "Test" was part of the command and we unfortunately had a project called "Test". So all of the targeted issues were moved to the project, losing a lot of their fields and settings...
So my question is:
Is there some kind of strict syntax i can use for that kind of integrations?
For example something like {},"" wrapping the words of the command preventing single words to be interpreted as a completely different command.
Please sign in to leave a comment.
I would say there is.
Instead of just Test one should write State Test.
I don't think that solves the problem in the case where the state consists of several words. See example below:
I believe it does. As you can see the command is now has errors, therefore it won't be applied.
Commands are being applied in a transactional, all or nothing, style.
Thanks for your answers! :)
you're right, in that dialog it doesn't apply anything..
Do you know if it's the case for mappings in a Projects' Build Server Integrations, too?
This is what we had in one of the mappings. "Test" exists as a project (and thus command), "Deploy" isn't recognized in the normal dialog:
I assumed that this was the source for our problem. But if you say, that it shoudn't execute anything, I might have to look again.
PS: I know, we're not using the State keyword above but I suppose it wouldn't change anything, right?
> Do you know if it's the case for mappings in a Projects' Build Server Integrations, too?
To the best of my knowledge, it should behave the same way
> I assumed that this was the source for our problem. But if you say, that it shoudn't execute anything, I might have to look again.
You may be correct in your guess after all. What's different for VCS integrations, is that they may treat the unknown tail part of the command as a comment to add.
> I know, we're not using the State keyword above but I suppose it wouldn't change anything, right?
I'd say it would. `State Test Deploy` string will under no circumstances become a project, causing so much damage.
The only reason we're still keeping this short ambiguous notation around is backward compatibility.
Ah, alright, I'll put State in front of it. Seems like that would solve my problem. Thanks :)