Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Europa Build Workshop Breakout Results"
(→Build Best Practices Breakout) |
m (→RSS) |
||
| Line 29: | Line 29: | ||
==RSS== | ==RSS== | ||
| − | + | * One artefact of an EMF build (Thu 00:00 EDT) being promoted (Thu 01:00 EDT) is that an RSS file is updated and scp'd to download.eclipse.org | |
| − | * | + | * UML consumes the RSS feed to trigger a new build (Thu 03:00 EDT) |
| − | * UML consumes the RSS to trigger a new build | + | |
* Platform will be publishing RSS soon (very soon) | * Platform will be publishing RSS soon (very soon) | ||
| − | * UML assumes a linear ordering (reads just one feed, not many feeds) | + | * UML assumes a linear ordering (reads just one feed, not many feeds, since it depends on EMF which in turn depends on Eclipse) |
| − | * RSS | + | * RSS feed supports a variety of status codes: build done, tests done, etc. though a definitive list has yet to be stated. |
| − | * RSS is on a download site so that mirrors will be updated with files and then the RSS | + | ** This is a TODO for Nick to define the spec, though I'm of course open to suggestions to make the spec useful to all |
| − | * RSS is committed to CVS for history | + | * RSS is on a download site so that mirrors will be updated with files and then the RSS - as such, you can watch a given mirror's copy of the feed in order to know when the mirror's got new upstream project bits on which you depend |
| − | * Dennis and Nick recommend | + | * RSS is committed to CVS for history/auditing |
| − | * Nick is willing to be the point person for initial communication | + | * Dennis and Nick recommend this should be adopted for cross-project notifications (and optionally response) by Europa projects to try it, use it and improve it |
| + | * Nick is willing to be the point person for initial communication, documentation, assistance | ||
* Which builds to publish for? nightly? integration? good? failed? | * Which builds to publish for? nightly? integration? good? failed? | ||
** Kim brings up "how to define what 'good' is - what if it was a test fixture failure (as determined by a human) instead of a test failure - then the human says 'this is a good build' and yet the RSS says 'bad'". | ** Kim brings up "how to define what 'good' is - what if it was a test fixture failure (as determined by a human) instead of a test failure - then the human says 'this is a good build' and yet the RSS says 'bad'". | ||
** Bjorn argues for more information rather than less - let the downstream consumers decide what to do with the extra information (e.g., ignore nightly builds, ignore bad builds, ...) | ** Bjorn argues for more information rather than less - let the downstream consumers decide what to do with the extra information (e.g., ignore nightly builds, ignore bad builds, ...) | ||
| + | ** As such, we would suggest that if you publish a build, it should includes an RSS entry (be it of type N or I/M or S or R). Build status in the feed (PASSED, FAILED, IN PROGRESS, PENDING, UNKNOWN, etc.) can default to a given state and be updated as needed by Ant tasks | ||
Additional information including implementation details and RSS feed schema [[Eclipse_Build_Available_RSS_Feeds | | Additional information including implementation details and RSS feed schema [[Eclipse_Build_Available_RSS_Feeds | | ||
can be found here]]. | can be found here]]. | ||
| + | |||
| + | I'll provide the working implementations for EMF and UML2 shortly. In the meantime, check out the [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.releng.basebuilder/plugins/org.eclipse.build.tools/?hideattic=0&only_with_tag=releng_test examples in CVS] | ||
| + | |||
| + | --[[User:Codeslave.ca.ibm.com|nickb]] | ||
==Nick's Tools== | ==Nick's Tools== | ||
Revision as of 02:11, 13 September 2006
Build Best Practices Breakout
(computer crashed in the middle of typing in the result)
- Proper version numbering
- Making builds reproducible
- Tag files from each release with the same human-readable tag
- Track API changes
- avoid circular dependencies
- documentation up-to-date; current link available on website; remove old contents
- backup redundant systems
- separate publishing script from “build” (compilation)
- able to turn functions on the build on or off e.g. turn off publishing
- regularly scheduled builds
- public humiliation
- send email to mailing list
- send email to plug-in owner
- have an update site; optimize update sites
- pack 200
- feature design – group plug-ins based on functional grouping
Buckminster/Maven
- Common model
- Backbone
- Graphical model input
- Buckminster and Buckminster model
- Maven in Eclipse and Maven model
- Maven
- Suggest that they adopt a Europa project and help revise that project's build. Nick volunteered one of the smaller EMFT projects; another candidate is BIRT (Sue); don't want to take on too much - want one/few good success stories rather than broad swath of mediocrity
- Document the process as a part of working with one of the projects.
RSS
- One artefact of an EMF build (Thu 00:00 EDT) being promoted (Thu 01:00 EDT) is that an RSS file is updated and scp'd to download.eclipse.org
- UML consumes the RSS feed to trigger a new build (Thu 03:00 EDT)
- Platform will be publishing RSS soon (very soon)
- UML assumes a linear ordering (reads just one feed, not many feeds, since it depends on EMF which in turn depends on Eclipse)
- RSS feed supports a variety of status codes: build done, tests done, etc. though a definitive list has yet to be stated.
- This is a TODO for Nick to define the spec, though I'm of course open to suggestions to make the spec useful to all
- RSS is on a download site so that mirrors will be updated with files and then the RSS - as such, you can watch a given mirror's copy of the feed in order to know when the mirror's got new upstream project bits on which you depend
- RSS is committed to CVS for history/auditing
- Dennis and Nick recommend this should be adopted for cross-project notifications (and optionally response) by Europa projects to try it, use it and improve it
- Nick is willing to be the point person for initial communication, documentation, assistance
- Which builds to publish for? nightly? integration? good? failed?
- Kim brings up "how to define what 'good' is - what if it was a test fixture failure (as determined by a human) instead of a test failure - then the human says 'this is a good build' and yet the RSS says 'bad'".
- Bjorn argues for more information rather than less - let the downstream consumers decide what to do with the extra information (e.g., ignore nightly builds, ignore bad builds, ...)
- As such, we would suggest that if you publish a build, it should includes an RSS entry (be it of type N or I/M or S or R). Build status in the feed (PASSED, FAILED, IN PROGRESS, PENDING, UNKNOWN, etc.) can default to a given state and be updated as needed by Ant tasks
Additional information including implementation details and RSS feed schema can be found here.
I'll provide the working implementations for EMF and UML2 shortly. In the meantime, check out the examples in CVS
--nickb
Nick's Tools
Nick shows off new Search CVS tool for browsing CVS and Bugzilla. (This tool is also linked from our generated release notes.) If you'd like your project indexed in this database, add your name and /cvsroot/path/to/project(s) here. I'll update this when you're indexed so you can play with it.
- org.eclipse.corona
- org.eclipse.emf, org.eclipse.emf.releng.build, org.eclipse.emf.ecore.sdo, org.eclipse.xsd
- org.eclipse.emft
- org.eclipse.gmf
- org.eclipse.uml2, org.eclipse.uml2.releng
- www
- emf
- emft
- uml2