We're using TestRail and FogBugz. I found this trigger today:
http://help.fogcreek.com/7755
The URL Trigger Plugin allows you to specify an HTTP request to be
sent to a specific URL when events occur in FogBugz. To create a
URLTrigger, select one or more events that your trigger will respond
to, then add values to the URL querystring using a list of variables
presented by the plugin.
I'm trying to get this to integrate, somehow, with TestRail. Ideal steps:
In TestRail, mark a test as failed, and enter the FB number in the Defects box.
In FogBugz, resolve the case.
FogBugz, using this plugin, sends an update string to TestRail, and changes the status of the test to "Retest".
My question: is this even possible, or am I dreaming again?
This is not possible with only URLTrigger plugin.
The main issue is that TestRail has access to the FB case number but FB does not know the TestRail case numbers. To do what you want you'll need a fuller feature set to look up the TestRail cases by "defect" (FB case) and then set their status.
It can likely be done with a custom FogBugz plugin which can include significantly more logic and multiple calls to the TestRail API.
Related
I want to create a zap with branching logic. I want to do this since the gateway/REST API am using supports addition of only one web hook. I require a Zap that can perform Action 'A' when suppose trigger returns an event with 'event_type' = 'alpha' and Action 'B' will be performed when the same trigger returns an event with 'event_type' = 'beta'
example:
if trigger_A.output.event_type = 'alpha'
then 'Send mail' to 'abc#xyz.com'
else if trigger_A.output.event_type = 'beta'
then 'Send message' to 'Slack'
else
post in 'Facebook' trigger_A.output.message
Is this possible with a single Zap?
NOTE that I cannot add multiple webhooks to my REST API, and hence I cannot have multiple Triggers, and I can use use maximum 1 Zap.
Any help from the forum would be appreciated.
edit: This answer is outdated. See the other answer about Zapier's first-party support for Paths.
David here, from the Zapier Platform team.
I've got good news and bad news! The bad: this is not currently possible out of the box. It's being discussed internally and we have nothing further to say about it at this time.
The good news is that the workflow you describe is possible, but it'll take a few zaps:
Zap A: Webhooks (catch) -> Code -> Webhooks (post)
Zap B: Webhooks (catch) -> Gmail (send mail)
Zap C: Webhooks (catch) -> Slack (send message)
Zap D: Webhooks (catch) -> Facebook (create new post)
The steps are as follows:
Your service sends a webhook to Zap A with a key+value describing event_type
You have a code step that runs the real version of the pseudocode you posted above, setting a url variable based on the event type. Zaps B,C,D each have a unique url for their trigger, all of which are known to Zap A.
Zap A posts to the url returned in step 2, sending along whatever data you'd like.
One of the child zaps (B,C,D) gets triggered, doing the desired action.
So there you have it! Not pretty, but certainly doable.
Let me know if you've got any other questions!
I know this is an old question, but it's worth sharing the good news. You can now define branching logic with Zapier out-of-the-box:
Paths let you build advanced workflows to run different actions based
on conditions you decide. Paths are Zapier's conditional logic tool.
Think of Paths as If/then logic: if A happens in your trigger app,
then do this, if B happens then do something else, and so on.
The Paths feature is only available on Professional, Professional Plus, and Teams plan accounts. More can be found in the Zapier documentation on Paths.
Another option that may be helpful is using filters and multiple zaps.
In our existing CD pipeline there is a manual step to push from test to production. Furthermore only certain persons can authorise this. We control this through Jenkins freestyle jobs in views with certain users having permissions to different views.
Now we are thinking about using Jenkins pipelines. There is an input step for a user to manually approve the go ahead to the next stage.
Is there a way to control who can perform the manual input? Alternatively, is there an API for progressing the pipeline, in which case we could build the tooling to let relevant users have permission.
Research
This SO post suggests it's not possible to do the API call.
This Jenkins issue tells me there is no ability to resume a pipeline that is stopped because of a failure
So far it's looking like a resounding "NO" to authorisation of manual step and progressing via API. Any other ideas appreciated.
From the documentation that you linked to, there's a submitter parameter where you can specify the allowed users/external groups allowed to respond to the input, which sounds like it should be what you're looking for.
submitter (optional)
User IDs and/or external group names of person or people permitted to respond to the input, separated by ','. If you configure "alice, bob", will match with "alice" but not with "bob". You need to remove all the white spaces.
I need to automatically update statuses of issues that satisfy certain conditions (e.g. some custom date field in the issue is less than 30 days to the current date) in Jira Service Desk.
It seems like there is no suitable trigger available in the Workflow automation.
Can someone pls advise how this could be implemented?
We are using latest version of Jira running in a Cloud.
Thanks
You can add your own postfunctions to workflow transitions (in Groovy if i'm not mistaken). For that go to your workflow, select the transition and add a custom postfunction.
A different way (that may be a bit more complicated) is to work with the Jira REST API. There is also a jira-python lib that is using that API.
So you could write a script that checks all your tickets using JQL and updates these tickets according to your condition.
Syntax could be like this
def checkIssue(issue):
if issue.fields.status.name == "Done":
// do something
issues = jira_connection.search_issues("updates <- 1d")
for i in issues:
checkIssue(i)
Keep in mind that you can't simply set the status in the issue object, you have to make transitions according to your workflow. Could be like this:
jira_connection.transition_issue(issue, '212')
where 212 is the ID of your workflow transition.
I was wondering if there is a way to update a custom field during a workflow transition in JIRA.
The "Update Issue Field" post function is the closest feature I found, but its document explicitly states "This post function cannot update custom fields and must be positioned after the other optional post functions."
I was wondering if there is another function can support my purpose.
JIRA Suite Utilities is the standard add-on everyone uses to do this
https://jsutil.atlassian.net/wiki/display/JSUTIL/JIRA+Suite+Utilities+Workflow+Post-Functions#JIRASuiteUtilitiesWorkflowPost-Functions-UpdateIssueCustomFieldPost-Function
Not available for OnDemand
EDIT: JIRA Suite Utilities is now available for JIRA Cloud and comes pre-installed in new Cloud instances.
EDIT: And now it is no longer free.
There is a Post Function Update Issue Custom Field now in JIRA OnDemand 7.1. It seems to be pretty limited, e.g. you can't write an expression such as setting the value if it's currently empty.
I'd provide a link to their documentation page but their search claims it doesn't exist.
There is possible to execute Groovy script as Post Function and it let you do almost everything.
For example, here is script, how to update custom field (option) dependent on value of another custom field value.
EDIT: This solution is abel only for hosted instace. Not for Cloud
Is it possible to embed multiple GMail schemas in a single email? I'd like to provide users the ability to retry or cancel an action (the cancel operation would perform some cleaning stuff in the server app). However, if I try to embed more than one script, only the first one appears in the inbox (each script is correct and shows up properly when it is the only one).
Only one action is currently supported and if you include multiple actions, the first one will be used. The user experience for exposing multiple actions would be really different, so if/how to handle them is still being discussed.