[
https://issues.jboss.org/browse/JBIDE-18742?page=com.atlassian.jira.plugi...
]
Nick Boldt commented on JBIDE-18742:
------------------------------------
What if we did this?
== STEP ONE: SHA CHECK ==
1. wget
http://download.jboss.org/jbosstools/builds/staging/*JOB_NAME*/all/repo/b...
2. parse file and look for
{code}
"revision" : {
"HEAD" : "05dd8cf40ef91400d407d5441fb6e56a7333c645",
{code}
3. diff with *WORKSPACE*/sources/site/target/repository/buildinfo.json
4. if different, call rsync.sh; if not, proceed to step 2
== STEP TWO: P2DIFF CHECK ==
5. Run p2diff to check if the destination site's metadata/contents are different (ie.,
built from same SHA but because it's an aggregator, contents may differ)
6. if different, call rsync.sh; if not, echo into log something like this (see publish.sh
for actual code){code}
BUILD_DESCRIPTION = "Destination built from same SHA; not republishing"{code}
Only rely on rsync to publish new aggregate (remove other
comparators)
----------------------------------------------------------------------
Key: JBIDE-18742
URL:
https://issues.jboss.org/browse/JBIDE-18742
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: build
Reporter: Mickael Istria
Assignee: Nick Boldt
Fix For: 4.3.0.Alpha2
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)