Difference between revisions of "Hudson-ci/community meetings/Feb202012"

From Eclipsepedia

Jump to: navigation, search
Line 26: Line 26:
 
** plugin-tester (https://github.com/hudson-plugins/plugin-tester): My prototype for testing a plugin in hudson using selenium tests. Similar to hudson-test-ui except my version tests against multiple hudson cores, and allows each test class to specify which plugins should be installed.
 
** plugin-tester (https://github.com/hudson-plugins/plugin-tester): My prototype for testing a plugin in hudson using selenium tests. Similar to hudson-test-ui except my version tests against multiple hudson cores, and allows each test class to specify which plugins should be installed.
  
I suggest we look into unifying hudson-test-ui with my prototype, but where should it be located and which plugins should be tested?
+
I suggest we look into unifying hudson-test-ui with my prototype, but where should it be located and which plugins should be tested?. (and we should try to run the plugin's own tests against out hudson cores)

Revision as of 16:21, 19 February 2012

Hudson Continuous Integration Server
Website
Download
Community
Mailing ListForumsIRC
Bugzilla
Open
Help Wanted
Bug Day
Contribute
Browse Source
Hudson-bust.png Community Meeting 20-Feb-2012











Agenda

Add or comment on agenda items here, just prefix the item with your name so we can identify you on the call:

  • 2.x?
    • What is the status on the next release on the 2.x line?
  • 3.0.0
    • [susan] M2/M3 Release
    • [susan] Website and wiki
    • [susan] Initial Code Contribution
    • [susan] Issues migration
  • [Winston] Hudson performance in a enterprise installation, defining best practice, dedicating a release for performance analysis.
  • [Henrik] What are the core team's priorities besides the eclipse migration? upcoming features?
  • [Henrik] Out approach to scripting Hudson seems half-hearted at best, how do we improve this? (We need a unified way that plugins can easily attach themselves to)
    • CLI works: but is limited in its API plus requires special access through firewalls etc.
    • old "REST" api: I can configure a project, but it generally lacks in api
    • new "REST" api, I personally find it confusing, eg. there is a difference bewteen project/<id> and projects/<name> in the latter I can get the config, nodes doesn't support configuration at all.
  • [Henrik] Collaboration on testing the hudson UI. Right now we have several testing "frameworks" in play for hudson. Right now we have
    • hudson-test-framework (part of core): Don't know it but assume it is for plugin developers writing their own tests
    • hudson-test-harness: Extensive "white-box" testing of hudson
    • hudson-test-ui: Small selenium based testing package primarily for cascading projects
    • plugin-tester (https://github.com/hudson-plugins/plugin-tester): My prototype for testing a plugin in hudson using selenium tests. Similar to hudson-test-ui except my version tests against multiple hudson cores, and allows each test class to specify which plugins should be installed.

I suggest we look into unifying hudson-test-ui with my prototype, but where should it be located and which plugins should be tested?. (and we should try to run the plugin's own tests against out hudson cores)