Details
-
Type: Improvement
-
Status: Closed (View Workflow)
-
Priority: Major
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: None
-
Labels:
-
Story Points:2
-
Epic Link:
-
Sprint:Fall 2019 Sprint 1, Fall 2019 Sprint 2, Fall 2019 Sprint 3, Fall 4 : 30 Sep to 11 Oct
Description
Currently, when we deploy a new GenoViz SDK jar to Nexus, we have to build it locally and then run mvn deploy to release the new artifact to the Nexus repository where we are distributing IGB project artifacts.
The release engineer who does this must configure their local computer to include a release engineer user name and password for accepted by the Nexus site.
However, the version of java used and other aspects may vary. It would be better to use a single environment for building the artifact. Also, it would be nice if this could be done from bitbucket pipelines, which uses the same Docker image as IGB and other Java-based projects.
Let's change how this is done!
For this task:
- Configure the POM for Genoviz SDK and bitbucket pipelines YML to release artifacts to Nexus.
In addition, investigate plugins released by Nexus that deploy artifacts.
See:
- https://www.baeldung.com/maven-release-nexus
- https://stackoverflow.com/questions/28071697/is-it-possible-to-pass-a-password-in-maven-deploy-in-the-command-line
Use google to look for additional tips and examples.
Also, investigate other possible improvements, including formalizing the release process using release branches.
Goal: Make this project as professional as possible to encourage developers to use the library in their projects – and hopefully contribute.
Attachments
Issue Links
Activity
Field | Original Value | New Value |
---|---|---|
Epic Link | IGBF-1531 [ 17617 ] |
Rank | Ranked higher |
Description |
Currently, when we deploy a new GenoViz SDK jar to Nexus, we have to build it locally and then run mvn deploy to release the new artifact to the Nexus repository where we are distributing IGB project artifacts.
The release engineer who does this must configure their local computer to include a release engineer user name and password for accepted by the Nexus site. However, the version of java used and other aspects may vary. It would be better to use a single environment for building the artifact. Also, it would be nice if this could be done from bitbucket pipelines, which uses the same Docker image as IGB and other Java-based projects. Let's change how this is done! For this task: * Configure the POM for Genoviz SDK and bitbucket pipelines YML to release artifacts to Nexus. In addition, investigate plugins released by Nexus that deploy artifacts. See: * https://www.baeldung.com/maven-release-nexus Use google to look for additional tips and examples. Also, investigate other possible improvements, including formalizing the release process using release branches. Goal: Make this project as professional as possible to encourage developers to use the library in their projects -- and hopefully contribute. |
Currently, when we deploy a new GenoViz SDK jar to Nexus, we have to build it locally and then run mvn deploy to release the new artifact to the Nexus repository where we are distributing IGB project artifacts.
The release engineer who does this must configure their local computer to include a release engineer user name and password for accepted by the Nexus site. However, the version of java used and other aspects may vary. It would be better to use a single environment for building the artifact. Also, it would be nice if this could be done from bitbucket pipelines, which uses the same Docker image as IGB and other Java-based projects. Let's change how this is done! For this task: * Configure the POM for Genoviz SDK and bitbucket pipelines YML to release artifacts to Nexus. In addition, investigate plugins released by Nexus that deploy artifacts. See: * https://www.baeldung.com/maven-release-nexus * https://stackoverflow.com/questions/28071697/is-it-possible-to-pass-a-password-in-maven-deploy-in-the-command-line Use google to look for additional tips and examples. Also, investigate other possible improvements, including formalizing the release process using release branches. Goal: Make this project as professional as possible to encourage developers to use the library in their projects -- and hopefully contribute. |
Story Points | 1 | 2 |
Workflow | Loraine Lab Workflow [ 18669 ] | Fall 2019 Workflow Update [ 19013 ] |
Sprint | Fall 2019 Sprint 1 [ 72 ] | Fall 2019 Sprint 1, Fall 2019 Sprint 2 [ 72, 73 ] |
Rank | Ranked higher |
Status | Open [ 1 ] | To-Do [ 10305 ] |
Sprint | Fall 2019 Sprint 1, Fall 2019 Sprint 2 [ 72, 73 ] | Fall 2019 Sprint 1, Fall 2019 Sprint 2, Fall 2019 Sprint 4 [ 72, 73, 74 ] |
Rank | Ranked higher |
Assignee | Prutha Kulkarni [ prutha ] |
Status | To-Do [ 10305 ] | In Progress [ 3 ] |
Assignee | Prutha Kulkarni [ prutha ] |
Status | In Progress [ 3 ] | Needs 1st Level Review [ 10005 ] |
Status | Needs 1st Level Review [ 10005 ] | First Level Review in Progress [ 10301 ] |
Status | First Level Review in Progress [ 10301 ] | Ready for Pull Request [ 10304 ] |
Assignee | Prutha Kulkarni [ prutha ] |
Assignee | Prutha Kulkarni [ prutha ] |
Status | Ready for Pull Request [ 10304 ] | Pull Request Submitted [ 10101 ] |
Assignee | Prutha Kulkarni [ prutha ] |
Status | Pull Request Submitted [ 10101 ] | Reviewing Pull Request [ 10303 ] |
Status | Reviewing Pull Request [ 10303 ] | Merged Needs Testing [ 10002 ] |
Assignee | Prutha Kulkarni [ prutha ] |
Status | Merged Needs Testing [ 10002 ] | Post-merge Testing In Progress [ 10003 ] |
Assignee | Ann Loraine [ aloraine ] |
Sprint | Fall 2019 Sprint 1, Fall 2019 Sprint 2, Fall 2019 Sprint 3 [ 72, 73, 74 ] | Fall 2019 Sprint 1, Fall 2019 Sprint 2, Fall 2019 Sprint 3, Fall 2019 Sprint 4 [ 72, 73, 74, 75 ] |
Rank | Ranked higher |
Status | Post-merge Testing In Progress [ 10003 ] | Merged Needs Testing [ 10002 ] |
Status | Merged Needs Testing [ 10002 ] | Post-merge Testing In Progress [ 10003 ] |
Resolution | Done [ 10000 ] | |
Status | Post-merge Testing In Progress [ 10003 ] | Closed [ 6 ] |
Assignee | Ann Loraine [ aloraine ] | Prutha Kulkarni [ prutha ] |
Workflow | Fall 2019 Workflow Update [ 19013 ] | Revised Fall 2019 Workflow Update [ 22462 ] |
To do this task, it looks like we need to re-create the Docker image to enable maven to pick up repository credentials using maven settings.xml. For this, we will need to add credentials in such a way that will allow testing by the person who does this.
This task will require coordination with Dr. Loraine to test the Nexus deployment part. What we will do is grant the developer write access to a test-only repository on our Nexus site.