Can you confirm if the updates to the module versions are done automatically? I do not remember who used to manage this tool - was a GsOC project
I’ve been exchanging emails with JFrog support the whole week, and I don’t think they actually understand yet what’s the problem.
I discovered that an JFrog admin can login to the Jfrog UI and push artefacts to Bintray manually: https://www.jfrog.com/confluence/display/RTF/Distribution+Repository#DistributionRepository-DistributingThroughtheUI
It works fine, it seems that only the automatic trigger is missing.
In this thread I’ve explained this is a JFrog configuration that is not working, and I’ve been talking to JFrog support.
After several emails exchanged with them, it doesn’t seem they even understood the symptoms and they are quite fast to dismiss my reports.
I’m not confident this will be working any time soon.
What’s the main reason to have both bintray and addons?
We wanted to support a distributed ecosystem that allows people in the community to publish their OpenMRS add-ons wherever they want, as GitHub Releases, to Bintray, to Maven, etc. And then addons merely indexes them for easy searching, in one unified index. Hence making it easier for end-users to find relevant add-ons, and making it easier for developers to publish new releases in their preferred workflow.
But why do we need OpenMRS community addons to be both in JFrog and Bintray?
We use JFrog Artifactory mainly for maven build artifacts for developers. Then we distribute our software to end users through JFrog Bintray, which is supposed to integrate seamlessly with JFrog Artifactory, especially considering the fact that they are products from the same company. In other words, we use JFrog Artifactory as a development-time tool, and JFrog Bintray as a release, distribution-time tool.
@cintiadr does this still work for you? It worked for me before, but this time round, it has failed for the dataexchange module version 1.3.4
Oh sorry, my bad.
Jfrog asked me to test a few more combinations, and I left it broken since the last call I had with them. Will fix later today.
@cintiadr did you get a chance to fix this?
Last email I got from them (it has been a call plus a dozen exchanged emails) is that they won’t support this anymore.
I asked for a confirmation.
Given that they confirm so, what would you recommend as the way forward?
You can see their answer there.
But they are acting as if that functionality never existed in the first place (and we always had to manually deploy from jfrog to bintray), so I’m still waiting for their confirmation that this functionality existed and it’s now dropped.
I’d vote for us to stop using bintray altogether and configure addons to find all modules in jfrog.
@cintiadr, is there a good concise summary of what differentiates artifactory and bintray, and why bintray would be needed over artifactory alone? Does bintray support a broader range of file types? Does bintray scale better to support lots of people needing to download files around the world? I admit that I don’t find it immediately clear where one stops and the other starts.
Do you have an idea what the strategy would be for OWAs? Or can we just continue to distribute them as they have been?
This StackOverflow post is decent and this post on the StackExchange network gives an even pithier summary: artifactory is for the (relatively) storage-intensive process of storing build artifacts and all the required components to create those build artifacts; bintray is for the network-intensive process of distributing binary artifacts to different end-points.
A bit more concretely for the OpenMRS use case: Artifactory stores all the jars and omods created as part of the build process; bintray only stores the omods.
Jfrog came back and they said that automatically publishing Artifactory artefacts to Bintray never existed.
We are now looking into connecting Artifactory with the OpenMRS Bintray account to automatically push releases to Bintray so they are available for end users.
Projects under https://github.com/openmrs are deployed to the OpenMRS org account on Bintray by our CI through Artifactory. For all other projects we create links.
All modules published to the OpenMRS maven repository are automatically published to the Bintray repository without any additional steps. However, it may take up to 3 hours to see the omod on Bintray.
But this is their answer:
Please be informed that it was never seem to be an option to automatically deploy the artifacts to Bintray upon executing the maven build from the build tool, unless the distribution is invoked in any way through the build itself. However, when there is no such configuration amended to the build configuration to invoke the distribution, we request you to distribute the artifacts to Bintray via UI or REST API.
I don’t know if they are gaslighting me or not.
I’m fairly sure this worked before, so if it wasn’t part of Artifactory itself, what exactly could it be? @raff, please send me more info if you have anything.
@cintiadr, thanks for flagging me.
We have https://ci.openmrs.org/browse/AR-DM, which used to trigger the sync between Artifactory and Bintray. It fails with bad credentials. I guess the CI user has been changed on Artifactory.
However, from what I see Artifactory has been upgraded and I do not longer see the sync being configured. It was described at https://www.jfrog.com/confluence/display/JFROG/Bintray+Distribution+Repositories, but it doesn’t match what I can see in the app now.
We need to determine how to achieve that in the version of Artifactory that is available to us.
Alrighty! That was the missing link that wasn’t in the docs. Updated all the docs, fixed the build to go red if the return isn’t 200, updated the build to use API key that I generated.
I got a 200 OK, let’s see if it will work.
After a bunch of attempts to get it right (I think they changed authentication and I changed permissions), it seemed to have worked? Let’s wait for it to finish before anything else.
Thanks @cintiadr and the team , all seems fine now
I updated all docs to reflect that piece of information (about that build)