July 2017 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-21796) [bzira] [jiralint] HTTP 400 errors creating ERT JIRAs from Eclipse BZ when BZ is in ASSIGNED state

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21796?page=com.atlassian.jira.plugi... ] Nick Boldt closed JBIDE-21796. ------------------------------ Resolution: Cannot Reproduce Haven't seen bzira crap out in ages, other than complaining about missing mappings, which are then added by hand. Last fix was on July 12 - don't throw an error when (auto)creating new versions: https://github.com/jbosstools/jiralint/commit/3adcd714a951d8cf6aba52176fd... So... I'm going to close this as cannot reproduce. > [bzira] [jiralint] HTTP 400 errors creating ERT JIRAs from Eclipse BZ when BZ is in ASSIGNED state > -------------------------------------------------------------------------------------------------- > > Key: JBIDE-21796 > URL: https://issues.jboss.org/browse/JBIDE-21796 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.3.1.CR1, 4.4.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.5.0.Final > > Attachments: bzira.log.txt > > > Was reported today that Eclipse bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=488373 was not created as an ERT issue. > So I re-ran bzira like this: > {code} > python -W ignore bzira.py -u JIRA_USER -p JIRA_PWD -s https://issues.jboss.org -S 2016-02-24 -v > {code} > And got this when creating ERT-82: > {code} > [INFO] Created https://issues.jboss.org/browse/ERT-82 > JiraError HTTP 400 > text: It seems that you have tried to perform a workflow operation (Start Progress) that is not valid for the current state of this issue (ERT-82). The likely cause is that somebody has changed the issue recently, please look at the issue history for details. > url: https://issues.jboss.org/rest/api/2/issue/ERT-82/transitions > {code} > Curiously, the same error was thrown when creating ERT-88: > {code} > [INFO] Created https://issues.jboss.org/browse/ERT-88 > > Jira ERT-82 gave following errors: > Could not perform transition{'id': '4'} error: JiraError HTTP 400 > text: It seems that you have tried to perform a workflow operation (Start Progress) that is not valid for the current state of this issue (ERT-82). The likely cause is that somebody has changed the issue recently, please look at the issue history for details. > url: https://issues.jboss.org/rest/api/2/issue/ERT-82/transitions > {code} > full log: [^bzira.log.txt] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21796) [bzira] [jiralint] HTTP 400 errors creating ERT JIRAs from Eclipse BZ when BZ is in ASSIGNED state

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21796?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-21796: ------------------------------- Fix Version/s: 4.5.0.Final (was: 4.4.x) > [bzira] [jiralint] HTTP 400 errors creating ERT JIRAs from Eclipse BZ when BZ is in ASSIGNED state > -------------------------------------------------------------------------------------------------- > > Key: JBIDE-21796 > URL: https://issues.jboss.org/browse/JBIDE-21796 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.3.1.CR1, 4.4.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.5.0.Final > > Attachments: bzira.log.txt > > > Was reported today that Eclipse bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=488373 was not created as an ERT issue. > So I re-ran bzira like this: > {code} > python -W ignore bzira.py -u JIRA_USER -p JIRA_PWD -s https://issues.jboss.org -S 2016-02-24 -v > {code} > And got this when creating ERT-82: > {code} > [INFO] Created https://issues.jboss.org/browse/ERT-82 > JiraError HTTP 400 > text: It seems that you have tried to perform a workflow operation (Start Progress) that is not valid for the current state of this issue (ERT-82). The likely cause is that somebody has changed the issue recently, please look at the issue history for details. > url: https://issues.jboss.org/rest/api/2/issue/ERT-82/transitions > {code} > Curiously, the same error was thrown when creating ERT-88: > {code} > [INFO] Created https://issues.jboss.org/browse/ERT-88 > > Jira ERT-82 gave following errors: > Could not perform transition{'id': '4'} error: JiraError HTTP 400 > text: It seems that you have tried to perform a workflow operation (Start Progress) that is not valid for the current state of this issue (ERT-82). The likely cause is that somebody has changed the issue recently, please look at the issue history for details. > url: https://issues.jboss.org/rest/api/2/issue/ERT-82/transitions > {code} > full log: [^bzira.log.txt] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22305) automate process for fetching latest target platform mirrors

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22305?page=com.atlassian.jira.plugi... ] Nick Boldt closed JBIDE-22305. ------------------------------ Resolution: Done As per JBIDE-19911, I'm going to mark this done. Job for mirroring TP reqs is now here: https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/jbosstoo... > automate process for fetching latest target platform mirrors > ------------------------------------------------------------ > > Key: JBIDE-22305 > URL: https://issues.jboss.org/browse/JBIDE-22305 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: target-platform, updatesite, upstream > Affects Versions: 4.4.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Labels: releasework > Fix For: 4.5.0.Final > > Attachments: git.diff.txt > > > Rather than manually pulling requirements, it would be hella sweet if there was a job config into which we could just list all the URLs to mirror and their matching project names. > Then this job would scrape the *.target files for the current list of URLs used, grep out the /requirements/<reqname>/<version>, fetch a new mirror for each new version*, and dump an updated copy of the .target file into the job's workspace. > Thus for webtools we might simply define: > webtools,S-3.8.0M7-20160503010110,http://download.eclipse.org/webtools/do... > and we'd end up with: > http://download.jboss.org/jbosstools/updates/requirements/webtools/S-3.8.... > * Since we already have a http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt... job we can just pass parameters to that to invoke the mirroring steps. Would be even better if we could run multiple calls in parallel as neon and wtp can take >2hr > 1. matrix job. each config is a trio of reqname/version/URL which is passed to a process akin to that of the jbosstools-requirements job to perform the mirror; process is now scripted here: https://github.com/jbosstools/jbosstools-build-ci/blob/jbosstools-4.4.x/p... > 2. when all children are done, a downstream job can runs TP update & validation against new .target files > * fetch http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstoolstargetplatf... > * parse that into a list of URLs > * each URL contains REQ_NAME/VERSION, which can then be matched up with similar lines in .target files > * run p2diff between old/new URLs in .target to generate list of changes and verify new site contains all the same IUs > * resulting edited .target files will remain in the workspace, and we can then run > * https://github.com/jbosstools/jbosstools-build-ci/blob/jbosstools-4.4.x/u... > * when done if success: > * ideally, generate a PR and attach link in email to jbosstools-dev@ > * if can't generate PR, then attach patch in email to nickboldt & mistria to apply locally in jbosstools-target-platforms to create a PR > * email should includes boilerplate text to send mail to list announcing new change for review -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22305) automate process for fetching latest target platform mirrors

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22305?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-22305: ------------------------------- Fix Version/s: 4.5.0.Final (was: 4.4.x) > automate process for fetching latest target platform mirrors > ------------------------------------------------------------ > > Key: JBIDE-22305 > URL: https://issues.jboss.org/browse/JBIDE-22305 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: target-platform, updatesite, upstream > Affects Versions: 4.4.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Labels: releasework > Fix For: 4.5.0.Final > > Attachments: git.diff.txt > > > Rather than manually pulling requirements, it would be hella sweet if there was a job config into which we could just list all the URLs to mirror and their matching project names. > Then this job would scrape the *.target files for the current list of URLs used, grep out the /requirements/<reqname>/<version>, fetch a new mirror for each new version*, and dump an updated copy of the .target file into the job's workspace. > Thus for webtools we might simply define: > webtools,S-3.8.0M7-20160503010110,http://download.eclipse.org/webtools/do... > and we'd end up with: > http://download.jboss.org/jbosstools/updates/requirements/webtools/S-3.8.... > * Since we already have a http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt... job we can just pass parameters to that to invoke the mirroring steps. Would be even better if we could run multiple calls in parallel as neon and wtp can take >2hr > 1. matrix job. each config is a trio of reqname/version/URL which is passed to a process akin to that of the jbosstools-requirements job to perform the mirror; process is now scripted here: https://github.com/jbosstools/jbosstools-build-ci/blob/jbosstools-4.4.x/p... > 2. when all children are done, a downstream job can runs TP update & validation against new .target files > * fetch http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstoolstargetplatf... > * parse that into a list of URLs > * each URL contains REQ_NAME/VERSION, which can then be matched up with similar lines in .target files > * run p2diff between old/new URLs in .target to generate list of changes and verify new site contains all the same IUs > * resulting edited .target files will remain in the workspace, and we can then run > * https://github.com/jbosstools/jbosstools-build-ci/blob/jbosstools-4.4.x/u... > * when done if success: > * ideally, generate a PR and attach link in email to jbosstools-dev@ > * if can't generate PR, then attach patch in email to nickboldt & mistria to apply locally in jbosstools-target-platforms to create a PR > * email should includes boilerplate text to send mail to list announcing new change for review -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-24748) Enable Show In Console for cdk 3

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24748?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-24748: ------------------------------------- [~mmalina] I investigated this a bit. It seems it *is* enabled, but only for a brief period ;) See... the show-in-console action is only enabled when: 1) The selection is non-null 2) The server is not stopped 3) The server has a 'launch' object 4) The launch isn't complete yet 5) And the launch has processes It turns out, once your startup command is completed, you can't show in console anymore. Now, I also noticed a bug... click a CDK server (stopped), and start it. Show-in-console will be disabled. Why? It seems it only re-computes the action's status as valid or invalid when you change the selection, regardless of whether the server has been asked to start or stop. The workaround here is to unselect (ctrl+click) the server, then select it again. The action will re-check itself and then become enabled. Awesome, huh? Now, I can probably submit a bugzilla entry for the 2nd bug, but the first probably isn't possible. The show-in-console action really shouldn't be enabled for a launch with no processes or all terminated processes. > Enable Show In Console for cdk 3 > -------------------------------- > > Key: JBIDE-24748 > URL: https://issues.jboss.org/browse/JBIDE-24748 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: cdk > Affects Versions: 4.5.0.AM2 > Reporter: Martin Malina > Assignee: Rob Stryker > > CDK 2 used the Terminal view, CDK 3 switched back to usiong Console view. So Show In Console on the server adapter should be enabled. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19911) Create a (manual) job to update a given 3rd-party project on TP

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19911?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-19911: ------------------------------------ The problem w/ automatically creating a PR is that often more things have to change/move than a simple version update. So while this new process might help for simple TP changes [1], it would fail for more complex ones [2]. [1] https://github.com/jbosstools/jbosstools-target-platforms/commit/43fa3eae... [2] https://github.com/jbosstools/jbosstools-target-platforms/commit/eb958eac... https://github.com/jbosstools/jbosstools-target-platforms/commit/1d8cbef2... https://github.com/jbosstools/jbosstools-target-platforms/commit/68033586... https://github.com/jbosstools/jbosstools-target-platforms/commit/d4182499... Since I'm the only person who ever initiates TP updates, and no one has complained that the process is too onerous since last summer, I'm going to assume our process here is adequate, and will close this. One improvement coming in the next sprint will be to eliminate the need to build BOTH a JBT and devstudio target platform, since they're now identical. See JBIDE-24772 > Create a (manual) job to update a given 3rd-party project on TP > --------------------------------------------------------------- > > Key: JBIDE-19911 > URL: https://issues.jboss.org/browse/JBIDE-19911 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Affects Versions: 4.3.0.Beta1 > Reporter: Mickael Istria > Assignee: Nick Boldt > Fix For: 4.5.0.Final > > > For 3rd-party sites that are regularly changing, we could provide a Jenkins job that would automatically update the .target and provide the pull request. > * Input: sourceSite, initialMirror (as found in .target), targetMirror > * Then > ** job mirros the sourceSite > ** job publishes (scp) it to targetMirror > ** job runs "sed s/initialMirror/targetMirror/" on multiple/*.target > ** job runs "mvn fix-version ..." on multiple/*.target > ** "mvn clean verify -Pmultiple2repo" on multiple/*.target > ** git add multiple/*.target; git commit -m "Update initialMirror to targetMirror"; git push origin HEAD:change-BUILD_NUMBER > ** p2diff > ** Put p2diff as a comment on PR: https://developer.github.com/v3/pulls/comments/#create-a-comment -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19911) Create a (manual) job to update a given 3rd-party project on TP

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19911?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-19911: ------------------------------- Fix Version/s: 4.5.0.Final (was: 4.4.x) > Create a (manual) job to update a given 3rd-party project on TP > --------------------------------------------------------------- > > Key: JBIDE-19911 > URL: https://issues.jboss.org/browse/JBIDE-19911 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Affects Versions: 4.3.0.Beta1 > Reporter: Mickael Istria > Assignee: Nick Boldt > Fix For: 4.5.0.Final > > > For 3rd-party sites that are regularly changing, we could provide a Jenkins job that would automatically update the .target and provide the pull request. > * Input: sourceSite, initialMirror (as found in .target), targetMirror > * Then > ** job mirros the sourceSite > ** job publishes (scp) it to targetMirror > ** job runs "sed s/initialMirror/targetMirror/" on multiple/*.target > ** job runs "mvn fix-version ..." on multiple/*.target > ** "mvn clean verify -Pmultiple2repo" on multiple/*.target > ** git add multiple/*.target; git commit -m "Update initialMirror to targetMirror"; git push origin HEAD:change-BUILD_NUMBER > ** p2diff > ** Put p2diff as a comment on PR: https://developer.github.com/v3/pulls/comments/#create-a-comment -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19911) Create a (manual) job to update a given 3rd-party project on TP

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19911?page=com.atlassian.jira.plugi... ] Nick Boldt closed JBIDE-19911. ------------------------------ Resolution: Done > Create a (manual) job to update a given 3rd-party project on TP > --------------------------------------------------------------- > > Key: JBIDE-19911 > URL: https://issues.jboss.org/browse/JBIDE-19911 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Affects Versions: 4.3.0.Beta1 > Reporter: Mickael Istria > Assignee: Nick Boldt > Fix For: 4.5.0.Final > > > For 3rd-party sites that are regularly changing, we could provide a Jenkins job that would automatically update the .target and provide the pull request. > * Input: sourceSite, initialMirror (as found in .target), targetMirror > * Then > ** job mirros the sourceSite > ** job publishes (scp) it to targetMirror > ** job runs "sed s/initialMirror/targetMirror/" on multiple/*.target > ** job runs "mvn fix-version ..." on multiple/*.target > ** "mvn clean verify -Pmultiple2repo" on multiple/*.target > ** git add multiple/*.target; git commit -m "Update initialMirror to targetMirror"; git push origin HEAD:change-BUILD_NUMBER > ** p2diff > ** Put p2diff as a comment on PR: https://developer.github.com/v3/pulls/comments/#create-a-comment -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-24772) eliminate devstudio target platform; reuse jbosstools target platform

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24772?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-24772: ------------------------------- Description: Now that jbosstoolstarget and jbdevstudiotarget are the same - JBDS-444- - we can eliminate one of them and simply reuse the same artifact in two places. Changes: * jbosstools-discovery repo - remove unneeded configuration / folders * job(s) that publish target platforms to dl.jb.o and ds.rh.com - copy the jbosstools TP to ds.rh.com instead of building a different one & publishing that * job(s) / release guide steps that rename/copy target platforms to staging / development / stable / static - change source of TPs to copy/rename to reuse the jbosstools artifacts * jbdevstudio-product/pom.xml - point at jbosstoolstarget instead of jbdevstudio one * refactoring as per JBDS-3894 * documentation as per JBIDE-23510 was: Now that jbosstoolstarget and jbdevstudiotarget are the same - JBDS-444- - we can eliminate one of them and simply reuse the same artifact in two places. Changes: * jbosstools-discovery repo - remove unneeded configuration / folders * job(s) that publish target platforms to dl.jb.o and ds.rh.com - copy the jbosstools TP to ds.rh.com instead of building a different one & publishing that * job(s) / release guide steps that rename/copy target platforms to staging / development / stable / static - change source of TPs to copy/rename to reuse the jbosstools artifacts * jbdevstudio-product/pom.xml - point at jbosstoolstarget instead of jbdevstudio one * refactoring as per JBDS-3894 > eliminate devstudio target platform; reuse jbosstools target platform > --------------------------------------------------------------------- > > Key: JBIDE-24772 > URL: https://issues.jboss.org/browse/JBIDE-24772 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, target-platform > Affects Versions: 4.5.0.Final > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.5.1.AM1 > > > Now that jbosstoolstarget and jbdevstudiotarget are the same - JBDS-444- - we can eliminate one of them and simply reuse the same artifact in two places. > Changes: > * jbosstools-discovery repo - remove unneeded configuration / folders > * job(s) that publish target platforms to dl.jb.o and ds.rh.com - copy the jbosstools TP to ds.rh.com instead of building a different one & publishing that > * job(s) / release guide steps that rename/copy target platforms to staging / development / stable / static - change source of TPs to copy/rename to reuse the jbosstools artifacts > * jbdevstudio-product/pom.xml - point at jbosstoolstarget instead of jbdevstudio one > * refactoring as per JBDS-3894 > * documentation as per JBIDE-23510 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23510) [devdoc] document sources in target platform zip & use of PDE Source Lookup feature

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23510?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-23510: ------------------------------- Fix Version/s: 4.5.1.AM1 (was: 4.4.x) > [devdoc] document sources in target platform zip & use of PDE Source Lookup feature > ----------------------------------------------------------------------------------- > > Key: JBIDE-23510 > URL: https://issues.jboss.org/browse/JBIDE-23510 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, devdoc, target-platform > Affects Versions: 4.4.2.AM3 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.5.1.AM1 > > > So that dev and qe can use Fred's PDE source lookup tool [1] to grab source bundles on demand (instead of having to build a target platform locally w/ all the sources [2]), we need to build a targetplatform with all the sources - done in JBIDE-23481. > [1] https://github.com/fbricon/pde.source.lookup/ > [2] https://github.com/jbosstools/jbosstools-devdoc/blob/master/building/targ... > Once we have sources in the JBT targetplatform repo, need to update devdoc [2] and add instructions (also write a blog!) about how to install/use the PDE Source Lookup plugin > 1. install the PDE source lookup plugin > 2. Window > Prefs > Update > Avail Software Sites > Add the new tp.source site > 3. for something you want sources, use the plugin and see if it can resolve sources -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 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 July 2017