[JBoss JIRA] (JBIDE-19132) For JBIDE 4.2.3.Beta1: Prepare for JBT 4.2.3 / JBDS 8.1.0 [OpenShift]
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19132?page=com.atlassian.jira.plugi... ]
Andre Dietisheim resolved JBIDE-19132.
--------------------------------------
Resolution: Done
re-closing
> For JBIDE 4.2.3.Beta1: Prepare for JBT 4.2.3 / JBDS 8.1.0 [OpenShift]
> ---------------------------------------------------------------------
>
> Key: JBIDE-19132
> URL: https://issues.jboss.org/browse/JBIDE-19132
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: openshift
> Reporter: Nick Boldt
> Assignee: Andre Dietisheim
> Priority: Blocker
> Labels: task
> Fix For: 4.2.3.Beta1
>
>
> For JBIDE 4.2.3.Beta1 [OpenShift]: Please perform the following tasks:
> 1. Ensure your component features/plugins have been [properly upversioned|http://wiki.eclipse.org/Version_Numbering#Overall_example], eg., from 1.0.1 to 1.0.2 or from 1.0.2 to 1.0.3.
> Please also ensure that the version of your plugins in the master (4.3.x) branch is a LARGER version, to prevent a user from accidentally updating from your Mars version to your Luna version. For example, org.jboss.tools.stacks.core cannot be version 1.1.1 in JBDS 8.0.2, and 1.1.0 in JBDS 9.
> {code}
> mvn -Dtycho.mode=maven org.eclipse.tycho:tycho-versions-plugin:0.22.0:set-version -DnewVersion=4.3.0-SNAPSHOT
> {code}
> 2. In the *{color:blue}jbosstools-4.2.x{color}* branch, update your root pom to use parent pom version *{color:blue}4.2.3.Beta1-SNAPSHOT{color}*
> {code}
> <parent>
> <groupId>org.jboss.tools</groupId>
> <artifactId>parent</artifactId>
> <version>4.2.3.Beta1-SNAPSHOT</version>
> </parent>
> {code}
> 3. Ensure you've built & run your plugin tests using the latest target platform version:
> {code}
> mvn clean verify -Dtpc.version=4.42.0.Beta1-SNAPSHOT
> {code}
> 4. Close (do not resolve) this JIRA when done.
> [Search for all task JIRA|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+and...], or [Search for OpenShift task JIRA|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+and...]
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-18772) Include publish.sh in parent pom as versioned maven dependency
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18772?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-18772:
---------------------------------------------
I really really like the idea of mvn deploy being nothing but the rsync call. But I understand we so far do much more in rsync.sh, but let me try and see which are *Actually* needed.
* ensure that the full target path actually exists before trying to rsync there
Could that not be solved by using one of the tips suggested here: http://stackoverflow.com/a/22908437/71208
'rsync -a --relative ${JOB_NAME}/${BUILD_ID}-B${BUILD_NUMBER}/all/repo/ user@remote:/jbosstools/updates/mars/snapshots/builds'
meaning it will fail if the snapshots/builds dir does not exist (which seems like a *good* thing that it will fail) and it will create the --relative part.
* create a symlink from this latest ${JOB_NAME}/${BUILD_ID}-B${BUILD_NUMBER} folder to ${JOB_NAME}/latest/
* create a composite site in ${JOB_NAME}/ of all the */all/repo/ folders, and purge old published folders older than 2 days old
This to me sounds like a thing that could be called when the jenkins jobs are done and kept outside of the responsibility of the component pom's ?
* create a copy of the build log in the ${JOB_NAME}/${BUILD_ID}-B${BUILD_NUMBER}/logs/ folder
is this one really needed ? could it be done in the separate job from above ?
* create a link to the published content from within the Jenkins job's BUILD_DESCRIPTION [not required but nice to have]
That seems like the wrong place to have it anyway the job itself would know where it is anyway since it passes in all the subpieces of the url.
The advantage of splitting this up is that the pom.xml in the project can deploy to anywhere - without having full magic system access to its destination - leaving the 'log file cleanup/syncing' etc. to a a jenkins job outside of the component build.
This seems to be a better split of tasks/responsibilities IMO.
WDYT ?
> Include publish.sh in parent pom as versioned maven dependency
> --------------------------------------------------------------
>
> Key: JBIDE-18772
> URL: https://issues.jboss.org/browse/JBIDE-18772
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Reporter: Max Rydahl Andersen
> Assignee: Mickael Istria
> Fix For: 4.3.0.Alpha2
>
>
> instead of relying to publish.sh being on master, we should use a versioned publish.sh (or maybe even mojo) that the build then uses.
> suggestion:
> publish.sh (or mojo) gets released to our maven repo, use it in the pom.xml to perform publishing.
> What this helps with is:
> a) can do changes to publish mechanism without affecting every past builds.
> b) more movable build system
> c) isolated testing possible
>
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-18772) Include publish.sh in parent pom as versioned maven dependency
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18772?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-18772:
----------------------------------------
{quote}Alternatively, we could start rewriting rsync.sh as some-kinda-deployment-mojo and jbosstools-cleanup.sh as some-kinda-cleanup-mojo. More work but ultimately way more portable.{quote}
Yes. Let's just try to consume the scripts from pom.xml for now, and once they're working, a next iteration would be to turn them into mojos.
> Include publish.sh in parent pom as versioned maven dependency
> --------------------------------------------------------------
>
> Key: JBIDE-18772
> URL: https://issues.jboss.org/browse/JBIDE-18772
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Reporter: Max Rydahl Andersen
> Assignee: Mickael Istria
> Fix For: 4.3.0.Alpha2
>
>
> instead of relying to publish.sh being on master, we should use a versioned publish.sh (or maybe even mojo) that the build then uses.
> suggestion:
> publish.sh (or mojo) gets released to our maven repo, use it in the pom.xml to perform publishing.
> What this helps with is:
> a) can do changes to publish mechanism without affecting every past builds.
> b) more movable build system
> c) isolated testing possible
>
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years