Automation for Jira - APIs and Functions

Question

Thought I'd dump some information here for those looking since there's almost nothing out there currently.

This is for Data Center.

I know of two Automation for Jira rest APIs that you might find useful:

* GET /rest/cb-automation/latest/project/GLOBAL/rule* Will return all rules regardless of state and attributes of rules

* PUT/DELETE /rest/cb-automation/latest/project/GLOBAL/rule/[rule-id]* I have not worked out how to make the PUT calls work however, I can delete

With these endpoints, you can do things like:

* return all rules and filter for inactive, not recently modified, and then delete

I've also developed some scripts for these functions. If you're interested, let me know.

I've also enquired of Atlassian as to why there's no public information on endpoints that I believe would have had documentation prior to the take over of the addon by Atlassian.

Have a good day.

Matthew Martin · Answer

I appreciate and agree with the general guidance. I don't believe that they would modify these endpoints for a separate function that could cause impact. The likelihood would moreso be that they would simply stop them from functioning and in that sense, it makes sense if you use them, for whatever you make to be something non-essential that you are willing to lose access to.

It is what it is though. I have a massive scaled instance of Jira and Atlassian refuse to provide me with features to manage the relentless growth of configuration data. Something has to give and this all becomes an exercise in risk management.

Bill Sheboy · Answer

Hi @Matthew Martin

Yes, and... to the suggestions from David:

Here are the open suggestions for Jira Cloud and Server / Data Center to add public REST API endpoints for rule management, which you may watch / vote for to see progress.

https://jira.atlassian.com/browse/AUTO-51
https://jira.atlassian.com/browse/JIRAAUTOSERVER-229

Kind regards,
Bill

unknown · Answer

Hello @Matthew Martin

I understand your intentions, and I'm sure you mean well, but I'd like to offer an alternative point of view.

Don't do that. But, if you do, keep it to yourself.

Using unofficial, unsupported, undocumented internal APIs as 'fudges' to achieve certain outcomes when there isn't an official, supported, public API for the same purpose has a very long history of ultimately backfiring when Atlassian changes or removes the endpoint without notice.

I've also enquired of Atlassian as to why there's no public information on endpoints that I believe would have had documentation prior to the take over of the addon by Atlassian.

They don't want anyone to know about those endpoints because they probably have plans to phase them out or change them. Remember the Greenhopper acquisition? There are still people reading ancient articles about its API and they still come looking for someone to help them make the remnant APIs work or find the magical missing documentation for it... 15 YEARS after the event.