[
https://issues.jboss.org/browse/JBIDE-18742?page=com.atlassian.jira.plugi...
]
Nick Boldt commented on JBIDE-18742:
------------------------------------
We need to ensure that the 5 aggregate sites (3 jobs per stream) do a DESTRUCTIVE publish
(that is, no plugin/feature jars from previously published update site should be left
over).
Also, since rsync.sh now pushes to a numbered folder [1] each time... will this even work?
I mean, sure, we can do a destructive push (with --delete) into [2] (not using rsync.sh -
just using raw ` rsync --delete /path/to/sources/ /path/to/someupdatesite/site-stream/ `),
but that won't work for [1].
[1]
http://download.jboss.org/jbosstools/mars/snapshots/builds/jbosstools-bui...
[2]
http://download.jboss.org/jbosstools/mars/snapshots/updates/earlyaccess/m...
Only rely on rsync to publish new aggregate (remove other comparators
and checks)
---------------------------------------------------------------------------------
Key: JBIDE-18742
URL:
https://issues.jboss.org/browse/JBIDE-18742
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: build
Reporter: Mickael Istria
Assignee: Mickael Istria
Fix For: 4.3.0.Beta1
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.11#6341)