Sorry, I didn’t really understand your answer.
So, is bintray an acceptable tool for your team for new modules? If not, what’s missing there?
Also, do you know which modules or artefacts that belong to you are already deployed to jfrog?
@cintiadr Yes, bintray is ok for our team.
Awesome, I raised ITSM-4204 for the work with the modules already there.
I don’t believe I will start working on it for 2 or 3 months :D, but I will try to keep you all informed when that happens.
@cintiadr Kindly update us on the progress of @makombe request. Let us know in-case anything is required from us for fast track this request.
The decision was for @makombe team to create and maintain their own bintray, so there’s no request pending.
Kindly clarify since the request from @makombe was to allow us to publish our modules and artifacts onto the openmrs repository.
Kindly let us know if this can be done.copying @aojwang
Let’s try to undo the misunderstanding.
@makombe requested to allow you to publish your modules (not community modules owned by our github organisation) to our maven repository.
That’s not how our maven repository is supposed to work. We should only have community owned modules, the ones that are in our github repository.
The suggestion we give for other teams is to setup their own bintray. So I asked if that solution would work for your case, and the answer was ‘yes’.
If it’s not on github/openmrs , it shouldn’t be in mavenrepo.openmrs . The exception is the teams which were already there due to historical reasons, I won’t just go and delete them.
Okay @cintiadr .This is well understood. Thanks.
As I’m handling JFrog for other reasons, I created now ‘modules-pih’ and ‘modules-pih-snapshots’ in JFrog.
I granted access to write to these repositories for only PIH users (including your CI user). No other system or person has permission to deploy there. It’s part of the ‘public’ repo, so it should work as before.
So all you’d have to do is change your pom files to use the new URLs. Everything would still be exactly the same.
In a couple of months, I’d like to change your CI user to only have access to deploy to those repositories (to avoid any confusion). All ‘human’ users should continue with the same access as now.
Great, thanks @cintiadr, I will test it out!
@mogoodrich while the integration between jfrog and bintray is not working, I do expect that jfrog support will eventually help us there.
Which bintray repository (if any) would you like your modules to be automatically deployed to? Would you be ok to have an PIH bintray repository?
Same for @ssmusoke and UgandaEMR modules.
@cintiadr re: bintray, I’m not sure… what are we thinking the potential options are? How does/will the automatic deployment work? (if there’s a thread describing everything feel free to just point me to that link )
When you say “PIH bintray repo” are you talking about having a PIH branch within the OpenMRS organization, or PIH requesting it’s own bintray account?
So when deploying an artefact to JFrog, we can configure it to automatically copy artefacts matching a certain REGEX to be deployed to a bintray repository automatically. It used to work, currently not working, but I have hope their support will eventually sort that out.
At this moment, any artefact that is deployed to maven repository ‘modules’ that matches ‘(.)/(.)-omod-([^-]*).(jar|omod)’ would be automatically deployed to Bintray OpenMRS/omod
The options I see are:
- PIH (and UgandaEMR) are also deployed to bintray OpenMRS/omod. It’s indistinguishable in bintray which modules are community based or for you, and we continue to control permissions to that.
- We create new bintray repositories in the OpenMRS bintray account/organisation, like ‘omods-pih’ and ‘omods-ugandaemr’. It’s easy to distinguish between modules that community based or not, but permissions and control access still done by us.
- Each one of you create your own Bintray accounts/repositories. It’s free and you don’t have to host anything, and we configure JFrog to deploy there.
- Neither of you require bintray at all.
Hard for me to tell which one fits your requirements and our community.
So I was able to configure a couple of our PIH modules to deploy to the the new repos @cintiadr created and everything seems to be working. I’ve created a task in PIH Jira to go through and rework all of our module deployments as needed. As part of this task, we are planning on taking a hard look at the existing modules in PIH Github to see if any are general purpose enough that they could/should be moved to OpenMRS Github, and therefore OpenMRS CI. So our plan would be for each module to either:
- Move this module to OpenMRS github, and create a build plan in OpenMRS CI to do the build deploy, or
- Make the change listed to the pom.xml for the module so that the job now deploys to the PIH-specific repos
Generally, I think we should have as much as possible in the main OpenMRS repos so that others in the community are aware of their existence.
If we do this, it’s quite possible that we don’t need a PIH Bintray at all… and if we do, I’d be fine with setting up a PIH account, assuming it’s simple. I quickly took a look at getting an artifactory account for PIH and that seems a little more complicated.
@cintiadr I hope you are keeping well, just checking if you completed making the changes for UgandaEMR modules as we are currently unable to release as before
Thanks in advance
As I mentioned via PM, I’m not being to come here more than once or twice a week. No changes were done to jfrog regarding to that, as far as I’m aware.
@ssmusoke if you are recently having trouble publishing to the Maven repository where you were not having trouble previously, there is an issue around the specific url that some of us have been having trouble with. Try adjusting the distributionManagement section of the poms for the modules that you are trying to publish. For example, I see this in your aijar module:
You’ll want to try changing the one that refers to mavenrepo.openmrs.org to refer to openmrs.frog.io like this:
Give that a try and let us know how it goes…
Thanks @mseaton let us try this out
Thanks @mseaton this is just what the doctor ordered, now the releases are working perfectly, infact may explain lots of failed snapshot updates over the last couple of weeks
I mentioned via PM, but here for others to see: maven newer than 3.3.9 is having that problem with our maven repository. Still to be decided what’s going to be about it, I raised a ticket with maven itself. (yeah, fun and games!)