[JBoss JIRA] (JBIDE-19598) Use "Build other project (extended)" to cascade aggregation
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19598?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-19598:
------------------------------------
So with this change any of the 17 builds would trigger a rebuild of the JBT core & coretests aggregates. But today, we can collect changes into fewer respins using the composite site job (which spins at intervals rather than for EVERY upstream commit).
The composite job ALSO does an install test to verify that everything can be installed into the current version of Eclipse. That job has been failing since we moved the target platform to use Eclipse Mars R (RC4/SR0) because it was using RC2 to do the install. (I fixed that yesterday and the job's back to blue/yellow.)
So... that's a GOOD thing. It caught the fact that we can't install JBT 4.3.0.Beta2-SNAPSHOT bits onto RC2 because of the incompatible target platforms (p2 director installs can't do remediation). Losing this test, IMHO, would be bad. The overhead/maintenance is minimal.
Causing many more aggregate builds to fire doesn't seem like a good thing. Why do we want to go back to something we specifically STOPPED doing a few years ago?
--
Today, we run all the project builds based on SCM change, then fire the aggregates based on a composite site build. When we want to build the whole stack, we use a buildflow job.
This achieves a balance of:
* fairly frequent aggregate respins (every 3 hours, with re-checks every 30 mins if the attempt to build failed due to missing content)
* light Jenkins slave load (composite job is faster and eats less time/disk space than 2 aggregate builds, which also have to suck down source zips from Github)
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS...
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS...
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS...
We used to have a cascade of jobs, linked together in their logical build order, then fired the aggregates based on a composite site build. We removed the inter-job linking to make maintenance easier (this was replaced by a buildflow job in 7.0).
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt...
Before that, we had all the jobs cause aggregates to fire (using a cascade of jobs, linked together in their logical build order). This was better than the old way, but harder to maintain as component job deps changed (more things depending on Base or Server, for example). So for 6.0 I added the composite install job.
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt...
Before that, we had all the projects firing the aggregate in no particular order, with no inter-job linking. This caused build failures and ate a lot of slave resources.
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt...
---
I guess my question, ultimately, is "what are we trying to solve by switching to a new model of job aggregation?"
This JIRA doesn't actually state the problem we're trying to fix; it only says "we could use this plugin to remove the need for 1 job". Is the job so bad that its maintenance burden behooves its removal?
> Use "Build other project (extended)" to cascade aggregation
> -----------------------------------------------------------
>
> Key: JBIDE-19598
> URL: https://issues.jboss.org/browse/JBIDE-19598
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Affects Versions: 4.3.0.Alpha2
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Priority: Minor
> Fix For: 4.3.0.Beta2
>
>
> In order to decide whether to cascade aggregation when components are build, we could use the "Build other project (extended)" plugin in order to trigger 2 aggregate jobs (site, coretests-site) when component has SCM changes.
> This would require changing all 17 component jobs (per stream = 34 jobs), but would eliminate the need for the composite-install test jobs [1].
> [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (JBIDE-20100) how to make users aware of fuse and other tooling only being available from earlyaccess?
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20100?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-20100:
----------------------------------------
1) currently, we only have one connector existing in regular and early-access, so the result would be the same list as when Early-Access is enabled, +1 (the regular version of this connector). No bug change for a big benefit that early-access content is visible immediately.
2) In that case. I don't see how adding "connectors" to show that Fuse & others currently don't work with JBT/JBDS is helpful for users. Note that the user-story in the description doesn't mention at all the need for "advertising connector".
> how to make users aware of fuse and other tooling only being available from earlyaccess?
> -----------------------------------------------------------------------------------------
>
> Key: JBIDE-20100
> URL: https://issues.jboss.org/browse/JBIDE-20100
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: central
> Reporter: Max Rydahl Andersen
> Assignee: Mickael Istria
>
> [~jtyrrell] find it confusing when he cannot see Fuse and other earlyaccess features immediately on the install page.
> Some comments:
> "I install JBDS 8.1 and click on the JBoss Integration and SOA Development, but where is the Fuse tooling in that list."
> "<without earlyaccess> why doesn’t my screen shot tell me to use an older version of JBDS or something."
> Suggestion:
> "when I picked the Integration Stack a greyed out Fuse IDE thingy in the list of choices, and something like (Select early Access) to enable this feature."
> I'm fine exploring options to show early access features more prominently but would prefer we would not need to treat Fuse "special" so maybe we should have a "Early Access" section at the bottom instead of filtered in between everything else ?
> and for any connectors that has additional/different features just add a "Extra features available in Early access " comment ?
> But what to do when Fuse or others dont even have an earlyaccess out yet ? (like is currently the state for devstudio 9)
> [~crobson], [~aileenc] and [~lhein] got any suggestions ?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (JBIDE-15388) Compute whether to publish or not based on output signature rather than commits
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15388?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-15388:
------------------------------------
We kind of already have this now as a shell wrapper to call maven deploy. Suggestion to migrate it to mojo in JBIDE-20177
> Compute whether to publish or not based on output signature rather than commits
> -------------------------------------------------------------------------------
>
> Key: JBIDE-15388
> URL: https://issues.jboss.org/browse/JBIDE-15388
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Priority: Minor
> Fix For: LATER
>
>
> [Assuming we already have reproducible qualifiers...]
> Currently, the CI jobs publish the output of a build if a change was detected in the Git repo since last publication.
> However there are some case not correctly supported:
> * Job configuration changed and caused changes in build output. In that case, we would like build output to be re-published, but it won't happen
> * Job source changed but not build output (eg a change in a pom.xml or any non-included file), then we don't need to republish output whereas current mechanism would republish it.
> instead, it would make sense to compare what's already published and what is to publish in order to decide or not whether this has to be published. Looking at signatures of update site zip would probably be enough.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months