Pipeline - Publish to Java Dev Feed will faill when retry

[saragluna]

Hey team, our nightly build pipeline failed several times on the integration stage this week. But whenever there's a network issue in the nightly build pipeline when transfer artifacts, it's hardly possible to rerun the publish job when you have more than one artifact to be published. The pipeline will fail, complaining there's a conflict of artifact (since the first one has already been transferred successfully). So there's no chance for the following artifacts to be deployed.

• The first attempt failed because of service unavailable
• Second attempt failed for conflict

409 Conflict - The feed 'azure-sdk-for-java' already contains file 'azure-identity-spring-1.2.0-alpha.20210203.0.jar'

So is there a way to catch the 409 Conflict status and make the pipeline continue so the remaining artifacts could get a chance to be deployed? Otherwise, we will wait days to make a successful deployment.

[weshaggard]

@mitchdenny do you have any ideas on how to improve this process? It is probably worth understanding why the publishing to the devops feed is failing so often.

[mitchdenny]

I think that this particular issue is down to a quirk of the way that Azure Artifacts supports Maven. My understanding is that at least part of the package files are getting uploaded, but subsequent files fail. However, Azure Artifacts takes it as the package has been published because it doesn't really know what other files it should be expecting, so when you go to publish again it fails.

Other package formats that Azure Artifacts supports are more atomic in nature (i.e. one *.nupkg file, one *.tgz file etc). Unfortunately Maven has multiple files and there is no single manifest which dictates which files are missing to determine whether the artifact should be taken as "published".

The way SonaType handles this is that you publish to a staging repository and then "release" that into the main repo (after certain validations have been done).

[mitchdenny]

After deploying this classifier I'm not seeing any instances of this so I'm going to close this issue since it doesn't seem all that common.