[JBoss JIRA] (JBIDE-21145) Component-install job does not reliably install all JBT IUs and so does not see changes between CI builds
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21145?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-21145:
------------------------------------
I think you meant JBIDE-16970, not JBIDE-19670.
If people feel we need more frequent composite/aggregate build checks... let me know.
Currently:
* JBT composite runs every 3 hrs to see if anything is new in the upstream component jobs, then that fires the aggregates if something is found.
* JBT aggregates (core, tests, child-sites) in the 4.3.mars branch fire every 8 hrs.
* JBT aggregates (core, tests, child-sites) in the master branch fire every 8 hrs.
* JBT aggregate (core only) in the master branch ALSO fires on its own every 6 hrs, independent of git changes.
Does that work for everyone?
I'm thinking we could add the "every 6 hrs" re-fire to both branches and the tests + child-sites builds too, or else remove the JBT core master 6hr cycle. Figure we should be consistent here.
> Component-install job does not reliably install all JBT IUs and so does not see changes between CI builds
> ---------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-21145
> URL: https://issues.jboss.org/browse/JBIDE-21145
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.3.1.Beta1, 4.4.0.Alpha1
> Reporter: Pavol Srna
> Assignee: Nick Boldt
> Priority: Blocker
> Fix For: 4.3.1.Beta1, 4.4.0.Alpha1
>
>
> We have often seen old artifacts on nightly sites (mars and neon too).
> It seems that the composite-install job [0], [1] is not reliable. So, the downstream JBT aggregate builds [2], [3] are not triggered automatically to pick up all new changes in the upstream JBT component site builds.
> [0] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite-...
> [1] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite-...
> [2] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-build-site... (latest build shows: "Nov 27, 2015 6:15 AM NOT PUBLISHED: UNCHANGED")
> [3] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-build-site... (latest build shows: "Nov 27, 2015 3:43 AM NOT PUBLISHED: UNCHANGED")
> Please investigate.
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[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 commented on JBIDE-16970:
------------------------------------
Please elaborate on your cryptic phrase "actual updates". I am led to believe that if the sources in the git repo changes, and the bits are rebuilt, they'll be new, different, upversioned, etc., thus making any source change an "actual update."
Is there something else you think a p2 diff will capture that a souce diff won't? Some new third party bits sucked into the build will likely ALSO cause a source change (a new version of some runtime needed to build forge or openshift or hibernate, for example). Some new URL for a new version of angular or tern will also be reflected in the root pom of those projects (jst, javaee, etc.).
So... can you demonstrate how to make an "actual update" in the composite or aggregate site that is not the result of an upstream SOURCE change?
> 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.x
>
>
> 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, 4 months
[JBoss JIRA] (JBIDE-21161) various UI issues on new cdk server adapter
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21161?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-21161:
-------------------------------------
The credential widgets are part of their own composite, and so I'm finding it difficult to ensure it aligns with the widgets from the parent composite. When I had the text fields left-aligned, they appeared directly next to the label, so, much further left than the text box next to Folder. ie, it looked even worse when left-aligned.
I could surround it in a Group so that the slight differences are less jarring to the user.
The reason I can't necessarily just have these widgets fill in the same layout as the parent composite is that we don't know what the parent composite's layout will be... It's possible the parent composite is a FormLayout or a gridlayout with 7 rows, or some other obscure layout, so I can't really make assumptions about the parent. What I *can* do is make sure my 5 widgets are in their own composite and look good self-contained, but when using that widget in other layouts, it may not always 'match'.
I can change the labels but aside from surrounding the composite in a group, I'm not sure how best to solve the layout issue.
> various UI issues on new cdk server adapter
> -------------------------------------------
>
> Key: JBIDE-21161
> URL: https://issues.jboss.org/browse/JBIDE-21161
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Reporter: Max Rydahl Andersen
> Assignee: Rob Stryker
> Attachments: New_Server_and_Java_EE_-_Eclipse.png
>
>
> the cDK server adapter page has some "weird" UI layout.
> see attached.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-21125) There was an error retrieving children in the OpenShift explorer Unable to find the connection for a %s named %s
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21125?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-21125:
------------------------------------------
I see the error being used in:
{code}
public ConnectionNotFoundException(IResource resource) {
super("Unable to find the connection for a {0} named {1}", resource.getKind(), resource.getName());
}
{code}
which is throws when a connection for a given resource is being looked up:
{code}
public class ConnectionsRegistryUtil {
...
public static Connection getConnectionFor(IResource resource) {
Connection connection = safeGetConnectionFor(resource);
if(connection == null) {
throw new ConnectionNotFoundException(resource);
}
return connection;
}
{code}
which is being used in various places upon application creation. It compares client lib instances which I guess can change upon re-connects.
I also see this being used in other related places like explorer watches etc.
I'd love to get more repdroducible details on when this happens to you.
> There was an error retrieving children in the OpenShift explorer Unable to find the connection for a %s named %s
> ----------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-21125
> URL: https://issues.jboss.org/browse/JBIDE-21125
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Reporter: Burr Sutter
> Fix For: 4.3.1.Beta1, 4.4.0.Alpha1
>
>
> Nightly Build from (Nov 20)
> File New OpenShift Application
> eap6-basic-sti
> produces:
> There was an error retrieving children in the OpenShift explorer
> Unable to find the connection for a %s named %s
> This version of Openshift
> https://github.com/hferentschik/openshift-vagrant
> oc version
> oc v3.1.0.4-3-ga6353c7
> kubernetes v1.1.0-origin-1107-g4c8e6f4
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-21173) Runtime detection not working for CDK 2 Beta3
by Martin Malina (JIRA)
Martin Malina created JBIDE-21173:
-------------------------------------
Summary: Runtime detection not working for CDK 2 Beta3
Key: JBIDE-21173
URL: https://issues.jboss.org/browse/JBIDE-21173
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: openshift
Affects Versions: 4.3.1.Beta1
Reporter: Martin Malina
Assignee: Rob Stryker
When I point runtime detection to my cdk folder, it will not detect anything.
I had the openshift.cdk feature installed.
{code}
nattura:features rasp$ ls|grep cdk
org.jboss.tools.openshift.cdk.feature_3.1.0.Beta1-v20151202-0847-B100
{code}
And the runtime detection preference page shows that it will search for cdk runtimes
(CDK is checked).
The cdk in the folder that I use work fine when I add the adapter manually.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-21125) There was an error retrieving children in the OpenShift explorer Unable to find the connection for a %s named %s
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21125?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-21125 at 12/2/15 10:14 AM:
--------------------------------------------------------------------
[~burrsutter] the stacktrace seems unrelated, it reports "Failed to load list of Docker containers from cdk2". Do you have the proper stacktrace or am I missing something?
Halting and reprovisioning could be the reason for the above but I cant reproduce it so far.
At what step does this happen to you? When creating the resources or upon import?
was (Author: adietish):
[~burrsutter] the stacktrace seems unrelated, it reports "Failed to load list of Docker containers from cdk2". Do you have the proper stacktrace or am I missing something?
Halting and reprovisioning could be the reason for the above but I cant reproduce it so far.
> There was an error retrieving children in the OpenShift explorer Unable to find the connection for a %s named %s
> ----------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-21125
> URL: https://issues.jboss.org/browse/JBIDE-21125
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Reporter: Burr Sutter
> Fix For: 4.3.1.Beta1, 4.4.0.Alpha1
>
>
> Nightly Build from (Nov 20)
> File New OpenShift Application
> eap6-basic-sti
> produces:
> There was an error retrieving children in the OpenShift explorer
> Unable to find the connection for a %s named %s
> This version of Openshift
> https://github.com/hferentschik/openshift-vagrant
> oc version
> oc v3.1.0.4-3-ga6353c7
> kubernetes v1.1.0-origin-1107-g4c8e6f4
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-21171) Need to remove bower / npm from jboss.tools.jsdt
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21171?page=com.atlassian.jira.plugi... ]
Ilya Buziuk updated JBIDE-21171:
--------------------------------
Description:
Assuming that bower / npm were moved to eclipse jsdt - https://git.eclipse.org/r/#/c/61336/
Need to perform a cleanup in jboss.tools.jst.jsdt repo and remove related plugins / tests / features
Bower is in eclipse upstream and we probably will need reflect it in new & noteworthy
was:
Assuming that bower / npm were moved to eclipse jsdt -
Need to perform a cleanup in jboss.tools.jst.jsdt repo
Bower is in eclipse upstream and we probably will need reflect it in new & noteworthy
> Need to remove bower / npm from jboss.tools.jsdt
> ------------------------------------------------
>
> Key: JBIDE-21171
> URL: https://issues.jboss.org/browse/JBIDE-21171
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: nodejs
> Affects Versions: 4.3.0.Final
> Reporter: Ilya Buziuk
> Assignee: Ilya Buziuk
> Labels: new_and_noteworthy
> Fix For: 4.4.0.Alpha1
>
>
> Assuming that bower / npm were moved to eclipse jsdt - https://git.eclipse.org/r/#/c/61336/
> Need to perform a cleanup in jboss.tools.jst.jsdt repo and remove related plugins / tests / features
> Bower is in eclipse upstream and we probably will need reflect it in new & noteworthy
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months