[JBoss JIRA] (JBIDE-16970) create mechanism to verify that nightly build is different from previous milestone
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16970?page=com.atlassian.jira.plugi... ]
Nick Boldt closed JBIDE-16970.
------------------------------
Fix Version/s: 4.3.1.Beta1
4.4.0.Alpha1
(was: 4.3.x)
Resolution: Done
Appears to be working and too onerous for QE to verify (requires reading lots of build logs and comparing the output to github to check for changes), so closing.
I won't add p2diff to the component site builds because by definition those IUs are different for every build (new timestamp, new BUILD_NUMBER). Sure, we could filter all that out and just check for 3rd party IU changes (eg., angular and tern in the JST builds) but that would ALSO be caught by the SHA check, so the extra level achieves nothing.
> create mechanism to verify that nightly build is different from previous milestone
> ----------------------------------------------------------------------------------
>
> Key: JBIDE-16970
> URL: https://issues.jboss.org/browse/JBIDE-16970
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Affects Versions: 4.2.0.Beta1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.3.1.Beta1, 4.4.0.Alpha1
>
>
> After the discovery site build job is done, we should:
> * get a list of JIRAs for a given target fixversion, eg., 4.2.0.Beta1 or 8.0.0.Beta1 *job param* milestone = Beta1, Beta2, CR1, Final/GA (special case)
> * for respins, use *job param* label = "respin-a" or "respin-b" in jira query
> * filter query to only show the components and map those to actual project names - see https://github.com/jbdevstudio/jbdevstudio-ci/blob/master/bin/createTaskJ... for mappings
> * install Eclipse from *job param* eclipseBundleVersion = luna.M6
> * install last milestone from *job param* oldURL = http://download.jboss.org/jbosstools/updates/staging/JBossTools-4.2.0.Bet...
> * install Eclipse from *job param* eclipseBundleVersion = luna.M6 (in a different folder)
> * install new nightly from *job param* oldURL = http://download.jboss.org/jbosstools/updates/nightlycore/4.2.luna/
> * compare installed footprints - see https://github.com/jbosstools/jbosstools-build-ci/blob/master/util/instal...
> * run p2diff on the two repos - see https://github.com/irbull/p2diff
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JBIDE-21233) remove need for a targetplatforms/jbosstoolstarget/neon site
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21233?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-21233:
------------------------------------
Occurs to me the only reason to KEEP this targetplatforms/jbosstoolstarget/neon URL is so that old JBT releases (4.3.0) can automatically link to the LATEST TP (4.52.x) rather than the one against which it was built.
But since an existing JBT user will have http://download.jboss.org/jbosstools/mars/stable/updates/ in their Eclipse, which will be updated to point at BOTH a newer JBT (4.3.1) and a newer TP (4.52.x), we achieve the same thing.
Note too that there's no JBDS equivalent targetplatforms/jbdevstudiotarget/neon URL because (for the same reason) we don't need it. We just update https://devstudio.redhat.com/9.0/stable/updates/ with the latest JBDS and TP, and bob's your uncle, all is well -- latest updates delivered and no new clutter in Available Software Sites.
Bottom line: we're doing something different for JBT than for JBDS, and the net is more maintenance and more Available Software Sites clutter. Surely we should follow the path of "less work, cleaner list of Avail Software Sites" that we use for JBDS when building JBT, too?
Have I missed a reason for keeping this extra URL that provides some value we're not achieving some other way?
> remove need for a targetplatforms/jbosstoolstarget/neon site
> ------------------------------------------------------------
>
> Key: JBIDE-21233
> URL: https://issues.jboss.org/browse/JBIDE-21233
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, target-platform
> Affects Versions: 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.4.0.Alpha1
>
> Attachments: jbt-creeping-update-sites.png
>
>
> For the last few years, we've had an associate site ref inside the JBT agg site, pointing at "the latest maximum TP", eg., http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/mars/
> But since we now always co-release JBT with its TP in the same URL, this is only useful for someone who wants to do an OFFLINE install using the zip, which will then go ONLINE to resolve TP dependencies. It's at best a broken use case, and at worst it's unnecessary cruft to maintain.
> Therefore I propose we stop linking to this site.
> We can build the aggregates using a specific TP (the one in the parent pom, natch), and simply NOT use an associate site in the JBT aggregate site build.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JBIDE-21233) remove need for a targetplatforms/jbosstoolstarget/neon site
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21233?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-21233 at 12/18/15 9:55 AM:
--------------------------------------------------------------
a) All aggregates & composites would be affected: /snapshots, /staging, /development and /stable. By having all 4 delivery types built & released the same way, we ensure more reliable releases.
b) Yes, I agree. The VISIBLE TP URL should not be there (nor should the 2 extra IS URLs). How do we get rid of it? We get rid of the associate sites and stick to just a composite site, since composites allow you to see the content of all the children but don't add extra URLs into the list of Available Software Sites. This is evident in JBDS (we only have one assoc site and it's a pointer to https://devstudio.redhat.com/$\{devstudioReleaseVersion}/stable/updates/ ), but not (yet) there in JBT since we have an assoc site link to our "latest TP" directly rather than hiding that under a composite site.
Re: 'too many sites visible in Available Software Sites' vs. 'uncategorized content' ... you can't have both. You can have one or the other. You mostly complain about URLs in the Available Software Sites preference page, so I have to assume that's the more important (*visible*) problem. But the side effect of building composite sites is that target platform content IS available from that same URL (but it's uncategorized). Same's true for JBDS. It has to be or else p2 wouldn't be able to find it.
I don't understand "lower level p2 concept". Please clarify.
c) I refute that it's a problem. I also refute that we're actively moving in that direction, unless you count projects moving from JBoss to Eclipse. m2e, docker tools, angular, jsdt... sure, those release semi-independently of the JBT release cycle. But the rest of the components? Not so much.
If that's a priority for JBDS 10, we should call that out as something that devs *need* to do. Last year I proposed doing CI builds for all the components, then having devs CHOOSE when to release a CI to "integration" and have ONLY those tagged released aggregated into the larger JBT/JBDS sites. No one adopted it. Instead we decided that QE and Dev should work more closely together and use CI builds more frequently... which seems like the opposite of the integration build model (which is comparable to what Eclipse does with map files). We're set up already so if devs want to have us build from tags instead of branches we can do that. Has anyone asked to do that? Not yet, because it's less overhead (more agile) to simply build CI from a branch than to deal with tags/mapfiles/integration builds. If you want it, it has to start at the dev level. Releng will support it (even if it's more overhead) but there needs to first be buy-in from the devs. Do they see the value? It does not (yet) seem that way. Convince them of the value, incentivize them to actually work differently, and we can move to a new development model.
was (Author: nickboldt):
a) All aggregates & composites would be affected: /snapshots, /staging, /development and /stable. By having all 4 delivery types built & released the same way, we ensure more reliable releases.
b) Yes, I agree. The VISIBLE TP URL should not be there (nor should the 2 extra IS URLs). How do we get rid of it? We get rid of the associate sites and stick to just a composite site, since composites allow you to see the content of all the children but don't add extra URLs into the list of Available Software Sites. This is evident in JBDS (we only have one assoc site and it's a pointer to https://devstudio.redhat.com/${devstudioReleaseVersion}/stable/updates/ ), but not (yet) there in JBT since we have an assoc site link to our "latest TP" directly rather than hiding that under a composite site.
Re: 'too many sites visible in Available Software Sites' vs. 'uncategorized content' ... you can't have both. You can have one or the other. You mostly complain about URLs in the Available Software Sites preference page, so I have to assume that's the more important (*visible*) problem. But the side effect of building composite sites is that target platform content IS available from that same URL (but it's uncategorized). Same's true for JBDS. It has to be or else p2 wouldn't be able to find it.
I don't understand "lower level p2 concept". Please clarify.
c) I refute that it's a problem. I also refute that we're actively moving in that direction, unless you count projects moving from JBoss to Eclipse. m2e, docker tools, angular, jsdt... sure, those release semi-independently of the JBT release cycle. But the rest of the components? Not so much.
If that's a priority for JBDS 10, we should call that out as something that devs *need* to do. Last year I proposed doing CI builds for all the components, then having devs CHOOSE when to release a CI to "integration" and have ONLY those tagged released aggregated into the larger JBT/JBDS sites. No one adopted it. Instead we decided that QE and Dev should work more closely together and use CI builds more frequently... which seems like the opposite of the integration build model (which is comparable to what Eclipse does with map files). We're set up already so if devs want to have us build from tags instead of branches we can do that. Has anyone asked to do that? Not yet, because it's less overhead (more agile) to simply build CI from a branch than to deal with tags/mapfiles/integration builds. If you want it, it has to start at the dev level. Releng will support it (even if it's more overhead) but there needs to first be buy-in from the devs. Do they see the value? It does not (yet) seem that way. Convince them of the value, incentivize them to actually work differently, and we can move to a new development model.
> remove need for a targetplatforms/jbosstoolstarget/neon site
> ------------------------------------------------------------
>
> Key: JBIDE-21233
> URL: https://issues.jboss.org/browse/JBIDE-21233
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, target-platform
> Affects Versions: 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.4.0.Alpha1
>
> Attachments: jbt-creeping-update-sites.png
>
>
> For the last few years, we've had an associate site ref inside the JBT agg site, pointing at "the latest maximum TP", eg., http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/mars/
> But since we now always co-release JBT with its TP in the same URL, this is only useful for someone who wants to do an OFFLINE install using the zip, which will then go ONLINE to resolve TP dependencies. It's at best a broken use case, and at worst it's unnecessary cruft to maintain.
> Therefore I propose we stop linking to this site.
> We can build the aggregates using a specific TP (the one in the parent pom, natch), and simply NOT use an associate site in the JBT aggregate site build.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JBIDE-21233) remove need for a targetplatforms/jbosstoolstarget/neon site
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21233?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-21233:
------------------------------------
a) All aggregates & composites would be affected: /snapshots, /staging, /development and /stable. By having all 4 delivery types built & released the same way, we ensure more reliable releases.
b) Yes, I agree. The VISIBLE TP URL should not be there (nor should the 2 extra IS URLs). How do we get rid of it? We get rid of the associate sites and stick to just a composite site, since composites allow you to see the content of all the children but don't add extra URLs into the list of Available Software Sites. This is evident in JBDS (we only have one assoc site and it's a pointer to https://devstudio.redhat.com/${devstudioReleaseVersion}/stable/updates/ ), but not (yet) there in JBT since we have an assoc site link to our "latest TP" directly rather than hiding that under a composite site.
Re: 'too many sites visible in Available Software Sites' vs. 'uncategorized content' ... you can't have both. You can have one or the other. You mostly complain about URLs in the Available Software Sites preference page, so I have to assume that's the more important (*visible*) problem. But the side effect of building composite sites is that target platform content IS available from that same URL (but it's uncategorized). Same's true for JBDS. It has to be or else p2 wouldn't be able to find it.
I don't understand "lower level p2 concept". Please clarify.
c) I refute that it's a problem. I also refute that we're actively moving in that direction, unless you count projects moving from JBoss to Eclipse. m2e, docker tools, angular, jsdt... sure, those release semi-independently of the JBT release cycle. But the rest of the components? Not so much.
If that's a priority for JBDS 10, we should call that out as something that devs *need* to do. Last year I proposed doing CI builds for all the components, then having devs CHOOSE when to release a CI to "integration" and have ONLY those tagged released aggregated into the larger JBT/JBDS sites. No one adopted it. Instead we decided that QE and Dev should work more closely together and use CI builds more frequently... which seems like the opposite of the integration build model (which is comparable to what Eclipse does with map files). We're set up already so if devs want to have us build from tags instead of branches we can do that. Has anyone asked to do that? Not yet, because it's less overhead (more agile) to simply build CI from a branch than to deal with tags/mapfiles/integration builds. If you want it, it has to start at the dev level. Releng will support it (even if it's more overhead) but there needs to first be buy-in from the devs. Do they see the value? It does not (yet) seem that way. Convince them of the value, incentivize them to actually work differently, and we can move to a new development model.
> remove need for a targetplatforms/jbosstoolstarget/neon site
> ------------------------------------------------------------
>
> Key: JBIDE-21233
> URL: https://issues.jboss.org/browse/JBIDE-21233
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, target-platform
> Affects Versions: 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.4.0.Alpha1
>
> Attachments: jbt-creeping-update-sites.png
>
>
> For the last few years, we've had an associate site ref inside the JBT agg site, pointing at "the latest maximum TP", eg., http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/mars/
> But since we now always co-release JBT with its TP in the same URL, this is only useful for someone who wants to do an OFFLINE install using the zip, which will then go ONLINE to resolve TP dependencies. It's at best a broken use case, and at worst it's unnecessary cruft to maintain.
> Therefore I propose we stop linking to this site.
> We can build the aggregates using a specific TP (the one in the parent pom, natch), and simply NOT use an associate site in the JBT aggregate site build.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JBIDE-21199) AssertionFailedException invoking menu on a server.
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21199?page=com.atlassian.jira.plugi... ]
Martin Malina closed JBIDE-21199.
---------------------------------
The exception is gone now. The renamed runtime still disappears from the server config. If you think this should be fixed too, feel free to reopen this or create a new JIRA.
> AssertionFailedException invoking menu on a server.
> ---------------------------------------------------
>
> Key: JBIDE-21199
> URL: https://issues.jboss.org/browse/JBIDE-21199
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.4.0.Alpha1
> Reporter: Viacheslav Kabanovich
> Assignee: Rob Stryker
> Priority: Minor
> Fix For: 4.3.1.Beta1, 4.4.0.Alpha1
>
>
> 1. Create a server with a JBoss runtime.
> 2. Make sure that context menu is invoked without exceptions.
> 3. Open Preferences/Server/Runtime Environments and rename the runtime environment bound to the server.
> 4. Invoke contex menu.
> Menu is opened, but there is logged exception:
> {code}
> !ENTRY org.eclipse.ui.navigator 4 2 2015-12-07 14:45:35.604
> !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.ui.navigator".
> !STACK 0
> org.eclipse.core.runtime.AssertionFailedException: null argument:
> at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:85)
> at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:73)
> at org.eclipse.core.runtime.Path.initialize(Path.java:641)
> at org.eclipse.core.runtime.Path.<init>(Path.java:238)
> at org.eclipse.core.runtime.Path.<init>(Path.java:186)
> at org.jboss.tools.as.core.server.controllable.subsystems.internal.LocalDeploymentOptionsController.makeRelative(LocalDeploymentOptionsController.java:44)
> at org.jboss.tools.as.core.server.controllable.subsystems.internal.LocalDeploymentOptionsController.getDeployFolder(LocalDeploymentOptionsController.java:68)
> at org.jboss.tools.as.core.server.controllable.systems.AbstractJBossDeploymentOptionsController.getDeploymentsRootFolder(AbstractJBossDeploymentOptionsController.java:78)
> at org.jboss.ide.eclipse.as.ui.subsystems.internal.LocalExploreBehavior.getPath(LocalExploreBehavior.java:105)
> at org.jboss.ide.eclipse.as.ui.subsystems.internal.LocalExploreBehavior.getDeployDirectory(LocalExploreBehavior.java:62)
> at org.jboss.ide.eclipse.as.ui.subsystems.internal.LocalExploreBehavior.canExploreServer(LocalExploreBehavior.java:81)
> at org.jboss.ide.eclipse.as.ui.subsystems.internal.LocalExploreBehavior.canExplore(LocalExploreBehavior.java:34)
> at org.jboss.tools.as.wst.server.ui.xpl.ExploreActionProvider.fillContextMenu(ExploreActionProvider.java:102)
> at org.eclipse.ui.navigator.NavigatorActionService$2.run(NavigatorActionService.java:225)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.ui.navigator.NavigatorActionService.addCommonActionProviderMenu(NavigatorActionService.java:219)
> at org.eclipse.ui.navigator.NavigatorActionService.fillContextMenu(NavigatorActionService.java:174)
> at org.eclipse.ui.navigator.CommonNavigatorManager.fillContextMenu(CommonNavigatorManager.java:267)
> at org.eclipse.ui.navigator.CommonNavigatorManager$3.menuAboutToShow(CommonNavigatorManager.java:283)
> at org.eclipse.jface.action.MenuManager.fireAboutToShow(MenuManager.java:333)
> at org.eclipse.jface.action.MenuManager.handleAboutToShow(MenuManager.java:466)
> at org.eclipse.jface.action.MenuManager.access$1(MenuManager.java:461)
> at org.eclipse.jface.action.MenuManager$2.menuShown(MenuManager.java:493)
> at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:255)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4481)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1327)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1351)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1332)
> at org.eclipse.swt.widgets.Menu._setVisible(Menu.java:198)
> at org.eclipse.swt.widgets.Display.runPopups(Display.java:3861)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3420)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1127)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1018)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:156)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:654)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:598)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:139)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:669)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:608)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1515)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1488)
> {code}
> I think we should prevent that exception.
> 5. Open the server in editor. Its 'Runtime Environment' is empty, which means that server lost connection to the renamed environment. Can we do something to prevent it, or is it an upstream issue, or is it an expected behavior?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JBIDE-21363) create bugzilla importer for JIRA
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21363?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-21363:
-------------------------------
Component/s: build
> create bugzilla importer for JIRA
> ---------------------------------
>
> Key: JBIDE-21363
> URL: https://issues.jboss.org/browse/JBIDE-21363
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.3.1.Beta1, 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.3.1.Beta2, 4.4.0.Alpha1
>
>
> Looking to create some kind of jiralint-like scraper tool to facilitate JIRA-like scrum/dashboard tracking of upstream projects, not located in JBoss JIRA.
> This scraper would:
> * [REQ1] find all bugzillas associated with a particular query, such as https://bugs.eclipse.org/bugs/buglist.cgi?status_whiteboard=RHT (18 issues)
> * [REQ2] generate a JIRA for each one found (no dupes should be created)
> * [REQ3] scrape several fields: product, component, version, target milestone, comment #0, summary, bug #
> * [REQ4] need a mapping table for Eclipse-prod:proj:component:fixversion-or-target-milestone to Neon milestone so we can set default values for affectsversion/fixversion/targetrelease in created JIRAs.
> * [REQ5] need a mapping table for Eclipse-prod:proj:component to ERT:component, eg., WTP:JSDT -> javascript
> * [REQ6] created test issues here: https://issues.stage.jboss.org/browse/ERT
> * [REQ7] run as a Jenkins job every 3 hours
> Generated JIRA example:
> {code}
> title: (scraped from summary) Support for smart Import Mechanism [Eclipse BZ 464535]
> issue link: (scraped from BZ ID#) https://bugs.eclipse.org/464535
> description: (scraped from BZ comment #0)
> affectsversion: (scraped from BZ version 1.6.0)
> fixversion: (scraped from BZ target milestone ---)
> component: (scraped from product:component = m2e:ui)
> labels: RHT, ERT
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JBIDE-21363) create bugzilla importer for JIRA
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21363?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-21363:
-------------------------------
Fix Version/s: 4.3.1.Beta2
4.4.0.Alpha1
> create bugzilla importer for JIRA
> ---------------------------------
>
> Key: JBIDE-21363
> URL: https://issues.jboss.org/browse/JBIDE-21363
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Affects Versions: 4.3.1.Beta1, 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.3.1.Beta2, 4.4.0.Alpha1
>
>
> Looking to create some kind of jiralint-like scraper tool to facilitate JIRA-like scrum/dashboard tracking of upstream projects, not located in JBoss JIRA.
> This scraper would:
> * [REQ1] find all bugzillas associated with a particular query, such as https://bugs.eclipse.org/bugs/buglist.cgi?status_whiteboard=RHT (18 issues)
> * [REQ2] generate a JIRA for each one found (no dupes should be created)
> * [REQ3] scrape several fields: product, component, version, target milestone, comment #0, summary, bug #
> * [REQ4] need a mapping table for Eclipse-prod:proj:component:fixversion-or-target-milestone to Neon milestone so we can set default values for affectsversion/fixversion/targetrelease in created JIRAs.
> * [REQ5] need a mapping table for Eclipse-prod:proj:component to ERT:component, eg., WTP:JSDT -> javascript
> * [REQ6] created test issues here: https://issues.stage.jboss.org/browse/ERT
> * [REQ7] run as a Jenkins job every 3 hours
> Generated JIRA example:
> {code}
> title: (scraped from summary) Support for smart Import Mechanism [Eclipse BZ 464535]
> issue link: (scraped from BZ ID#) https://bugs.eclipse.org/464535
> description: (scraped from BZ comment #0)
> affectsversion: (scraped from BZ version 1.6.0)
> fixversion: (scraped from BZ target milestone ---)
> component: (scraped from product:component = m2e:ui)
> labels: RHT, ERT
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JBIDE-21342) [CDK] multiple duplicate docker connections created after multiple starts
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21342?page=com.atlassian.jira.plugi... ]
Martin Malina closed JBIDE-21342.
---------------------------------
This was because Rob was looking for tcp:// or http://, but not https://. I'm not sure why depend on these at all, but it is working now.
> [CDK] multiple duplicate docker connections created after multiple starts
> -------------------------------------------------------------------------
>
> Key: JBIDE-21342
> URL: https://issues.jboss.org/browse/JBIDE-21342
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift, server
> Affects Versions: 4.3.1.Beta1
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Labels: respin-a
> Fix For: 4.3.1.Beta1, 4.3.1.Beta2, 4.4.0.Alpha1
>
> Attachments: IMG_1145.jpg
>
>
> After starting and stopping the CDK multiple times, multiple docker connections exist.
> This does not seem replicatable on linux; only windows.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months