David,
Thanks for the explanation and for the refresh of the staging repository. I was able to complete my verification. - Konstantin From: [email protected] [mailto:[email protected]] On Behalf Of David M Williams Sent: Wednesday, September 19, 2012 7:55 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] How to test that a simrel repository has a project's final contribution? > Is the current process to request an update of the staging repository? Yes. (I try to keep up as we near the end ... but admit I've been distracted since 5:30 AM) > Would it be possible to modify the aggregator job to archive the result of > aggregation? Yes. But its more than changing a Hudson job configuration since current aggregation build writes to /shared/simrel area, not to Hudson's "workspace". There's several historical reasons for that and I've always wanted to investigate alternatives, but has never reached high enough in my priority list. You could "manually" search through the logs in "old" builds, if it was just repo URLs and bundle versions you were looking to verify. Thanks, From: "Konstantin Komissarchik" <[email protected]> To: "'Cross project issues'" <[email protected]>, Date: 09/19/2012 09:47 AM Subject: [cross-project-issues-dev] How to test that a simrel repository has a project's final contribution? Sent by: [email protected] _____ I am trying to figure what process a project should employ to validate that an about-to-be-released simrel repository indeed contains project’s final contribution. For instance, I am trying to verify Sapphire’s contribution to Juno SR1 before aggregation locks down for the quiet week later today. On Hudson, I see the relevant commit has cleared through the aggregator job [1], but the Hudson job does not archive its result, so I cannot check it there. The listed staging repository URL [2] appears to be manually updated and doesn’t include the change in question. Suggestions? Is the current process to request an update of the staging repository? Would it be possible to modify the aggregator job to archive the result of aggregation? The retention of bits can be configured to one or two runs to keep disk usage down. If we had this, one could always access the latest aggregator result from Hudson [3] and there wouldn’t be a need to manually maintain the current staging repositories. - Konstantin [1] <https://hudson.eclipse.org/hudson/job/simrel.juno.runAggregator/> https://hudson.eclipse.org/hudson/job/simrel.juno.runAggregator/ [2] <http://download.eclipse.org/releases/maintenance/> http://download.eclipse.org/releases/maintenance/ [3] <https://hudson.eclipse.org/hudson/job/simrel.juno.runAggregator/lastSuccessfulBuild/artifact/repository> https://hudson.eclipse.org/hudson/job/simrel.juno.runAggregator/lastSuccessfulBuild/artifact/repository _______________________________________________ cross-project-issues-dev mailing list [email protected] <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
