Team concept and API access [message #1184730] |
Wed, 13 November 2013 11:55  |
Eclipse User |
|
|
|
Hi
We are trying to upgrade to the team concept (we are already on 3.1.0), but we are having some issues with creation of the jobs using the xml API.
I think the main issue is that we haven't figured out how to place a job in a team when using the XML API. We have tried the following, all using HTTP POST of a config.xml as described in the built in help page .../api
1. Post to <Team name>.<Job name>: Server returns bad request or 404
2. Post to <Job name> using system admin account: Job ends up in public team (seems natural)
3. Post to <Job name> using team member: Jobs ends up in the first team hudson find him in.
Option 3 could in theory be used as a expensive workaround by having each hudson admin have a hudson account per team (5 people and 40 team= 200 accounts) it doesn't work because the API doesn't seem to respect the namespace.
If I load the job "Build_core" into "team_one" by using the "team_one_member" account, that loaded will go okay, but if I then try to load the job "Build_core" into "team_two" by using the "team_two_member" account, the loading will fail since the job is already present in team_one.
Maybe it is because the resulting job ("Build_core" in "team_one") does not get the team name as part job name i.e. the job name is "Build_core" not "team_one.Build_core"
One option which we haven't explored thoroughly is using option 2 during the initial job creation, move the jobs manually in the gui and then use "<Team name>.<Job name>" on subsequent updates.
Updating a job seem to work when using the full "<Team name>.<Job name>" it is only creation that fails.
When I say seems to it is because we have seen some corruption of the team/teams.xml where some jobs would be duplicated within a team. We haven't been able to nail down whether this happens during creation, update or deletion. (We also delete jobs through the API)
|
|
|
|
|
Re: Team concept and API access [message #1184954 is a reply to message #1184930] |
Wed, 13 November 2013 15:20   |
Eclipse User |
|
|
|
Bob Foster wrote on Wed, 13 November 2013 14:59Hi Henrik,
The REST API knows nothing about teams. So the behavior you describe, sys admin jobs go to public team and team member jobs go to first team found, is as planned. You can specify a particular team using, e.g., the create-job CLI command, which allows a team argument.
You might also want to look into the create-team, list-jobs and list-teams CLI commands for various aspects team management.
Please let us know of any duplicated jobs bugs you can reproduce in 3.1.0. We've fixed a few team bugs for 3.1.1, but I thought we'd gotten all those for 3.1.0.
Not really the answer I was hoping for 
I can understand the idea that sys admin jobs go to public, but the pick random team if user is member than more than one team I still consider a bug. randomness is hardly planned behaviour (I have created the following BugZilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=421671)
I don't think it would be too hard to support the team concept in xml API, all it need to do is look for a period sign in the job name and split it into team part and job part. I have created Bz https://bugs.eclipse.org/bugs/show_bug.cgi?id=421672 for this.
It is at good to know the CLI supports it, although at this point I would consider it a fallback since we migrated away from that and to the XML API given the performance problems of the CLI application.
When we last tested it, it took 5+ minutes to load a pipeline of ~50 jobs while the XML API does it in around 30 seconds.
Do you know if there has been any performance improvements on the CLI side?
|
|
|
|
|
|
Re: Team concept and API access [message #1201646 is a reply to message #1186791] |
Thu, 21 November 2013 16:20  |
Eclipse User |
|
|
|
I stand corrected, I always thought that jenkins API only used the XML and JSON API under <jobname>/api, because the last time it broke it wasa because api/python was no longer available. So I thought it used it for everything. but reading the code I see now that it does use option 5 for job creation.
Still think it is a problem that jobs land in a random team when none is specified but that is another less important bug
|
|
|
Powered by
FUDForum. Page generated in 0.03815 seconds