[jbosstools-issues] [JBoss JIRA] (JBIDE-18742) Only rely on rsync to publish new aggregate (remove other comparators and checks)

[Nick Boldt (JIRA)]

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

Nick Boldt edited comment on JBIDE-18742 at 4/22/15 11:31 AM:
--------------------------------------------------------------

Pushing into a new BUILD folder every time (mars/snapshots/builds/$\{JOB_NAME}/$\{BUILD_ID}-B$\{BUILD_NUMBER}) isn't a reusable publish location. If we disable the check here, then you'll end up with 100s of unneeded folders in /builds/JOB_NAME/. 

You could remove the guard on the second rsync call, if you really wanted... but then you'll get a newer version of the BUILD_NUMBER in the index.html even if the underlying bits haven't changed, AND that could make the version in builds/JOB_NAME/latest/ different from what's in /updates/... thus confusing people.

---

So... my recommendation here is to close this, with the SHA check as the only thing we're still worried about. I don't see the need to add the p2diff check too.

There's nothing wrong with the tiny checkLatestPublishedSHA.sh [1] check here, which diffs buildinfo.json versions to determine if a new publish is warranted.

[1] https://github.com/jbosstools/jbosstools-build-ci/blob/4.3.x/util/checkLatestPublishedSHA.sh


was (Author: nickboldt):
Pushing into a new BUILD folder every time (mars/snapshots/builds/$\{JOB_NAME}/$\{BUILD_ID}-B$\{BUILD_NUMBER}) is NOT lazy. If we disable the check here, then you'll end up with 100s of unneeded folders in /builds/JOB_NAME/. 

You could remove the guard on the second rsync call, if you really wanted... but then you'll get a newer version of the BUILD_NUMBER in the index.html even if the underlying bits haven't changed, AND that could make the version in builds/JOB_NAME/latest/ different from what's in /updates/... thus confusing people.

---

My recommendation here is to close this, with the SHA check as the only thing we're still worried about. I don't see the need to add the p2diff check too.

There's nothing wrong with the tiny checkLatestPublishedSHA.sh [1] check here, which diffs buildinfo.json versions to determine if a new publish is warranted.

[1] https://github.com/jbosstools/jbosstools-build-ci/blob/4.3.x/util/checkLatestPublishedSHA.sh

> 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.15#6346)