September 2016 - jbosstools-issues

[JBoss JIRA] (JBDS-4056) Devsuite 1.1.0 install fails due to vagrant 1.8.1 box add failure

by Robert Terzi (JIRA)

Robert Terzi created JBDS-4056: ---------------------------------- Summary: Devsuite 1.1.0 install fails due to vagrant 1.8.1 box add failure Key: JBDS-4056 URL: https://issues.jboss.org/browse/JBDS-4056 Project: Red Hat JBoss Developer Studio (devstudio) Issue Type: Bug Components: platform-installer Affects Versions: 1.1.0.GA Environment: Windows 10/64 bit Reporter: Robert Terzi DevSuite 1.1.0 GA install fails on Windows 10/64 bit, due to CDK vagrant box add failure that maybe related to Vagrant version greater than 1.7.4. See related ticket JBDS-3863 Platform installer hangs for log files. Split this into a separate ticket to track vagrant version issue in this ticket and the lack of feedback in 3863. See vagrant issue - https://github.com/mitchellh/vagrant/issues/6725 - Adding a local box via "box add" fails with v1.8.0, succeeds with v1.7.4 #6725 Partial workaround: 1. Install DevSuite 1.1.0, quit installer after CDK install fails 2. Uninstall Vagrant 1.8.1 3. download and install Vagrant 1.7.4 4. cd c:\DevelopmentSuite\cdk\boxes 5. vagrant box add --name cdkv2 rhel-vagrant-virtualbox.box An alternative workaround from the Vagrant issue #6725, maybe to install VC++ 2010 redistributable runtime libraries to work around curl problem in vagrant box add. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23208) SSLCertificatesPreference.isValid(String): Could not parse

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23208?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-23208: ------------------------------------- [~scabanovich] [~mmalina] I've made a PR to implement slava's proposed fix, but I haven't tested it (not sure on the workflow to test it). https://github.com/jbosstools/jbosstools-openshift/pull/1324 > SSLCertificatesPreference.isValid(String): Could not parse > ---------------------------------------------------------- > > Key: JBIDE-23208 > URL: https://issues.jboss.org/browse/JBIDE-23208 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: cdk, openshift > Affects Versions: 4.4.2.AM1 > Reporter: Martin Malina > > When I start CDK and OpenShift connection is established, I get this in the Error Log view: > org.jboss.tools.openshift.ui > SSLCertificatesPreference.isValid(String): Could not parse 'Čt, 20 Zář 2018 12:54:07' in format E, d MMM yyyy HH:mm:ss > An exception stack trace is not available. > As you can see, the date is localized. I think this started happening after I updated to macOS Sierra last night - I never noticed it before. If we can figure out where the parsing is happening, perhaps we can come up with a switch for using english date here. > Env: > devstudio-10.2.0.AM1-v20160920-0457-B6061-installer-standalone.jar > cdk 2.2.rc5 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23015) Creating a route should have a default port

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23015?page=com.atlassian.jira.plugi... ] Andre Dietisheim commented on JBIDE-23015: ------------------------------------------ In JBIDE-23204 the tooling was changed to referencing the latest openshift-restclient-java 5.2.0-SNAPSHOT. So this change in the PR is now obsolete > Creating a route should have a default port > ------------------------------------------- > > Key: JBIDE-23015 > URL: https://issues.jboss.org/browse/JBIDE-23015 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.4.1.AM3 > Reporter: Fred Bricon > Assignee: Jeff MAURY > Labels: new_and_noteworthy, openshift, openshift_v3 > Fix For: 4.4.2.AM1 > > > When deploying a docker image, in the Services and Routing settings, when "Add route" is checked, if there are multiple ports exposed, then openshift will round-robin the route to any of the ports. So if you have 3 exposed ports, 1 of them is for the web app, then 2/3 of the http connections to the service will fail. > There should be a new column, in the ports table, with 1 checkbox checkable at the time: checking 1 box will uncheck the others. > The lowest port should be selected by default (that's what the oc client does apparently, but deserve confirmation) > To reproduce: > - git clone https://github.com/redhat-helloworld-msa/aloha > - mvn package > - build docker image from Dockerfile, to CDK docker connection > - deploy docker image to openshift -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23206) build flag for always use current timestamp to assist QE in testing PRs

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23206?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-23206: ------------------------------------- I like -PR. -Prawblem is a horrible name. It's mean to accuse QE of causing all our problems, and reminding them of this each time they test a PR. ;) > build flag for always use current timestamp to assist QE in testing PRs > ----------------------------------------------------------------------- > > Key: JBIDE-23206 > URL: https://issues.jboss.org/browse/JBIDE-23206 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Affects Versions: 4.4.2.AM1 > Reporter: Rob Stryker > Assignee: Nick Boldt > > In the case where a PR is not rebased against master constantly, QE is blocked from testing it under two situations: > 1) The PR job has produced a site. QE installs most recent jbt, then tries to install the PR site. This fails because the PR site is older than the nightly build. > 2) The QE rep checks out the PR and tries to build locally. The timestamps match the change date (ie the date the PR was last changed), which is still older than the nightly build. > In both situations, QE cannot install a locally-built or PR-built site on top of a more recent nightly build of JBT. We cannot expect QE to rebase and (if required) merge / change code. > The best bet here is to simply add a flag QE can use when building locally to always use current timestamp, to ensure locally built unit is always 'newest'. > We then document that flag in devdoc for QE and make it part of their standard workflow. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23090) instead of running the getProjectRootPomParents.sh script on jenkins, reference it in the email

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23090?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-23090: ------------------------------------ seems that while I can put a comment in a JIRA with smart commit comments, I can't cause an issue to be resolved or closed > instead of running the getProjectRootPomParents.sh script on jenkins, reference it in the email > ----------------------------------------------------------------------------------------------- > > Key: JBIDE-23090 > URL: https://issues.jboss.org/browse/JBIDE-23090 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: build > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.2.AM1 > > > instead of running the getProjectRootPomParents.sh script on jenkins, reference it in the email so that Alexey or Jeff can run it locally in their /tmp folder > 1. script how to fetch jbosstools-build-ci > 2. script how to then run getProjectRootPomParents.sh -w1 /tmp/some-folder/ -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3863) Platform Installer Hung after CDK install failed, no way to cancel, no info on error.

by Robert Terzi (JIRA)

[ https://issues.jboss.org/browse/JBDS-3863?page=com.atlassian.jira.plugin.... ] Robert Terzi edited comment on JBDS-3863 at 9/21/16 3:29 PM: ------------------------------------------------------------- DevSuite 1.1.0 GA is installing Vagrant 1.8.1. Is this correct? In the past CDK was recommending against using 1.8.0 or 1.8.1. When trying to figure out what the cause of the vagrant box add failure that is preventing DevSuite 1.1.0 installer from successfully completing, I found this issue open Vagrant issue. https://github.com/mitchellh/vagrant/issues/6725. I have not been able to get a successful install on my Windows 10 machine so far. Update: Tried Vagrant 1.7.4 was able to successfully add the box manually, but the installer won't install with vagrant < 1.8.1 was (Author: rterzi): DevSuite 1.1.0 GA is installing Vagrant 1.8.1. Is this correct? In the past CDK was recommending against using 1.8.0 or 1.8.1. When trying to figure out what the cause of the vagrant box add failure that is preventing DevSuite 1.1.0 installer from successfully completing, I found this issue open Vagrant issue. https://github.com/mitchellh/vagrant/issues/6725. I have no been able to get a successful install on my Windows 10 machine so far. > Platform Installer Hung after CDK install failed, no way to cancel, no info on error. > -------------------------------------------------------------------------------------- > > Key: JBDS-3863 > URL: https://issues.jboss.org/browse/JBDS-3863 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Bug > Components: platform-installer > Affects Versions: 1.1.0.GA, 9.1.0.Beta1 > Environment: Windows 7/64 bit. > (Some components of previous manual CDK install on the system). > Also Windows 10/64. > Reporter: Robert Terzi > Assignee: Denis Golovin > Fix For: 10.2.0.AM1 > > Attachments: box-add-fail-1.1.0-ga.txt, install.log, jbds-install-log-win7-error.txt > > > Using the platform installer, CDK installation failed, progress shown as 99%. At this point the installer was hung. > Note: > * CDK install progress said Failed, with progress stuck at 99%. > * There is no way to cancel out of the install. > * There was no pop-up about error messages. > * No indication of where to look for error messages/logs etc.was provided. > * CDK was previously installed manually. However, the installer window didn't say a previous CDK installation was detected, but the log does show it deleted the previous cdkv2 box. > From the log it looks like the box add command failed. When originally reported it might have been due to disk space, but it's not clear/obvious from the log. As of DevSuite 1.1.0 GA, the problems still exists if the vagrant box add command fails. Note: I've verified this isn't related to disk space and is a Vagrant problem. > Note: after killing the installer and trying the `vagrant box add` command copied from the log file manually in Cygwin bash the box add command succeeded. The test system had 5-15 GB of free space between the installation started. > Full log attached, excerpt here. > Tue, 26 Apr 2016 18:05:38 GMT-INFO: cdk - Move C:\Users\rct\AppData\Local\Temp\7zSC53C.tmp\rhel-vagrant-virtualbox.box to c:\sw\rhjbds\cdk\boxes\rhel-vagrant-virtualbox.box > Tue, 26 Apr 2016 18:05:43 GMT-INFO: cdk - Move C:\Users\rct\AppData\Local\Temp\7zSC53C.tmp\rhel-vagrant-virtualbox.box to c:\sw\rhjbds\cdk\boxes\rhel-vagrant-virtualbox.box SUCCESS > Tue, 26 Apr 2016 18:05:43 GMT-INFO: cdk - Move C:\Users\rct\AppData\Local\Temp\7zSC53C.tmp\pscp.exe to c:\sw\rhjbds\cdk\bin\pscp.exe > Tue, 26 Apr 2016 18:05:43 GMT-INFO: cdk - Move C:\Users\rct\AppData\Local\Temp\7zSC53C.tmp\pscp.exe to c:\sw\rhjbds\cdk\bin\pscp.exe SUCCESS > Tue, 26 Apr 2016 18:05:43 GMT-INFO: cdk - Write C:\Users\rct\AppData\Local\Temp\set-pscp-path.ps1 > Tue, 26 Apr 2016 18:05:43 GMT-INFO: cdk - Write C:\Users\rct\AppData\Local\Temp\set-pscp-path.ps1 SUCCESS > Tue, 26 Apr 2016 18:05:43 GMT-INFO: cdk - Write c:\sw\rhjbds\cdk\components\rhel\rhel-ose\.cdk > Tue, 26 Apr 2016 18:05:43 GMT-INFO: cdk - Write c:\sw\rhjbds\cdk\components\rhel\rhel-ose\.cdk SUCCESS > Tue, 26 Apr 2016 18:05:43 GMT-INFO: cdk - Execute powershell -ExecutionPolicy,ByPass,-File,C:\Users\rct\AppData\Local\Temp\set-pscp-path.ps1 > Tue, 26 Apr 2016 18:05:44 GMT-INFO: cdk - Execute powershell -ExecutionPolicy,ByPass,-File,C:\Users\rct\AppData\Local\Temp\set-pscp-path.ps1 SUCCESS > Tue, 26 Apr 2016 18:05:44 GMT-INFO: cdk - postVagrantSetup called > Tue, 26 Apr 2016 18:05:44 GMT-INFO: cdk - Execute command vagrant plugin install "c:\sw\rhjbds\cdk\plugins\vagrant-registration-1.2.1.gem" > Tue, 26 Apr 2016 18:05:44 GMT-INFO: cdk - Execute options { > "env": { > "path": "C:\\HashiCorp\\Vagrant\\bin;C:\\Program Files\\Oracle\\VirtualBox\\;" > } > } > Tue, 26 Apr 2016 18:05:55 GMT-INFO: cdk - Installing the 'c:\sw\rhjbds\cdk\plugins\vagrant-registration-1.2.1.gem' plugin. This can take a few minutes... > Installed the plugin 'vagrant-registration (1.2.1)'! > Tue, 26 Apr 2016 18:05:55 GMT-INFO: cdk - Execute vagrant plugin install "c:\sw\rhjbds\cdk\plugins\vagrant-registration-1.2.1.gem" SUCCESS > Tue, 26 Apr 2016 18:05:55 GMT-INFO: cdk - Execute command vagrant box remove cdkv2 -f > Tue, 26 Apr 2016 18:05:55 GMT-INFO: cdk - Execute options { > "env": { > "path": "C:\\HashiCorp\\Vagrant\\bin;C:\\Program Files\\Oracle\\VirtualBox\\;" > } > } > Tue, 26 Apr 2016 18:06:02 GMT-INFO: cdk - Removing box 'cdkv2' (v0) with provider 'virtualbox'... > Tue, 26 Apr 2016 18:06:02 GMT-INFO: cdk - Execute vagrant box remove cdkv2 -f SUCCESS > Tue, 26 Apr 2016 18:06:02 GMT-INFO: cdk - Execute command vagrant box add --name cdkv2 "c:\sw\rhjbds\cdk\boxes\rhel-vagrant-virtualbox.box" > Tue, 26 Apr 2016 18:06:02 GMT-INFO: cdk - Execute options { > "env": { > "path": "C:\\HashiCorp\\Vagrant\\bin;C:\\Program Files\\Oracle\\VirtualBox\\;" > } > } > Tue, 26 Apr 2016 18:06:10 GMT-ERROR: cdk - Error: Command failed: vagrant box add --name cdkv2 "c:\sw\rhjbds\cdk\boxes\rhel-vagrant-virtualbox.box" > The box failed to unpackage properly. Please verify that the box > file you're trying to add is not corrupted and try again. The > output from attempting to unpackage (if any): > x box.ovf > x Vagrantfile > x vagrant-virtualbox-box.vmdk: Write failed > x metadata.json > bsdtar.EXE: Error exit delayed from previous errors. > Tue, 26 Apr 2016 18:06:10 GMT-ERROR: cdk - The box failed to unpackage properly. Please verify that the box > file you're trying to add is not corrupted and try again. The > output from attempting to unpackage (if any): > x box.ovf > x Vagrantfile > x vagrant-virtualbox-box.vmdk: Write failed > x metadata.json > bsdtar.EXE: Error exit delayed from previous errors. > Tue, 26 Apr 2016 18:06:10 GMT-ERROR: cdk failed to install: Error: Command failed: vagrant box add --name cdkv2 "c:\sw\rhjbds\cdk\boxes\rhel-vagrant-virtualbox.box" > The box failed to unpackage properly. Please verify that the box > file you're trying to add is not corrupted and try again. The > output from attempting to unpackage (if any): > x box.ovf > x Vagrantfile > x vagrant-virtualbox-box.vmdk: Write failed > x metadata.json > bsdtar.EXE: Error exit delayed from previous errors. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23090) instead of running the getProjectRootPomParents.sh script on jenkins, reference it in the email

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23090?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-23090: ------------------------------------ Fixed - this commit comment should cause this JIRA to be auto-closed. > instead of running the getProjectRootPomParents.sh script on jenkins, reference it in the email > ----------------------------------------------------------------------------------------------- > > Key: JBIDE-23090 > URL: https://issues.jboss.org/browse/JBIDE-23090 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: build > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.2.AM1 > > > instead of running the getProjectRootPomParents.sh script on jenkins, reference it in the email so that Alexey or Jeff can run it locally in their /tmp folder > 1. script how to fetch jbosstools-build-ci > 2. script how to then run getProjectRootPomParents.sh -w1 /tmp/some-folder/ -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23091) use #close smart tag in commit messages so JIRAs are closed automatically

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23091?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-23091: ------------------------------------ For this to work, we will need to be able to run createTaskJIRAs.py 17 times (once per project) and for each one, return the ID of the generated JIRA. Then, we can use that JIRA number when calling getProjectRootPomParents.sh so that commit comments when making changes look like this: {code} git commit -m \"JBIDE-23091 #close bump up to parent pom version = $\{version_parent}\" {code} instead of {code} git commit -m \"bump up to parent pom version = $\{version_parent}\" {code} > use #close smart tag in commit messages so JIRAs are closed automatically > ------------------------------------------------------------------------- > > Key: JBIDE-23091 > URL: https://issues.jboss.org/browse/JBIDE-23091 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: build > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.2.AM1 > > > Rather than having to create and bulk-close 17 JIRAs, we should use smart commit msgs that cause JIRA workflow to close JIRAs automatically -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23029) Integration tests: Tests should be able to run individually

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23029?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-23029: ------------------------------------- Git Pull Request: https://github.com/jbosstools/jbosstools-integration-tests/pull/1609, https://github.com/jbosstools/jbosstools-openshift/pull/1322 (was: https://github.com/jbosstools/jbosstools-integration-tests/pull/1609, https://github.com/jbosstools/jbosstools-openshift/pull/1311) > Integration tests: Tests should be able to run individually > ----------------------------------------------------------- > > Key: JBIDE-23029 > URL: https://issues.jboss.org/browse/JBIDE-23029 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: openshift > Affects Versions: 4.4.1.AM3 > Reporter: Andre Dietisheim > Assignee: Andre Dietisheim > Labels: integration_tests > Fix For: 4.4.2.Final > > > We should be able to run the bot tests individually. Currently you cant because the suite is setting up requirements (ex. ScalingTest requires a connection. The connection though is set up in the CreateNewConnectionTest. You thus cant run ScalingTest only, you need to copy the suite, comment all the tests that you dont need). > This is even more true since running the whole suite is a lengthy task. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23091) use #close smart tag in commit messages so JIRAs are closed automatically

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23091?page=com.atlassian.jira.plugi... ] Nick Boldt reassigned JBIDE-23091: ---------------------------------- Assignee: Nick Boldt > use #close smart tag in commit messages so JIRAs are closed automatically > ------------------------------------------------------------------------- > > Key: JBIDE-23091 > URL: https://issues.jboss.org/browse/JBIDE-23091 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: build > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.2.AM1 > > > Rather than having to create and bulk-close 17 JIRAs, we should use smart commit msgs that cause JIRA workflow to close JIRAs automatically -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 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