Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maven #14

Merged
merged 7 commits into from
Dec 4, 2020
Merged

Maven #14

merged 7 commits into from
Dec 4, 2020

Conversation

jburel
Copy link
Member

@jburel jburel commented Nov 18, 2020

Add template to build using Maven
This has been tested in the BF repo see https://github.com/jburel/bioformats/actions/runs/370615843

Copy link
Member

@sbesson sbesson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One immediate suggestion to add pom.xml to the JSON description.

Tested in a few context of a few repositories.

Other repositories will need extra customizations:

A related question is whether you see the Maven deployment happening as part of this template or in a separate template running on tags like PyPI? For reference, we have 2 strategies depending on the target repository:

  • for OME Artifactory deployment, a deploy phase was following the Travis build phases and running mvn deploy with a secret
  • for OSS Sonatype deployments, the process was carried out manually with the signed GPG key

workflow-templates/maven.properties.json Show resolved Hide resolved
Co-authored-by: Sébastien Besson <seb.besson@gmail.com>
@jburel
Copy link
Member Author

jburel commented Nov 26, 2020

I think we should split the "deployment" step and the "build" from the template.
Some packages e.g. minimal-omero-client do not need the deployment step.

@jburel
Copy link
Member Author

jburel commented Nov 26, 2020

Some repos won't be able to use the template as such. The same is true for the gradle template e.g. https://github.com/ome/omero-blitz

@joshmoore
Copy link
Member

I think we should split the "deployment" step and the "build" from the template.

If the one workflow won't be a single solution, then might be worth renaming. Have we split the two procedures in the other ecosystems as well?

@jburel
Copy link
Member Author

jburel commented Nov 26, 2020

Gradle for example does not have yet any deployment
Publishing to several locations (as we discussed) e.g. artifactory/ sonatype/github. This could make the template a bit convoluted and might not work depending on the actions used. Combining the various locations is more my reasoning for splitting.
The Maven template could have the recommended deployment whatever it is

@sbesson
Copy link
Member

sbesson commented Nov 29, 2020

Summarizing briefly a conversation with @jburel:

  • for Python, the Tox-based workflow is certainly different from the deployment workflow. This is largely motivated by the fact different build targets are used i.e. install vs sdist/bdist_wheel
  • for Maven projects however, the deploy target is at the end of the Maven lifecyle so a separate deployment job would re-execute most of the steps of the build job. From my side both a combined multi-step workflow as well as separate build vs publication workflows are conceivable and have advantages and trade-offs.
  • assuming separate workflows, what would be the name of the publication worklfow? publish_maven? maven_deploy? publish_{artifactory,ossrh}?
  • similar decisions will likely be made for Gradle-based Java projects

@jburel
Copy link
Member Author

jburel commented Dec 1, 2020

One option could be to have a flag at the top of the template indicating the desired deployment target e.g. push artifact to GH
push artifact to artifactory, ossh.

@jburel
Copy link
Member Author

jburel commented Dec 1, 2020

I will list this for review since some repositories that do not need deployment steps could benefit from that template as it is

@jburel
Copy link
Member Author

jburel commented Dec 1, 2020

tested the GH publishing option in ome/omero-downloader#46

Copy link
Member

@sbesson sbesson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Think this is a great start. Understanding this template might be expanded to cover publication release steps - see ome/omero-downloader#46, happy to get this merged it and start apply it to the relevant repositories. The main disadvantage is that it might involve a wave of workflow updates. @joshmoore any concern or additional thoughts?

Copy link
Member

@joshmoore joshmoore left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, none as it stands. I can see getting this in a propagating or trying to get the uploading handled to only need to rollout once.

@sbesson
Copy link
Member

sbesson commented Dec 4, 2020

Understood, immediately I'll start rolling this out to the Maven repositories deployed on OSSRH since there was no equivalent and we still need to investigate this publishing strategy.

@sbesson sbesson merged commit c5b2edb into ome:master Dec 4, 2020
@jburel jburel deleted the maven branch March 22, 2022 10:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants