Is it possible for DC Plugins (for Confluence, Bitbucket, or JIra) to add structured information to customer generated support zips? I am imaging a scenario where the existing support zip mechanism has an API of some kind that one of my plugin’s classes can implement, or similar, which results in us being able to put some kind of structured data into a new file in the support zip, or added to application.xml
, or something else.
I finally figured out how to do this.
Step 1: import the Atlassian troubleshooting API as a provided dependency.
<dependency>
<groupId>com.atlassian.troubleshooting</groupId>
<artifactId>api</artifactId>
<version>2.8.0</version>
<scope>provided</scope>
</dependency>
Step 2: Make a class which implements the SupportZipBundle
interface from com.atlassian.troubleshooting.api.supportzip
. Mark it @Named
and Atlassian Spring Scanner @ExportAsService
.
SupportZipBundle.getKey()
can be used to specify a custom directory.
In SupportZipBundle.getArtifacts()
, you can add files to the support zip, like this:
@Override
public Collection<Artifact> getArtifacts() {
return List.of(new TempFileSupportZipArtifact("file contents", "settings.json", "path"));
}
Step 3: Export your class as a service in your AMPS settings:
<Export-Package>
com.example.my.package
</Export-Package>
You can play with the other settings in SupportZipBundle
to see what works for you. We tested this in Confluence and Jira, but think it’ll work for Bitbucket too. We found yet another solution for Bitbucket, but it’s not as good as this one.
It is incomprehensible to me that Atlassian doesn’t have a tutorial for this. Hopefully when you see this, it won’t have taken you 2 years to find a solution.
Impressive!
I can guess that Atlassian doesn’t see this as their supported way to help DC plugin vendors do support. Support Zips are just for Atlassian Support. Some plugins (ScriptRunner and others) do have ways to export configurations, logs etc outside the use of Support Zip files.
I’m not sure what Atlassian thinks, but if someone from Atlassian see this - we often find that full Support Zips are absolutely necessary for effective troubleshooting of customer issues. The benefits are almost too numerous to count:
- Having full application logs, including servlet container logs (i.e.
catalina.out
) if there’s a bug in our app where an exception is fully uncaught in background thread. - Having database configuration.
- Having information about clustering.
- Having information about individual node resourcing for troubleshooting performance issues.
This has been the opinion of the other DC app vendors we’ve talked to as well, though that’s been an insignificant fraction of the total number of vendors on the marketplace.
Having app-specific troubleshooting information available in one step for our customers has significantly reduced back-and-forths when we do have critical customer support issues - has definitely been a net positive for us.
That makes sense. I know when I was a customer, I was very cautious about where I sent Support Zips. Atlassian was fine, but I had to get approval for each app vendor. It helped when the data being sent was well documented and easy to verify by myself.