Eclipse Community Forums: Hudson » Team concept and API access

Help

Home

Home » Archived » Hudson » Team concept and API access

Show: Today's Messages :: Show Polls :: Message Navigator

Team concept and API access [message #1184730]

Wed, 13 November 2013 16:55

Henrik Lynggaard Hansen

Messages: 8
Registered: November 2013

Junior Member

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)

Report message to a moderator

Re: Team concept and API access [message #1184930 is a reply to message #1184730]

Wed, 13 November 2013 19:59

Bob Foster

Messages: 85
Registered: January 2013

Member

Hi 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.

Thanks!

Bob

Report message to a moderator

Re: Team concept and API access [message #1184931 is a reply to message #1184930]

Wed, 13 November 2013 20:00

Bob Foster

Messages: 85
Registered: January 2013

Member

Forgot to mention. copy-job CLI command has also been modified to accept target team argument.

Bob

Report message to a moderator

Re: Team concept and API access [message #1184954 is a reply to message #1184930]

Wed, 13 November 2013 20:20

Henrik Lynggaard Hansen

Messages: 8
Registered: November 2013

Junior Member

Bob Foster wrote on Wed, 13 November 2013 14:59

Hi 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 Sad

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 Wink

(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?

Report message to a moderator

Re: Team concept and API access [message #1185227 is a reply to message #1184931]

Thu, 14 November 2013 00:25

Bob Foster

Messages: 85
Registered: January 2013

Member

As you may have noticed, I was wrong about the REST API knowing nothing about teams. Commands to create jobs and copy jobs have added a team parameter that allows you to specify the target team. I added the parameter myself to support other uses and never thought about it being available to REST.

Report message to a moderator

Re: Team concept and API access [message #1186716 is a reply to message #1185227]

Thu, 14 November 2013 21:11

Henrik Lynggaard Hansen

Messages: 8
Registered: November 2013

Junior Member

I think there is some confusion as to what API we are referring to. I reopened the bugreport with the following explanation.

As far as I can determine there are the following approaches to interacting with Hudson

1. Normal web gui of course
2. The Hudson CLI jar
3. The "original" XML/JSON api available by postfixing /api to urls like this localhost:8080/job/testjob/api/
4. The Rest plugin which I believe came from Sonatype available here localhost:8080/plugin/rest-plugin/api/index.html (if the plugin is installed)
5. The your_server/createItem approach mentioned in this bugzilla

The API I have been trying to use it #3, since this is the one used by jenkinsapi python wrapper. Despite the description on the api page it can also be used to create job and not just update jobs. Well except for when using teams

Option 4 I have never used since I never had the need to explore it.

Option 5 I haven't heard of until this bugreport and I have no idea how it works. Ihaven't been able to find any documentation on this, although I did find the following page www.eclipse.org/forums/index.php/t/487395/ where Winston writes "You should not use createItem directly. You should use the remote Access API as explained here wiki.hudson-ci.org/display/HUDSON/Remote+access+API. "

My bug is about supporting teams fully in option 3 and that is still an open issue.

Report message to a moderator

Re: Team concept and API access [message #1186791 is a reply to message #1186716]

Thu, 14 November 2013 22:02

Winston Prakash

Messages: 534
Registered: August 2011
Location: Fremont, CA USA

Senior Member

Henrik, my comment about "You should not use createItem directly" is a misunderstanding on my side. When you click on a "New Job" link it does GET on http://host:8080/createItem. I mean that.

You can create a job by doing a POST as Latha has successfully demonstrated the following (copied from 421671)

--->

This works for creating a job in a team:
curl -u user:pwd -X POST "http://host:8080/createItem?name=TeamJob&team=IDEQA" --data-binary "@config.xml" -H "Content-Type: text/xml"

This will use config.xml to create a team job in team 'IDEQA' named 'IDEQA.TeamJob' (fully qualified name)

<---

I doubt #3 will work for creating a job

3. The "original" XML/JSON api available by postfixing /api to urls like this http://localhost:8080/job/testjob/api/

Because the path http://localhost:8080/job/testjob will throw exception if the job does not exist already

So the correct way is #5

#3 you can use only for updating the existing config.xml. Following is the excerpt from http://localhost:8080/job/testjob/api/

"To programmatically obtain config.xml, use http://your_server/job/your_job_name/config.xml, (try it now!).
You can also POST an updated config.xml to the same URL to programmatically update the configuration of a job."

Winston Prakash
Eclipse Hudson team

Report message to a moderator

Re: Team concept and API access [message #1201646 is a reply to message #1186791]

Thu, 21 November 2013 21:20

Henrik Lynggaard Hansen

Messages: 8
Registered: November 2013

Junior Member

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

Report message to a moderator

Previous Topic:	Subversion，ERROR: hudson.model.Job.hasCascadingProject()Z
Next Topic:	antrun target 'unless' ignored

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 18 09:21:11 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter