September 2016 - jbosstools-issues

[JBoss JIRA] (JBIDE-22248) Some CI jobs fail at deploying to Nexus

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22248?page=com.atlassian.jira.plugi... ] Nick Boldt closed JBIDE-22248. ------------------------------ Fix Version/s: 4.3.2.Final Resolution: Done Reclosing. > Some CI jobs fail at deploying to Nexus > --------------------------------------- > > Key: JBIDE-22248 > URL: https://issues.jboss.org/browse/JBIDE-22248 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.4.0.Alpha1 > Reporter: Martin Malina > Assignee: Nick Boldt > Priority: Blocker > Fix For: 4.3.2.Final, 4.4.0.Alpha2 > > > Nick, can you take a look why mvn deploy fails here? > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... > It worked for us in the past. > It says: > {code} > [WARNING] Could not transfer metadata org.jboss.reddeer:jboss-reddeer-archetype/maven-metadata.xml from/to jboss-snapshots-repository (https://repository.jboss.org/nexus/content/repositories/snapshots/): Not authorized , ReasonPhrase:Unauthorized. > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 04:49 min > [INFO] Finished at: 2016-04-26T09:42:02-04:00 > [INFO] Final Memory: 19M/612M > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on project jboss-reddeer-archetype: Failed to retrieve remote metadata org.jboss.reddeer:jboss-reddeer-archetype/maven-metadata.xml: Could not transfer metadata org.jboss.reddeer:jboss-reddeer-archetype/maven-metadata.xml from/to jboss-snapshots-repository (https://repository.jboss.org/nexus/content/repositories/snapshots/): Not authorized , ReasonPhrase:Unauthorized. -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please read the following articles: > [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException > {code} > I'm not exactly sure how this works. Or is this something that is managed in jenkins config, so should I raise this with the jenkins team? > Cc: [~rawagner] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22248) Some CI jobs fail at deploying to Nexus

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22248?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-22248: ------------------------------------ Fixed in 4.3.x branch too: https://github.com/jbosstools/jbosstools-build/blob/jbosstools-4.3.x/pare... Now you can build with `-DjbossNexus=origin-repository.jboss.org` to work around those 404 errors like this one: {code} 404 - Request is marked as local-only, remote access not allowed from M2Repository(id=snapshots) Request is marked as local-only, remote access not allowed from M2Repository(id=snapshots){code} -- https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... > Some CI jobs fail at deploying to Nexus > --------------------------------------- > > Key: JBIDE-22248 > URL: https://issues.jboss.org/browse/JBIDE-22248 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.4.0.Alpha1 > Reporter: Martin Malina > Assignee: Nick Boldt > Priority: Blocker > Fix For: 4.4.0.Alpha2 > > > Nick, can you take a look why mvn deploy fails here? > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... > It worked for us in the past. > It says: > {code} > [WARNING] Could not transfer metadata org.jboss.reddeer:jboss-reddeer-archetype/maven-metadata.xml from/to jboss-snapshots-repository (https://repository.jboss.org/nexus/content/repositories/snapshots/): Not authorized , ReasonPhrase:Unauthorized. > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 04:49 min > [INFO] Finished at: 2016-04-26T09:42:02-04:00 > [INFO] Final Memory: 19M/612M > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on project jboss-reddeer-archetype: Failed to retrieve remote metadata org.jboss.reddeer:jboss-reddeer-archetype/maven-metadata.xml: Could not transfer metadata org.jboss.reddeer:jboss-reddeer-archetype/maven-metadata.xml from/to jboss-snapshots-repository (https://repository.jboss.org/nexus/content/repositories/snapshots/): Not authorized , ReasonPhrase:Unauthorized. -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please read the following articles: > [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException > {code} > I'm not exactly sure how this works. Or is this something that is managed in jenkins config, so should I raise this with the jenkins team? > Cc: [~rawagner] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23014) Allow connections to configure the cluster namespace from which to get clusterwide templates

by Jeff MAURY (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23014?page=com.atlassian.jira.plugi... ] Jeff MAURY reassigned JBIDE-23014: ---------------------------------- Assignee: Jeff MAURY > Allow connections to configure the cluster namespace from which to get clusterwide templates > -------------------------------------------------------------------------------------------- > > Key: JBIDE-23014 > URL: https://issues.jboss.org/browse/JBIDE-23014 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: openshift > Reporter: Jeff Cantrill > Assignee: Jeff MAURY > Labels: connection, connection_wizard, openshift_v3 > Fix For: 4.4.x > > > There are a few places where we assume the cluster is configured with the openshift namespace (e.gretrieve templates) which contains templates and other resources that are available to everyone. We should provide a per connection configuration (advanced property?) that allows us to change the default since it is not discoverable from the server. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22915) Deploy Docker Image: Replication controller is not created for some images

by Jeff MAURY (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22915?page=com.atlassian.jira.plugi... ] Jeff MAURY reassigned JBIDE-22915: ---------------------------------- Assignee: Jeff MAURY > Deploy Docker Image: Replication controller is not created for some images > -------------------------------------------------------------------------- > > Key: JBIDE-22915 > URL: https://issues.jboss.org/browse/JBIDE-22915 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.1.AM3 > Reporter: Marián Labuda > Assignee: Jeff MAURY > Labels: deploy_docker_wizard, openshift_v3 > Fix For: 4.4.2.AM1 > > > When I am trying to deploy docker image docker.io/openshift/hello-openshift:v1.2.1 from context menu of the image in Docker Explorer it does not trigger a new replication controller and thus an application pod is not spinned up. When working from oc binary, replication controller is created successfully ("oc new-app docker.io/openshift/hello-openshift:v1.2.1") -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23014) Allow connections to configure the cluster namespace from which to get clusterwide templates

by Jeff MAURY (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23014?page=com.atlassian.jira.plugi... ] Jeff MAURY updated JBIDE-23014: ------------------------------- Story Points: 10 (was: 4) > Allow connections to configure the cluster namespace from which to get clusterwide templates > -------------------------------------------------------------------------------------------- > > Key: JBIDE-23014 > URL: https://issues.jboss.org/browse/JBIDE-23014 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: openshift > Reporter: Jeff Cantrill > Labels: connection, connection_wizard, openshift_v3 > Fix For: 4.4.x > > > There are a few places where we assume the cluster is configured with the openshift namespace (e.gretrieve templates) which contains templates and other resources that are available to everyone. We should provide a per connection configuration (advanced property?) that allows us to change the default since it is not discoverable from the server. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22915) Deploy Docker Image: Replication controller is not created for some images

by Jeff MAURY (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22915?page=com.atlassian.jira.plugi... ] Jeff MAURY updated JBIDE-22915: ------------------------------- Sprint: devex #120 September 2016 > Deploy Docker Image: Replication controller is not created for some images > -------------------------------------------------------------------------- > > Key: JBIDE-22915 > URL: https://issues.jboss.org/browse/JBIDE-22915 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.1.AM3 > Reporter: Marián Labuda > Labels: deploy_docker_wizard, openshift_v3 > Fix For: 4.4.2.AM1 > > > When I am trying to deploy docker image docker.io/openshift/hello-openshift:v1.2.1 from context menu of the image in Docker Explorer it does not trigger a new replication controller and thus an application pod is not spinned up. When working from oc binary, replication controller is created successfully ("oc new-app docker.io/openshift/hello-openshift:v1.2.1") -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22915) Deploy Docker Image: Replication controller is not created for some images

by Jeff MAURY (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22915?page=com.atlassian.jira.plugi... ] Jeff MAURY updated JBIDE-22915: ------------------------------- Story Points: 2 > Deploy Docker Image: Replication controller is not created for some images > -------------------------------------------------------------------------- > > Key: JBIDE-22915 > URL: https://issues.jboss.org/browse/JBIDE-22915 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.1.AM3 > Reporter: Marián Labuda > Labels: deploy_docker_wizard, openshift_v3 > Fix For: 4.4.2.AM1 > > > When I am trying to deploy docker image docker.io/openshift/hello-openshift:v1.2.1 from context menu of the image in Docker Explorer it does not trigger a new replication controller and thus an application pod is not spinned up. When working from oc binary, replication controller is created successfully ("oc new-app docker.io/openshift/hello-openshift:v1.2.1") -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22915) Deploy Docker Image: Replication controller is not created for some images

by Jeff MAURY (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22915?page=com.atlassian.jira.plugi... ] Jeff MAURY updated JBIDE-22915: ------------------------------- Story Points: 4 (was: 2) > Deploy Docker Image: Replication controller is not created for some images > -------------------------------------------------------------------------- > > Key: JBIDE-22915 > URL: https://issues.jboss.org/browse/JBIDE-22915 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.1.AM3 > Reporter: Marián Labuda > Labels: deploy_docker_wizard, openshift_v3 > Fix For: 4.4.2.AM1 > > > When I am trying to deploy docker image docker.io/openshift/hello-openshift:v1.2.1 from context menu of the image in Docker Explorer it does not trigger a new replication controller and thus an application pod is not spinned up. When working from oc binary, replication controller is created successfully ("oc new-app docker.io/openshift/hello-openshift:v1.2.1") -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22916) Deploy Docker Wizard: Deploying a docker image from OpenShift explorer does not fetch metadata

by Jeff MAURY (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22916?page=com.atlassian.jira.plugi... ] Jeff MAURY commented on JBIDE-22916: ------------------------------------ There is one case which is not covered yet: when the docker image is in the docker daemon (of the docker connection). In that case, the image metadata are loaded from Docker and not from Openshift and seems exposed ports and env vars are not loaded correctly > Deploy Docker Wizard: Deploying a docker image from OpenShift explorer does not fetch metadata > ---------------------------------------------------------------------------------------------- > > Key: JBIDE-22916 > URL: https://issues.jboss.org/browse/JBIDE-22916 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.1.AM3 > Reporter: Marián Labuda > Assignee: Jeff MAURY > Labels: deploy_docker_wizard, openshift_v3 > Fix For: 4.4.1.Final > > > When I am trying to deploy a docker image from context menu of a project in OpenShift explorer view and I paste image name (e.g. docker.io/openshift/hello-openshift), image metadata are not fetched/processed and thus there are no environment variables in the wizard and routing (routing wizard page is empty and cannot finish dialog - requires manual entry). This force user to enter the details manually, otherwise he would get deployed not working pod. This is happening only in case when user provide an image without any tag and thus there is/supposed to be assumed tag "latest". > You can observe that it works when using tag v1.2.1. Difference between images with tag v1.2.1 and latest is that v1.2.1 contains exposed ports also in container config, not just in general config of the image. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23074) For JBIDE 4.4.1.Final: Prepare for 4.4.1.Final / 10.1.0.GA [Integration Tests]

by Radim Hopp (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23074?page=com.atlassian.jira.plugi... ] Radim Hopp closed JBIDE-23074. ------------------------------ Resolution: Done Done. > For JBIDE 4.4.1.Final: Prepare for 4.4.1.Final / 10.1.0.GA [Integration Tests] > ------------------------------------------------------------------------------ > > Key: JBIDE-23074 > URL: https://issues.jboss.org/browse/JBIDE-23074 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: qa > Reporter: Friendly Jira Robot > Assignee: Radim Hopp > Priority: Blocker > Labels: task > Fix For: 4.4.1.Final > > > For JBIDE 4.4.1.Final [Integration Tests]: Please perform the following tasks: > 0. Make sure your component has no remaining unresolved JIRAs set for fixVersion = 4.4.1.Final or 10.1.0.GA > [Unresolved JIRAs with fixVersion = 4.4.1.Final, 10.1.0.GA|https://issues.jboss.org/issues/?jql=%28%28project%20%3D%20%22J...] > 1. Check out your existing *{color:orange}master{color}* branch: > {code} > git checkout master > {code} > 2. Update your *{color:orange}master branch{color}* root pom to use the latest parent pom version, *{color:orange}4.4.1.Final-SNAPSHOT{color}*: > {code} > <parent> > <groupId>org.jboss.tools</groupId> > <artifactId>parent</artifactId> > <version>4.4.1.Final-SNAPSHOT</version> > </parent> > {code} > Now, your root pom will use parent pom version: > * *{color:orange}4.4.1.Final-SNAPSHOT{color}* in your *{color:orange}master{color}* branch > 3. Branch from your existing master branch into a new *{color:blue}jbosstools-4.4.1.x{color}* branch: > {code} > git checkout master > git pull origin master > git checkout -b jbosstools-4.4.1.x > git push origin jbosstools-4.4.1.x > {code} > Now, your root pom will use parent pom version: > * *{color:blue}4.4.1.Final-SNAPSHOT{color}* in your *{color:blue}jbosstools-4.4.1.x{color}* branch, too. > 4a. Ensure you've *built your code* using the latest *minimum* target platform version 4.60.1.Final > {code} > mvn clean verify -Dtpc.version=4.60.1.Final > {code} > 4b. Ensure you've *run your tests* using the latest *maximum* target platform version 4.60.1.Final > {code} > mvn clean verify -Dtpc.version=4.60.1.Final > {code} > 5. Close (do not resolve) this JIRA when done. > 6. If you have any outstanding [New + Noteworthy JIRAs|https://issues.jboss.org/issues/?jql=%28%28project%20%3D%20%22JBIDE...] to do, please complete them next. > [Search for all task JIRA|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+and...], or [Search for Integration Tests task JIRA|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+and...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues September 2016