[JBoss JIRA] (JBIDE-20904) create single bash script (and Jenkins job wrapper) to perform the first 10 steps of CI -> stage or stage -> development/stable
by Nick Boldt (JIRA)
Nick Boldt created JBIDE-20904:
----------------------------------
Summary: create single bash script (and Jenkins job wrapper) to perform the first 10 steps of CI -> stage or stage -> development/stable
Key: JBIDE-20904
URL: https://issues.jboss.org/browse/JBIDE-20904
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: build
Affects Versions: 4.4.0.Alpha1
Reporter: Nick Boldt
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, [~mickael_istria] 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_gui...
Examples of using a series of commands in parallel w/ a wait at the end:
http://stackoverflow.com/questions/19543139/bash-script-processing-comman...
{code:title=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 $! $#
{code}
More discussion:
{quote}
[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
{quote}
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!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (JBIDE-20904) create single bash script (and Jenkins job wrapper) to perform the first 10 steps of CI -> stage or stage -> development/stable
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20904?page=com.atlassian.jira.plugi... ]
Nick Boldt reassigned JBIDE-20904:
----------------------------------
Assignee: Nick Boldt
> create single bash script (and Jenkins job wrapper) to perform the first 10 steps of CI -> stage or stage -> development/stable
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-20904
> URL: https://issues.jboss.org/browse/JBIDE-20904
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.4.0.Alpha1
>
>
> 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, [~mickael_istria] 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_gui...
> Examples of using a series of commands in parallel w/ a wait at the end:
> http://stackoverflow.com/questions/19543139/bash-script-processing-comman...
> {code:title=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 $! $#
> {code}
> More discussion:
> {quote}
> [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
> {quote}
> 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!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (JBIDE-20904) create single bash script (and Jenkins job wrapper) to perform the first 10 steps of CI -> stage or stage -> development/stable
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20904?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-20904:
-------------------------------
Fix Version/s: 4.4.0.Alpha1
> create single bash script (and Jenkins job wrapper) to perform the first 10 steps of CI -> stage or stage -> development/stable
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-20904
> URL: https://issues.jboss.org/browse/JBIDE-20904
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.4.0.Alpha1
>
>
> 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, [~mickael_istria] 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_gui...
> Examples of using a series of commands in parallel w/ a wait at the end:
> http://stackoverflow.com/questions/19543139/bash-script-processing-comman...
> {code:title=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 $! $#
> {code}
> More discussion:
> {quote}
> [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
> {quote}
> 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!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (JBIDE-19729) Version Auditing
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19729?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-19729:
-------------------------------
Fix Version/s: 4.4.0.Final
(was: 4.3.0.Final)
> Version Auditing
> ----------------
>
> Key: JBIDE-19729
> URL: https://issues.jboss.org/browse/JBIDE-19729
> Project: Tools (JBoss Tools)
> Issue Type: Epic
> Components: build
> Affects Versions: 4.3.0.Alpha2
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.4.0.Final
>
>
> Epic to track issues related to auditing and quality control.
> This may include tools & workflows to ensure we're not building the wrong stuff, including too much (or incompatible versions) in target platforms, forgetting to upversion components, etc.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (JBIDE-20903) Need to split org.jboss.tools.jst.js to *.node and *.bower
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20903?page=com.atlassian.jira.plugi... ]
Ilya Buziuk updated JBIDE-20903:
--------------------------------
Description:
After some npm investigation I can claim that npm support covered in the issue description can be implemented pretty easily. However, in order to make the implementation generic I do believe that *org.jboss.tools.jst.js* plugin must be refactored. My proposal is to split it to:
* *org.jboss.tools.jst.js.node* (plugin with generic node tools launch, which will be subclassed for bower, npm etc. Node preferences + some utilities)
* *org.jsboss.tools.jst.js.bower* (bower specific stuff, will have org.jboss.tools.jst.js.node as required bundle )
it will simplify the implementation of not only npm but also other node dependent tools (grunt, gulp etc.).
> Need to split org.jboss.tools.jst.js to *.node and *.bower
> ----------------------------------------------------------
>
> Key: JBIDE-20903
> URL: https://issues.jboss.org/browse/JBIDE-20903
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: javascript, javascript-bower
> Affects Versions: 4.3.0.CR1
> Reporter: Ilya Buziuk
> Assignee: Ilya Buziuk
> Fix For: 4.4.0.Alpha1
>
>
> After some npm investigation I can claim that npm support covered in the issue description can be implemented pretty easily. However, in order to make the implementation generic I do believe that *org.jboss.tools.jst.js* plugin must be refactored. My proposal is to split it to:
> * *org.jboss.tools.jst.js.node* (plugin with generic node tools launch, which will be subclassed for bower, npm etc. Node preferences + some utilities)
> * *org.jsboss.tools.jst.js.bower* (bower specific stuff, will have org.jboss.tools.jst.js.node as required bundle )
> it will simplify the implementation of not only npm but also other node dependent tools (grunt, gulp etc.).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months