Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

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

(Agenda)
Line 20: Line 20:
 
** old "REST" api: I can configure a project, but it generally lacks in api
 
** 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.
 
** 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?

Revision as of 16:19, 19 February 2012

Hudson Continuous Integration Server
Website
Download
Community
Mailing ListForumsIRCmattermost
Issues
OpenHelp WantedBug 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?

Copyright © Eclipse Foundation, Inc. All Rights Reserved.