[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
[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
[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
[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
[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
[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