Uploaded image for project: 'Tools (JBoss Tools)'
  1. Tools (JBoss Tools)
  2. JBIDE-20904

automate publishing latest CI build to staging, then from staging to development (or stable)

    XMLWordPrintable

Details

    • Enhancement
    • Resolution: Done
    • Major
    • 4.4.3.AM1
    • 4.4.0.Alpha1
    • build
    • None

    Description

      Suggestion:

      rather than opening 10 bash terminals to perform the copy-from-one-place-on-disk-to-local, copy-from-local-to-another-place steps required to clone CI bits to Stage or from Stage to release, mistria@redhat.com and I discovered today that we could use `wait` or `parallel` to orchestrate these steps via a bash script so they run in parallel (as quickly as possible), but still return feedback when all parallel steps are completed.

      So, where today we run these steps sorta-by-hand (copy script into a console and wait until it's done) [1], in future we could simply kick a job and wait for the job to notify its completion.

      [1] https://github.com/jbdevstudio/jbdevstudio-devdoc/tree/master/release_guide/9.x

      Examples of using a series of commands in parallel w/ a wait at the end:

      http://stackoverflow.com/questions/19543139/bash-script-processing-commands-in-parallel

      spawns the 3 parallel steps, waits until #3 is done (2 seconds later) and returns the PID of the last one + its return code
      echo "1" & echo 2 & (sleep 2;echo 3) & wait && echo $! $#
      

      More discussion:

      [12:44:46 PM] Mickael Istria: I believe some parts would have to be turned into functions
      [12:54:41 PM] Mickael Istria: so, to hack the script, it could be just:

      • add && after the 1st rsync in each loop
      • add & after the last one
      • put a wait after the last loop
      • give the big piece of code to procede directly to bash

      After this job is done, releng would still have to "wire up" the new bits by updating composite*.xml and index.html pages, but that's considerably easier to do locally in a terminal, or even to script too. Rather than updating these files w/ sed, we could generate them from a template.

      And if we don't care about committing those changes back to github, we could even push them to the dl.jb.o and ds.jb.c servers directly as part of the above job.

      Scary, but much faster!

      Attachments

        Issue Links

          Activity

            People

              nickboldt Nick Boldt
              nickboldt Nick Boldt
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: