Support the DC upload

[bberenberg]

Not sure if we properly support DC uploads or not, see https://community.developer.atlassian.com/t/releasing-server-data-center-apps-using-marketplace-rest-api/34286/3?u=george-soteri

[nhan-nguyen-se]

Currently the release action omits field compatibilities when create new version. As stated in the API documentation , if that field is omitted then marketplace will use the previous compatibilities which is probably the latest DC version (because DC version number is greater than the server one). As the result, release action only create new version for DC.

Then I made the change in release action to include compatibilities which specifies both server and DC compatibility information, then I got the issue stated in the community link above: There is only one version is created (and it compatible with both server and DC). It does not like what happen if the app is release via web interface (two separated versions with the same version name but different build numbers.)

In the thread they said about adding custom header to request but I don't know how to use it. The header value is weird and I'm asking the author for more information.

[nhan-nguyen-se]

Tried to use header X-Mpac-DataCenter-BuildNumber to create single version name with different build numbers for server and DC for example app but got below error:

{"code":400,"message":{"errors":[{"message":"Sorry! You can no longer publish a new Data Center app with server compatibility. Learn more: https://community.developer.atlassian.com/t/end-of-new-server-sales-resources-and-support-for-the-ecosystem/42325."}]}}

As mentioned in the link, newly submitted apps are not allowed to publish DC version with server compatibility. Also tried on web interface (I created a test marketplace account and a vender) and it does not allow to do that too.

So our example app does not have the same state with our prod apps making it inappropriate for testing purpose.

[nhan-nguyen-se]

I'm still waiting for a response from community on how to use X-Mpac-DataCenter-BuildNumber header. My guess is that we need to explicitly provide the server build number in versions create request body, and also include that header with a value of server build number increased by 10.

Once we know how to use that header, we need to figure out a way to test it since our example app is useless for marketplace place upload testing.

[bberenberg]

I am confused with what you're saying. We should be able to upload new versions of apps. Not brand new apps in their entirety.

[nhan-nguyen-se]

Yes. For the existing public apps (like our production apps) we can still publish their DC version with with server compatibility using web interface (same version name but different build number). The problem is how to archive the same thing by using REST API. The community suggest adding a header in the request and I'm asking them for more information.

When I got more information about how to use the API from the community I need to test it on a dummy app. The problem is I cannot use our example app for that purpose because Atlassian does not allow to publish its DC version with with server compatibility. More information here https://community.developer.atlassian.com/t/end-of-new-server-sales-resources-and-support-for-the-ecosystem/42325

[nhan-nguyen-se]

And this reply from Atlassian staff https://community.developer.atlassian.com/t/reminder-we-will-stop-accepting-new-server-app-submissions-from-may-1-exceptions-to-be-made-for-bamboo-and-crowd/47042/3

[bberenberg]

This doesn't make sense Nhan. The thread you're asking how to get the server version number, that is dynamically generated by incrementing the previous version and leaving a consistent gap. You can look at old NAFJ versions to see what the gap is.

At the same time, you're talking about publishing DC version being blocked. This is a limitation yes, but this seems like something we need to request Atlassian to unlock on our test listing right? Not anything to do with the actual upload functionality we have here.

[nhan-nguyen-se]

Hmm not sure you mean his approach does not make sense or my question for him does not make sense?

He mentions that using a header will help. Look like he is using python for his automation script and manual passing the server build number. So I confuse and want to learn more how to get the server build number.

If we can ask Atlassian to unlock our testing app so that we can publish new public version for both DC and server, just like what we can do with our prod app, then no problem.

[bberenberg]

We don't need to publish public versions of server and dc, we need private versions.

The server build number is the previous build number incremented by a set interval as I described above. Please go look at past numbers for NAFJ versions to see this.

[nhan-nguyen-se]

Okay. I got what you mean about server build number.

Even for private versions, we still need to ask Atlassian to unlock our testing app (example-confluence-server-app) so that we can publish DC version with server compatibility (which mean same version name but different build number). Currently we can only publish DC version, not DC version with server compatibility.

I mentioned public because I see latest versions of our app are public:

• https://marketplace.atlassian.com/rest/2/addons/com.riadalabs.jira.plugins.notificationassistant/versions/latest?hosting=dataCenter
• https://marketplace.atlassian.com/rest/2/addons/com.riadalabs.jira.plugins.notificationassistant/versions/latest?hosting=server

[bberenberg]

But we previously had server and dc at https://marketplace.atlassian.com/manage/apps/1227599/versions and you don't need approval from them to publish a private version, only to make it public.

[nhan-nguyen-se]

I don't have access to the link because it's private. But I guess server and DC have the same version and the same build number? If so that is the issue stated in the community thread.

[bberenberg]

Here is the example from NAFJ:

They're not the same, they are incremented.

[nhan-nguyen-se]

No I'm talking about our testing app: example-confluence-server-app. The link you mention earlier is our testing app.

As I said before, example-confluence-server-app has problem, not our prod apps.

[bberenberg]

You're linking a Git Repo, this doesn't help as you have created multiple apps on marketplace. Which app are you using there? Is it https://marketplace.atlassian.com/manage/apps/1227599/versions ?

[nhan-nguyen-se]

Yes https://marketplace.atlassian.com/manage/apps/1227599/versions

[nhan-nguyen-se]

@bberenberg So are you working with Atlassian to unlock https://marketplace.atlassian.com/manage/apps/1227599/versions?

[bberenberg]

Yes I am

[boris-moduscreate]

Hey so I got Atlassian to start looking at this, but we're still not sure what you need here. https://marketplace.atlassian.com/manage/apps/1227599/versions is showing both DC and Server issues in the history. We only want this action to push private versions. What exactly do we need from Atlassian here?

[nhan-nguyen-se]

@bberenberg I don't have access to https://marketplace.atlassian.com/manage/apps/1227599/versions. Can you screenshot it to me?

[boris-moduscreate]

You should be able to access it as the devops account?

[nhan-nguyen-se]

@boris-moduscreate We need the ability to create the same version for both DC and server with different build number, like NAFJC:

We unable to do the same with our example app:

Here DC and server have the same version and the same build number.

The community suggest to use X-Mpac-DataCenter-BuildNumber header, I tried and got this error: {"code":400,"message":{"errors":[{"message":"Sorry! You can no longer publish a new Data Center app with server compatibility. Learn more: https://community.developer.atlassian.com/t/end-of-new-server-sales-resources-and-support-for-the-ecosystem/42325."}]}}

So we need Atlassian Support on how to use that header for our example app. (Using that header is confirmed a solution by community so I think the issue is about our example app)