[jbosstools-issues] [JBoss JIRA] (JBIDE-23768) Publish tagged version of jboss tools parent pom to public repository

[Nick Boldt (JIRA)]

    [ https://issues.jboss.org/browse/JBIDE-23768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13371053#comment-13371053 ] 

Nick Boldt edited comment on JBIDE-23768 at 3/1/17 11:14 AM:
-------------------------------------------------------------

Yes, you're right. Missed the last step.
This means that the script I send Jeff to do branching has to happen BEFORE the branch update & parent pom release; THEN when that's done we can send out the SECOND script to update root poms.

Sucks to have to have a manual human process in the middle of two mostly-automated ones. Will have to think about how we can make the parent pom commits generated & pushed to github automatically...

* branch jbosstools-build (4.4.4.x and later again for 4.5.0.x); send email to Jeff w/ instructions for batch creation of jbosstools-* projects' branches
* update parent pom to use correct "stable branch" settings [1] & update version (remove -SNAPSHOT) [2] *could this be done by Jenkins job in future?*
* trigger build which will now auto-release it to Nexus [3] *could this be triggered automatically via upstream job in future?*
* send email to Jeff w/ instructions for batch changes to jbosstools-* projects' root poms (point to non-SNAPSHOT version of parent pom)

Maybe a build pipeline would work for this, with a blocking step #2 until we can replace it with a script. 

[~jeffmaury] would you be OK if the devstudio-release machine user [4] had push rights to the parent pom in jbosstools-build [5]? 

[4] https://github.com/devstudio-release
[5] https://github.com/jbosstools/jbosstools-build


was (Author: nickboldt):
Yes, you're right. Missed the last step.
This means that the script I send Jeff to do branching has to happen BEFORE the branch update & parent pom release; THEN when that's done we can send out the SECOND script to update root poms.

Sucks to have to have a manual human process in the middle of two mostly-automated ones. Will have to think about how we can make the parent pom commits generated & pushed to github automatically...

* branch jbosstools-build (4.4.4.x and later again for 4.5.0.x); send email to Jeff w/ instructions for batch creation of jbosstools-* projects' branches
* update parent pom to use correct "stable branch" settings [1] & update version (remove -SNAPSHOT) [2] *could this be done by Jenkins job in future?*
* trigger build which will now auto-release it to Nexus [3] *could this be triggered automatically via upstream job in future?*
* send email to Jeff w/ instructions for batch changes to jbosstools-* projects' root poms (point to non-SNAPSHOT version of parent pom)

Maybe a build pipeline would work for this, with a blocking step #2 until we can replace it with a script. 

[~jeffmaury] would you be OK if the devstudio-release machine user had push rights to the parent pom in jbosstools-build? 


> Publish tagged version of jboss tools parent pom to public repository
> ---------------------------------------------------------------------
>
>                 Key: JBIDE-23768
>                 URL: https://issues.jboss.org/browse/JBIDE-23768
>             Project: Tools (JBoss Tools)
>          Issue Type: Task
>          Components: build
>    Affects Versions: 4.4.2.Final, 4.4.3.AM1
>            Reporter: Aurélien Pupier
>            Assignee: Nick Boldt
>              Labels: releasework
>             Fix For: 4.4.3.Final
>
>
> it will allow Fuse Tooling (and other dependent projects) to have tagged version of their parent pom for tagged release.
> i'm talking about org.jboss.tools:parent



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)