Rob, was this ever resolved ? seems JBIDE-15503 was committed so i'll assume it is ? /max On Thu, Sep 19, 2013 at 03:46:05PM +0200, Snjezana Peco wrote: > Hi, > > Building the server component fails because the required file > http://download.lab.bos.redhat.com/devel/candidates/JBEAP/JBEAP-6.1.0-ER4... > > doesn't exist anymore. > I suppose we would need to replace it with > http://download.devel.redhat.com/released/JBEAP-6/6.1.0/jboss-eap-6.1.0.zip > > or > http://download.devel.redhat.com/released/JBEAP-6/6.1.1/jboss-eap-6.1.1.zip. > > > > Snjeza > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev

Max: https://issues.jboss.org/browse/JBIDE-15503#comment-12807020 N On 09/24/2013 11:37 AM, Rob Stryker wrote: > >Everything built locally so I committed it. Don't think we've seen the >jenkins results yet. > > >On 09/24/2013 11:19 PM, Max Rydahl Andersen wrote: >>Rob, was this ever resolved ? seems JBIDE-15503 was committed so i'll >>assume it is ? >> >>/max >> >>On Thu, Sep 19, 2013 at 03:46:05PM +0200, Snjezana Peco wrote: >>>Hi, >>> >>>Building the server component fails because the required file >>>http://download.lab.bos.redhat.com/devel/candidates/JBEAP/JBEAP-6.1.0-ER4/jboss-eap-6.1.0.ER4.zip >>> >>>doesn't exist anymore. >>>I suppose we would need to replace it with >>>http://download.devel.redhat.com/released/JBEAP-6/6.1.0/jboss-eap-6.1.0.zip >>> >>>or >>>http://download.devel.redhat.com/released/JBEAP-6/6.1.1/jboss-eap-6.1.1.zip. >>> >>> >>> >>>Snjeza >>>_______________________________________________ >>>jbosstools-dev mailing list >>>jbosstools-dev(a)lists.jboss.org >>>https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > >_______________________________________________ >jbosstools-dev mailing list >jbosstools-dev(a)lists.jboss.org >https://lists.jboss.org/mailman/listinfo/jbosstools-dev > -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com

To avoid this conversation in future, I suggest a possible workflow change: 1. push PR or commit 2. push the "build now" button for your component's Jenkins job 3. comment in the JIRA that the fix will be available in a specific build, eg., "Spinning https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-server_41/ >=120 to pick up the fix" This benefits other devs who might be peer-reviewing your code, project/program management who might be overseeing commits for that branch, and QE because it's much easier to know when/where the fix will appear. It also guarantees your fix will be picked up much faster than in 6 hours when the job checks github for changes. Everyone wins, and it only costs you a few dozen keystrokes. WDYT? On 09/24/2013 02:56 PM, Max Rydahl Andersen wrote: > cool - I was just trying to figure out what status was and there was no > followup/comment on the mail thread here. > > Thanks all for replying now :) > > /max > > On Tue, Sep 24, 2013 at 01:50:45PM -0400, Nick Boldt wrote: >> Max: >> >> https://issues.jboss.org/browse/JBIDE-15503#comment-12807020 >> >> N >> >> On 09/24/2013 11:37 AM, Rob Stryker wrote: >>> Everything built locally so I committed it. Don't think we've seen the >>> jenkins results yet. >>> >>> >>> On 09/24/2013 11:19 PM, Max Rydahl Andersen wrote: >>>> Rob, was this ever resolved ? seems JBIDE-15503 was committed so i'll >>>> assume it is ? >>>> >>>> /max >>>> >>>> On Thu, Sep 19, 2013 at 03:46:05PM +0200, Snjezana Peco wrote: >>>>> Hi, >>>>> >>>>> Building the server component fails because the required file >>>>> http://download.lab.bos.redhat.com/devel/candidates/JBEAP/JBEAP-6.1.0-ER4... >>>>> >>>>> >>>>> doesn't exist anymore. >>>>> I suppose we would need to replace it with >>>>> http://download.devel.redhat.com/released/JBEAP-6/6.1.0/jboss-eap-6.1.0.zip >>>>> >>>>> >>>>> or >>>>> http://download.devel.redhat.com/released/JBEAP-6/6.1.1/jboss-eap-6.1.1.zip. >>>>> >>>>> >>>>> >>>>> >>>>> Snjeza >>>>> _______________________________________________ >>>>> jbosstools-dev mailing list >>>>> jbosstools-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>> >>> _______________________________________________ >>> jbosstools-dev mailing list >>> jbosstools-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>> >> -- >> Nick Boldt :: JBoss by Red Hat >> Productization Lead :: JBoss Tools & Dev Studio >> http://nick.divbyzero.com

On 09/24/2013 09:47 PM, Denis Golovin wrote: >1. More jenkins builds We already have many jobs on Jenkins and the reactivity is not always very good. Adding 30 to 40 more jobs will not make it better. Despite of that, there is nothing preventing us from doing this. Please open a Jira.

>2. Have no Idea how to deal with PR's related to each other for >different components

It's concretely impossible to make sure a PR 123 of server builds against what was suggested in PR 57 of base, for the following reason: * PR123 has no knowledge that it depends on another PR from another component. So there is no way to automatically choose a specific build output for another component. * Job triggering is not deterministic since it depends on availability of slaves, number of pull requests in the pipe, job duration... So we can't rely on assumptions such as "PR were pushed at the same time, so they'll build fine".

So in that case of linked PR, the output of automated build for PR suggested above would be: green for PR57, red for PR123. The process would be to merge PR57 first, build it with the regular job, and then re-run build for PR123.

On 25/09/2013, at 11.53, Nick Boldt <nboldt(a)redhat.com&gt; wrote: Sounds reasonable in theory, but not all our jobs do the same thing. Consider these 9 different templates: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-build.par... https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstoolstargetplat... https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-server_ma... (this template is reused for 15 or so component jobs, each which different scheduled github checks to ensure that jobs will (in theory) fire in the correct sequence rather than all at once) https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite... https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-build-sit... (this template is reused for building the webtools agg site and the coretests agg site, but each one has different upstream/downstream linkages) https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/devstudio.product_ma... https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/devstudio.versionwat... https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-discovery... https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-install-g... When it's time to update all the jobs to pull from Alpha2x branch instead of Alpha1x branch, sure, you could regenerate the 15 component jobs but you'd still have to go find+replace strings in the other 10 jobs' config.xml files, and push those to the server. And if you have to find+replace for 10 jobs, why not do it for all 25, rather than having 2/3rds generated and 1/3rd manually updated? --- That said, it might be possible to parameterize a job to be able to push in a value of "fork" and "branch" so that rather than always building the job from jbosstools/jbosstools-<project> from origin/master or origin/jbosstools-4.1.1.Alpha2x, you could instead pass in fork=maxandersen&branch=origin/JBIDE-12345, which would run the job in an override mode to build using your fork and topic branch. Then of course we'd need a third parameter to define where to put this forked build results so it wouldn't conflict w/ the main composite site & downstream aggregate assemblies. So instead of the usual /builds/staging/CI/JOB_NAME/BUILD_ID/ we might instead publish to /builds/staging/forks/JOB_NAME/BUILD_ID_gituser_branch We could then run the new composite*.xml generator I've started here [1] to composite your forks into the larger CI composite, in order to test assembly and installation. [1] https://issues.jboss.org/browse/JBIDE-15483, https://issues.jboss.org/browse/JBIDE-15482 WDYT? Crazytalk? Reasonable? N > On 09/25/2013 02:20 PM, Max Rydahl Andersen wrote: >> On Wed, Sep 25, 2013 at 08:30:44AM +0200, Mickael Istria wrote: >>> On 09/24/2013 09:47 PM, Denis Golovin wrote: >>> 1. More jenkins builds >> We already have many jobs on Jenkins and the reactivity is not always >> very good. Adding 30 to 40 more jobs will not make it better. >> Despite of that, there is nothing preventing us from doing this. >> Please open a Jira. > > I really would like to see us use something like https://github.com/maxandersen/buildchow > or maybe even the literatebuild approach http://jenkins-ci.org/content/literate-builds-wtf which > would allow for defining builds more 'declaratively' and easier to handle branches and allow > one to reproduce our jenkins build setup locally and not be 117% tied to our > jenkins instances. > > The number of jobs currently handedited or search/replaced and then sometimes edited on the server > is making it very hard to share/move around to do things ike this "test run a PR". > >>> 2. Have no Idea how to deal with PR's related to each other for >>> different components > > Basically these just won't be able to do with this approach imo. > But how many jobs do you actually have that needs this ? > >> It's concretely impossible to make sure a PR 123 of server builds >> against what was suggested in PR 57 of base, for the following reason: >> * PR123 has no knowledge that it depends on another PR from another >> component. So there is no way to automatically choose a specific build >> output for another component. >> * Job triggering is not deterministic since it depends on availability >> of slaves, number of pull requests in the pipe, job duration... So we >> can't rely on assumptions such as "PR were pushed at the same time, so >> they'll build fine". > > Even you could be deterministic - the jobs using a PR should not be publsihing > their result anywhere for downstream usage since it has been merged in yet. > >> So in that case of linked PR, the output of automated build for PR >> suggested above would be: green for PR57, red for PR123. The process >> would be to merge PR57 first, build it with the regular job, and then >> re-run build for PR123. > > yes. > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com

On 24/09/2013, at 12.33, Nick Boldt <nboldt(a)redhat.com&gt; wrote: To avoid this conversation in future, I suggest a possible workflow change: 1. push PR or commit 2. push the "build now" button for your component's Jenkins job 3. comment in the JIRA that the fix will be available in a specific build, eg., "Spinning https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-server_41/ >=120 to pick up the fix" This benefits other devs who might be peer-reviewing your code, project/program management who might be overseeing commits for that branch, and QE because it's much easier to know when/where the fix will appear. It also guarantees your fix will be picked up much faster than in 6 hours when the job checks github for changes. Everyone wins, and it only costs you a few dozen keystrokes. WDYT? > On 09/24/2013 02:56 PM, Max Rydahl Andersen wrote: > cool - I was just trying to figure out what status was and there was no > followup/comment on the mail thread here. > > Thanks all for replying now :) > > /max > >> On Tue, Sep 24, 2013 at 01:50:45PM -0400, Nick Boldt wrote: >> Max: >> >> https://issues.jboss.org/browse/#comment-12807020 >> >> N >> >>> On 09/24/2013 11:37 AM, Rob Stryker wrote: >>> >>> Everything built locally so I committed it. Don't think we've seen the >>> jenkins results yet. >>> >>> >>>> On 09/24/2013 11:19 PM, Max Rydahl Andersen wrote: >>>> Rob, was this ever resolved ? seems JBIDE-15503 was committed so i'll >>>> assume it is ? >>>> >>>> /max >>>> >>>>> On Thu, Sep 19, 2013 at 03:46:05PM +0200, Snjezana Peco wrote: >>>>> Hi, >>>>> >>>>> Building the server component fails because the required file >>>>> http://download.lab.bos.redhat.com/devel/candidates/JBEAP/JBEAP-6.1.0-ER4... >>>>> >>>>> >>>>> doesn't exist anymore. >>>>> I suppose we would need to replace it with >>>>> http://download.devel.redhat.com/released/JBEAP-6/6.1.0/jboss-eap-6.1.0.zip >>>>> >>>>> >>>>> or >>>>> http://download.devel.redhat.com/released/JBEAP-6/6.1.1/jboss-eap-6.1.1.zip. >>>>> >>>>> >>>>> >>>>> >>>>> Snjeza >>>>> _______________________________________________ >>>>> jbosstools-dev mailing list >>>>> jbosstools-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>> >>> >>> _______________________________________________ >>> jbosstools-dev mailing list >>> jbosstools-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> >> -- >> Nick Boldt :: JBoss by Red Hat >> Productization Lead :: JBoss Tools & Dev Studio >> http://nick.divbyzero.com -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com