Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dash-dev] Current promotion strategy for Buckminster Users
Title: Re: [dash-dev] Current promotion strategy for Buckminster Users
OK.  I have the vtp build process back up and running.  That last bit from Dave was the missing piece.  Thank you.  If you’ve missed the talk on the cross project list, it’s been requested that you either link your builds against one of the slaves or unlink it all together and allow it to float if your job will work in that set up.  Here’s a rundown of the things I did to get everything working including publishing an update site:

  1. I linked all the VTP jobs to Slave 2.
  2. I updated the ant script we use to copy the buckminster site.p2 output into a local build directory to not use the old cbi build number structure.  This structure will not be needed by the new publishing script.
  3. The project is set to archive all artifacts in the local build directory.
  4. I modified the recommended ant script to pick up the zip file generated by Hudson for the archived build directory and set it up to run on build.eclipse.org.

Here is the new workspace structure of the vtp nightly build


The results of the site.p2 buckminster action are copied into the build directory here.  A secondary ant build step was added to the job to perform this copy.  The new publish script leverages the lastSuccessfulBuild url of Hudson to get a zip file of all the artifacts in the build directory.  Here’s my changes to the given script:

<?xml version="1.0" encoding="UTF-8"?>
<project name="project" default="publish">
    
    <property name="P2Zip" value="https://hudson.eclipse.org/hudson/job/buckminster-voicetools-nightly/lastSuccessfulBuild/artifact/build/*zip*/build.zip"/>
    <property name="publishDir" value="downloads/technology/vtp/helios"/>

    <!-- =================================
          target: default              
         ================================= -->
    <target name="publish">
        <delete dir="publish" failonerror="false"/>
        
        <mkdir dir="publish"/>
        <get dest="publish/build.zip" src="${P2Zip}" ignoreerrors="no"/>
        <delete dir="build" failonerror="false"/>
        <unzip dest="${basedir}" src="publish/build.zip"/>
        <delete dir="${publishDir}" failonerror="true"/>
        <mkdir dir="${publishDir}"/>
        <copy todir="${publishDir}"
              preservelastmodified="true"
              failonerror="true">
            <fileset dir="build"
                     includes="**/*"/>
        </copy>
    </target>
</project>

Now if someone can tell me how to get buckminster to perform an SVN update during the local resolver materialization step I’d be golden.  Currently I have to wipe the workspace if I want to build off of the latest revision.  I can’t use Hudson’s built in SVN integration because we use multiple component roots in our repository that need to be checked out into the same build directory.

Trip Gilman


On 9/22/10 3:43 PM, "David Carver" <d_a_carver@xxxxxxxxx> wrote:

  You guys can get a ZIP of everything as well:
 
https://hudson.eclipse.org/hudson/view/WTP/job/cbi-wtp-inc-xquery-integration/lastSuccessfulBuild/artifact/sourceediting/development/org.eclipse.wst.xquery.repository/target/site/*zip*/site.zip
 
 You can see an Ant script that does the publishing here:
 
http://git.eclipse.org/c/webtools/org.eclipse.webtools.incubator.git/tree/sourceediting/development/org.eclipse.wst.xquery.releng/publish.xml?h=xquery-dev
 
 Modify as you wish for your own jobs.
 
 Dave
 
 
 That is an example of getting a ZIP file that contais everything that was Archived for the last XQuery milestone we just published to download.eclipse.org.   Once you have the zip, you can
 On 09/22/2010 11:31 AM, Trip Gilman wrote:
Re: [dash-dev] Current promotion strategy for Buckminster Users It appears that the foundation hudson doesn’t have the “trunk” part of the url indicated in the document which was causing the 404s.  The proper url format is:
 
     https://hudson.eclipse.org/hudson/job/[job name]/lastSuccessfulBuild/
 
 >From what I can tell, you can either have the system return you an XML document, a JSON fragment, or executable python code that builds the object structure for python scripts.  So far it looks like the procedure is going to be something like:
 
  
  1. Build finishes in hudson archiving the build artifacts locally and making them available through this remote API
  2. A custom application is triggered via cron tab that accesses this API and retrieves the general build information
  3. The information is processed and the appropriate artifacts are retrieved via HTTP from the hudson server and copied locally
  4. Once the download is verified (not sure how this will be done), the local file is then published to the downloads directory path on the build server for mirroring.


 The application run on build.eclipse.org is going to have to be far more intelligent and capable than earlier ant/bash script incarnations as the information must be parsed from a formatted document.  It will also be more difficult as we’ll need to reproduce the add/remove/update features already present in the original cbi scripts.  Am I missing something that would make this process less complex?  What do you guys think?
 
 Trip
 
 
 On 9/22/10 12:53 PM, "Terran Gilman" <trip@xxxxxxxxxxxxxxx> wrote:
 
  
I’m not sure what the proper approach is here.  I have read the remote access article before.  I have attempted to access that url scheme for some of the projects that appear to have successfully built but always get a 404 for the last successful url.  Even if this is working, is the suggestion to download what resides at that location to build.eclipse.org, and then copy it to the mirrored drive location so it can be copied again to the live download areas?
 
 It took a significant amount of time for me to figure out how to get the provisioning to work after migrating to buckminster.  I guess if I have to re-invest this time so be it, but some other project has to have already figured this out on the new server.  I’d hate to duplicate my previous work and their current work reinventing the wheel.
 
 Trip
 
 
 On 9/22/10 12:46 PM, "Miles Parker" <milesparker@xxxxxxxxx> wrote:
 
  

 Is there a standard approach to this and/or should we come up with one before everyone rolls their own (as we all seem wont to do)? :)
 
 On Sep 22, 2010, at 10:39 AM, Nicolas Bros wrote:
 
  
You can access the archive from the Hudson build using Hudson's REST API :
 http://wiki.hudson-ci.org/display/HUDSON/Remote+access+API
 And then copy it to the downloads area.
 
 On Wed, Sep 22, 2010 at 7:23 PM, Trip Gilman <trip@xxxxxxxxxxxxxxx> wrote:
  
With the new build server being in a separate location from the Hudson server, what is the new process of getting the product of a Hudson build over to the downloads area?
 
 Trip
 
 
 
 On 9/17/10 5:54 PM, "David Carver" <d_a_carver@xxxxxxxxx <http://d_a_carver@xxxxxxxxx/> > wrote:
 
  
  Build.eclipse.org <http://Build.eclipse.org/>  has died....they are building a new build.eclipse.org <http://build.eclipse.org/> , they can make it stronger, they can make it faster, they have the technology.....
  
  http://en.wikipedia.org/wiki/The_Six_Million_Dollar_Man
  
  Dave
  
  On 09/17/2010 02:54 PM, Miles Parker wrote:
  

 
  
  
 Looks like both build servers are down now as well..
  
  
  
 On Sep 17, 2010, at 12:20 PM, David Carver wrote:
  
  
  
 
  build.eclipse.org <http://build.eclipse.org/>  <http://build.eclipse.org <http://build.eclipse.org/> >  is currently down, see cross project message regarding it.
 
  
  Dave
  
  On 09/17/2010 12:03 PM, Miles Parker wrote:
 
 





 
 
  
  
 Excellent..I'm eager to try it out. However..
  
  
  
 On Sep 17, 2010, at 10:34 AM, Trip Gilman wrote:
  
  

 I couldn’t get the actual command as I can’t seem to connecto to build.eclipse.org <http://build.eclipse.org/>  <http://build.eclipse.org/> .  Is it down right now or am I having issues?
  
 
 
 
  
  
 I can't get to it either, but then I'm always having issues.. :)
  
  
  
 
 _______________________________________________
 dash-dev mailing list
 dash-dev@xxxxxxxxxxx <http://dash-dev@xxxxxxxxxxx/>
 https://dev.eclipse.org/mailman/listinfo/dash-dev
  
  






 
  
  _______________________________________________
  dash-dev mailing list
  dash-dev@xxxxxxxxxxx <http://dash-dev@xxxxxxxxxxx/>
  https://dev.eclipse.org/mailman/listinfo/dash-dev
  
 
  
  
  
 
 
 _______________________________________________
 dash-dev mailing list
 dash-dev@xxxxxxxxxxx <http://dash-dev@xxxxxxxxxxx/>
 https://dev.eclipse.org/mailman/listinfo/dash-dev
  
 
 
  
 
_______________________________________________
 dash-dev mailing list
 dash-dev@xxxxxxxxxxx <http://dash-dev@xxxxxxxxxxx/>
 https://dev.eclipse.org/mailman/listinfo/dash-dev
 

 _______________________________________________
 dash-dev mailing list
 dash-dev@xxxxxxxxxxx
 https://dev.eclipse.org/mailman/listinfo/dash-dev
 
 

 
 


 
_______________________________________________
 dash-dev mailing list
 dash-dev@xxxxxxxxxxx
 https://dev.eclipse.org/mailman/listinfo/dash-dev
 



_______________________________________________
dash-dev mailing list
dash-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dash-dev
 

 
_______________________________________________
dash-dev mailing list
dash-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dash-dev

Back to the top