January 2014 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-4731) use p2.mirror w/ comparator to verify plugin/feature versions are correctly incremented between builds/baselines

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-4731?page=com.atlassian.jira.plugin... ] Mickael Istria updated JBIDE-4731: ---------------------------------- Labels: versioning (was: ) > use p2.mirror w/ comparator to verify plugin/feature versions are correctly incremented between builds/baselines > ---------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-4731 > URL: https://issues.jboss.org/browse/JBIDE-4731 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: build > Reporter: Nick Boldt > Assignee: Nick Boldt > Priority: Blocker > Labels: versioning > Fix For: 4.1.x, 4.2.x > > > This depends on having per-component builds and a buckminster/p2 aggregator to merge them into a single update site. > See http://aniefer.blogspot.com/2009/08/versioning-p2-slides-from-eclipsecon.... for details on using p2.mirror w/ a comparator -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15339) Create version/change auditor/reporting tool

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15339?page=com.atlassian.jira.plugi... ] Mickael Istria updated JBIDE-15339: ----------------------------------- Labels: versioning (was: ) > Create version/change auditor/reporting tool > -------------------------------------------- > > Key: JBIDE-15339 > URL: https://issues.jboss.org/browse/JBIDE-15339 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, updatesite > Affects Versions: 4.1.0.Final > Reporter: Nick Boldt > Assignee: Nick Boldt > Labels: versioning > Fix For: 4.2.x > > > Plugin/Feature Version Auditor > Goal: be able to more easily see if a feature or plugin needs to be upversioned > Goal: be able to more easily see if a commit in github has been built into the jars in an update site > Goal: be able to more easily see what has changed between two builds (with links to relevant Jenkins, JIRA, Github, upstream URLs, TP URLs) > Output: generate a report of: > plugins, features in JBT or JBDS by version, md5 #, JIRA #s related to latest commits, jenkins build IDs > Include URL links to content/metadata: Github, Jenkins, JIRA, dl.jb.org (upstream sites which feed the aggregates, target platforms, composites, etc.) > May also include some parallel work to provide improvements to QA's versionwatch tool (https://github.com/jbdevstudio/jbdevstudio-qa/tree/master/vwatch ) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15472) Improve visibility for developers when test failures persist for multiple builds (Jenkins emails are ignored)

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15472?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-15472: ---------------------------------------- I also believe that Jenkins mailing should be enough, but it seems to me that some people ignore or automatically route those emails so they don't see them. Some months ago, we configured jobs so that the "component owner" for the job automatically receives a mail in case of failure (additionally to those who contributed changes and jbosstools-dev). Some people react to those mails, some other seem to not notice them. > Improve visibility for developers when test failures persist for multiple builds (Jenkins emails are ignored) > ------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-15472 > URL: https://issues.jboss.org/browse/JBIDE-15472 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: build > Reporter: Nick Boldt > > First iteration: https://issues.jboss.org/browse/JBIDE-15470, as generated by this: https://github.com/jbdevstudio/jbdevstudio-ci/blob/master/bin/createTestF... > [~maxandersen] said: > {quote} i would put the details in attachment i think. its a bit overloaded otherwise I think, > btw. is this something you will run when you find a failed buid or did you say you would detect when hit a certain amont of fail you generate it ? > if auto generated shuold take care to not keep opening new jiras again andagain ;) > maybe add a "watermark" to detect stil open test failure jiras > {quote} > Idea here is to run this tool as needed when I notice that builds which are supposed to be frozen and stable are showing test failures persisting for multiple builds. Could also run against master jobs, but less critical. > Not sure what you mean by a watermark, or how that would be implemented. Please elaborate. > As this is purely a workflow optimization, it does NOT affect docs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15483) generate content in staging/_composite_/core/{trunk, 4.1.kepler} based on new builds/staging/{JOB_NAME}/{BUILD_ID_N} and builds/staging/{JOB_NAME}/{BUILD_ID_N-1}

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15483?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-15483: ---------------------------------------- Shouldn't it be closed as a "won't fix" as a consequence of JBIDE-16309 ? > generate content in staging/_composite_/core/{trunk,4.1.kepler} based on new builds/staging/{JOB_NAME}/{BUILD_ID_N} and builds/staging/{JOB_NAME}/{BUILD_ID_N-1} > ---------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-15483 > URL: https://issues.jboss.org/browse/JBIDE-15483 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: build > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.2.x > > > Because the content in builds/staging/\{JOB_NAME}/all/repo/ and builds/staging.previous/\{JOB_NAME}/all/repo/ is moving to builds/staging/\{JOB_NAME}/\{BUILD_ID_N} and builds/staging/\{JOB_NAME}/\{BUILD_ID_N-1}, we need to generate a list of matching build URLs for inclusion in the composite*.xml files, perhaps based on a template that's stored in github (to define which projects to include). > Parameters to the generation would need to be: > a) template > b) number of builds per project to include (1, for stable_branch or 2, for trunk) > Constraints: > * Need to ensure that the generated files are always fresher than anything pulled from github via rsync, so templates should not be called "compositeContent.xml" but rather "compositeContent.template.xml" > * Need to be able to run this regeneration as a Jenkins job, perhaps as the first step in https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite... and https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite... > Worries: > * What happens if the regen happens and then a jbosstools-cleanup.sh fires minutes later, wiping out that N-1 build? Does jbosstools-cleaup.sh need to regen these files too? > Default operation of jbosstools-cleanup.sh as called from publish_new.sh and publish.sh is to keep the last 5 builds and anything newer than 5 days old; if there are no such builds, it will always keep the last build in a folder: > {code}./jbosstools-cleanup.sh --keep 5 --age-to-delete 5 --childFolderSuffix /all/repo/{code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15918) Could Jenkins perform tagging of its own repo?

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15918?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-15918: ---------------------------------------- > My thinking on this is to keep it simple A script, a new repo, some new UI entries doesn't seem simple to me ;) > check which exact commits was used for a build That's already possible just by looking at the build page. I don't see how adding scripts and so on would make things simpler than looking at a page and using "git tag...; git push...". The only difference with what you suggest is that CI builds are not kept forever. IMO, the problem to solve here is not that things are technically complicated to do, it's just that people don't think about it. Tagging or promoting a tag will always require a manual step from devs. If they forget to tag things, they'll also easily forget to promote stuff. > Could Jenkins perform tagging of its own repo? > ---------------------------------------------- > > Key: JBIDE-15918 > URL: https://issues.jboss.org/browse/JBIDE-15918 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.1.1.Beta1 > Reporter: Nick Boldt > Priority: Minor > > [~maxandersen] said: > {quote} > Project leads, please tag your projects! > {code} > co jbosstools-4.1.1.Beta1x > git tag jbosstools-4.1.1.Beta1 > git push origin jbosstools-4.1.1.Beta1 > {code} > {quote} > Then asked: > {quote} > Really would be nice if jenkins could just make such tags in its own repository and we could move the exact commit over from the "build" repository to the master repository. > {quote} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-16158) Investigate tools/processes to "templatize" CI jobs

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-16158?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-16158: ---------------------------------------- See related request on Jenkins: https://issues.jenkins-ci.org/browse/JENKINS-21380 > Investigate tools/processes to "templatize" CI jobs > --------------------------------------------------- > > Key: JBIDE-16158 > URL: https://issues.jboss.org/browse/JBIDE-16158 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: build > Reporter: Mickael Istria > Assignee: Max Rydahl Andersen > Fix For: 4.2.x > > > Found something a bit more complete than the maven plugin - haven't tried it yet but its examples looks extremely clean. > python script for creating jobs (linked to puppet but can be used standalone) > http://ci.openstack.org/jenkins-job-builder/installation.html > Example: https://github.com/adaptivelab/jenkins-build/blob/develop/template.yaml > Article: http://techs.enovance.com/6006/manage-jenkins-jobs-with-yaml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-16214) Code Coverage jobs needs to have locally available measured plugins

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-16214?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-16214: ---------------------------------------- I think you need to investigate about which jars does Sonar use to generate the jacoco reports. The best value is to use the classpath computed by Maven (which are the actual jars used by the tests), but it's possible that Sonar simply uses the jars of the modules in target/. If it is so, this can probably be a bug to report directly to Sonar. > Code Coverage jobs needs to have locally available measured plugins > ------------------------------------------------------------------- > > Key: JBIDE-16214 > URL: https://issues.jboss.org/browse/JBIDE-16214 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: build > Affects Versions: 4.1.1.CR1 > Reporter: Vlado Pakan > Assignee: Mickael Istria > Fix For: 4.1.x > > > Code Coverage calculating via maven build returns 0% coverage because it's using source code and binary plugins installed from update site. > When these are built locally prior to build calculating code coverage it returns correct results. > Unfortunately sometimes maven build used plugins installed from update site instead of those which are locally build. > We need to find way how to fix this. > It's already reported here https://bugs.eclipse.org/bugs/show_bug.cgi?id=352560 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-16262) README.md still points to community.jboss.org

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-16262?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-16262: ---------------------------------------- Not merged: * Birt * Forge * Server > README.md still points to community.jboss.org > --------------------------------------------- > > Key: JBIDE-16262 > URL: https://issues.jboss.org/browse/JBIDE-16262 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Reporter: Mickael Istria > Priority: Minor > Fix For: 4.2.0.Alpha2 > > > README.md still point to community.jboss.org, which isn't up to date and nor maintained any more. > Those files should be updated to point to https://github.com/jbosstools/jbosstools-devdoc -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-16376) Disabled "fetch-zips" on aggregate

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-16376?page=com.atlassian.jira.plugi... ] Mickael Istria resolved JBIDE-16376. ------------------------------------ Assignee: Mickael Istria Resolution: Won't Fix This does not seem to be something we need to work on. > Disabled "fetch-zips" on aggregate > ---------------------------------- > > Key: JBIDE-16376 > URL: https://issues.jboss.org/browse/JBIDE-16376 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.2.0.Alpha2 > Reporter: Mickael Istria > Assignee: Mickael Istria > Fix For: 4.2.0.Alpha2 > > > As a consequence of changes for JBIDE-16309, the Maven mojo which fetches zip from aggregate files doesn't work any more. > So I disabled it (added fetch-zips-for-aggregate.skip=true ). We should decide whether to keep this or not. It seems to me that so far, the individual zips have not been used often, so we may be able to get rid of it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-16220) create an all-in-one build for JBT projects, using submodules

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-16220?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-16220: ---------------------------------------- The job is configured to run tests, which makes it much longer than a "simple" build. IMO, * either the job should skip tests, or * the timeout should be longer (I'd bet about 8 to 10 hours). > create an all-in-one build for JBT projects, using submodules > ------------------------------------------------------------- > > Key: JBIDE-16220 > URL: https://issues.jboss.org/browse/JBIDE-16220 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.2.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.2.x > > Attachments: buildlog_maven311.txt > > > Git 1.8.2 includes an option to have submodules track a branch tip, rather than specific commit IDs. > {code:title=https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.2.txt#L186-L188} > "git submodule" started learning a new mode to integrate with the > tip of the remote branch (as opposed to integrating with the commit > recorded in the superproject's gitlink). > {code} > Therefore, while the solution [~dgolovin] has for his https://github.com/dgolovin/jbosstools-submodules project is a decent option, it requires updating to stay current with branch tips. It's therefore only really as useful as it stays current. > If we can get Git 1.8.2 or newer installed on the Jenkins slaves, we could do a submodule build against whatever branch we wanted - master, 4.2.0.Alpha1x, etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 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 January 2014