[jbosstools-issues] [JBoss JIRA] (JBIDE-18742) Decide whether to publish new aggregate by comparating it with last snapshot

[Nick Boldt (JIRA)]

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

Nick Boldt edited comment on JBIDE-18742 at 11/12/14 12:34 PM:
---------------------------------------------------------------

* schedule all 4 aggregate jobs [core, tests, hibernate, webtools] to check at 3 hr intervals (same as we do today for the composite install job)
** if we want, we can implement the "if you failed try again 30 mins later" logic currently in the master branch composite install job [1]
* put p2diff executable (for both x86 and x86_64) in /home/hudson/static_build_env/jbds/ on dev01 server
* store 4 p2diff logs in /logs/ folder [compare w/ previous snapshot, previous staging, previous milestone/development, previous stable/release]

When the above is working, we can:

* deprecate master branch composite install job [1]
* delete master branch composite install site [2]

[1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite-install_master/
[2] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/master/

Added bonus is that for any given published build (snapshot, staging, development, stable) we can see how it compared with its predecessor build. Helpful for QE, I hope.


was (Author: nickboldt):
* schedule all 4 aggregate jobs [core, tests, hibernate, webtools] to check at 3 hr intervals (same as we do today for the composite install job)
** if we want, we can implement the "if you failed try again 30 mins later" logic currently in the master branch composite install job [1]
* put p2diff executable (for both x86 and x86_64) in /home/hudson/static_build_env/jbds/ on dev01 server
* store 4 p2diff logs in /logs/ folder [compare w/ previous snapshot, previous staging, previous milestone/development, previous stable/release]

When the above is working, we can:

* deprecate master branch composite install job [1]
* delete master branch composite install site [2]

[1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite-install_master/
[2] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/master/

> Decide whether to publish new aggregate by comparating it with last snapshot
> ----------------------------------------------------------------------------
>
>                 Key: JBIDE-18742
>                 URL: https://issues.jboss.org/browse/JBIDE-18742
>             Project: Tools (JBoss Tools)
>          Issue Type: Enhancement
>          Components: build
>            Reporter: Mickael Istria
>
> Instead of the composite-install test to decide whether we aggregate or not, it would be simpler to build aggregation in any case and then use p2diff (or other smart mechanism) to decide whether we want to publish the new composite or not.
> It's more or less just a matter of scripting
> {code:none}
> p2diff file:${WORKSPACE}/results/${JOB_NAME}/all/repo/ http://download.jboss.org/jbosstools/builds/staging/${JOB_NAME}/all/repo/ | grep -e ^\< -e ^\> > p2diff_snapshot
> if [[ -s p2diff_snapshot ]]; then
>    ./publish.sh
> fi
> {code}
> Another benefit is that it allows us to get rid of the composite (1 less couple of files to maintain)



--
This message was sent by Atlassian JIRA
(v6.3.8#6338)