Gogs: REST API

[nasali]

Currently, the REST API exposed by Gogs, at /api/v1/, is limited. Please provide CRUD (Create, Read, Update, and Delete) methods to manipulate the following models:

• [x] User
• [ ] Org
• [ ] Repo
• ?Access

Thank you so much in advance!

[matrixise]

When do you think to release 0.7.0 ?

[unknwon]

@matrixise fairly a long time from now...

[ZUNbado]

i am very interested on these options, basically create users and repos by Rest API, for if more comments on this issue sums more points to make this changes :)

[jpiontek]

This would be really useful.

[mcumello]

+1 thank you

[techzilla]

Definitely would be a huge benefit to have the administrative parts of the v3. I'm working on getting a lot of teams migrated to using gogs, and away from old-school manual git on file-system.

[chasinglogic]

+1

Is the current rest api documented anywhere?

[unknwon]

@ChasingLogic https://github.com/gogits/go-gogs-client/wiki

[kernel164]

+1

[kernel164]

These are the apis that we currently need. (we use phantomjs to script the gogs, but if its available as api it would be cool)

all apis are done by admin (using api token)

• [-] add auth source (we use pam)
• [x] create user under the auth source
• [x] add ssh key to user
• [x] create org
• [x] create repo under the org (I believe this is already there)
• [x] create team under the org
• [x] add user to team
• [x] remove user from team
• [x] add repo to team
• [x] remove repo from team

This one is for easy config manage gogs from ansible.

• api for /install (we config manage app.ini so most of the fields shown in /install page is from app.ini except admin user name & password)

[rogeriolino]

Are plan to implement issues management routes?

[unknwon]

@rogeriolino Those should come with https://github.com/gogits/gogs/issues/809

[rogeriolino]

Thanks for reply me @Unknwon

This migration will include issues API too?

I'm already using Gogs in my work and I'm intending to code a frontend that integrate to gogs issues via API. Providing to my app users a way to report bugs without create a account into Gogs.

Regards.

[unknwon]

@renatoaquino

This migration will include issues API too?

I'm planning do migration with APIs, that's more flexible.

I'm already using Gogs in my work and I'm intending to code a frontend that integrate to gogs issues via API. Providing to my app users a way to report bugs without create a account into Gogs.

Though you still need an account to call APIs, just make sure you know this...

[rogeriolino]

@Unknwon

Though you still need an account to call APIs, just make sure you know this...

Right. Internally I'll use an account to do it (make API requests).

[unknwon]

@kernel164 https://github.com/gogits/go-gogs-client/wiki/Administration-Users

BTW, I'll try to make an other mirror update release before 0.8, other org-related APIs need to wait until 0.8.x releases. :sweat:

[kernel164]

Thank you.

[unknwon]

FYI: Users Emails APIs are done: https://github.com/gogits/go-gogs-client/wiki/Users-Emails

[kernel164]

I was proposing gogs instead of gitlab. The only issue that blocks my proposal is gogs missing API support. Hmm.... These api's are high priority for me.

• create org
• create team under the org
• add user to team
• add repo to team

all api are admin api.

[unknwon]

@kernel164 working on that. Note that checklist was already made in your previous comment, commenting duplicated things cause big confusion.

[yurivict]

Support of some parts of GitHub API would be nice: https://developer.github.com/v3/
Particularly Commits API: https://developer.github.com/v3/repos/commits/ is useful.

[kernel164]

Cool. Thanks.

[unknwon]

@kernel164 rest of your requests hopefully can be done before next minor release on this Saturday.

[kernel164]

Are these api's "create team under the org, add user to team, add repo to team" planned for next release.

[unknwon]

Are these api's "create team under the org, add user to team, add repo to team" planned for next release.

Depends on how much time I get...

[dakira]

Any update on creating issues via API? I'm in the same boat as @rogeriolino. I need an interface for my users to create issues.

[unknwon]

Basic CRUD for issues: https://github.com/gogits/go-gogs-client/wiki/Issues

[richmahn]

@Unknwon This commit mentioned above causes develop branch to not be able to compile:

routers/api/v1/convert/convert.go:200: undefined: gogs.Team
routers/api/v1/convert/convert.go:201: undefined: gogs.Team

[dakira]

@richmahn
you probably haven't pulled in all changes.

git pull --all
go get -u ./...
go build

[richmahn]

Ah, right, keep forgetting the go get -u. Sorry about that. Thanks for your help.

[iwanbk]

@Unknwon i'd like to contribute to issues API implementation, is someone working on it? (I know you have implemented basic issues API functionalities.)

From https://github.com/gogits/go-gogs-client/wiki, there are four things to implement:

1. assignees
   
   
   
   • from the code, it already implemented in create, edit, and get
   
   
   • do we need to list all assignees of a repo's issue? i don't think so
   
   
   • any other things to implement?
   
   
2. comments
   still not implemented at all, APIs to implement:
   
   
   
   • GET /api/v1/repos/:username/:reponame/issues/:index/comments to get all comments of an issue
   
   
   • POST /api/v1/repos/:username/:reponame/issues/:index/comments to create comment
   
   
   • PATCH /api/v1/repos/:username/:reponame/issues/:index/comments to edit comment
   
   
3. labels
   
   
   
   • already implemented in create and get an issue
   
   
   • need to implement in edit an issue
   
   
   • need POST, GET, and PATCH /api/v1/repos/:username/:reponame/labels to create, get, and edit labels of a repo's issue
   
   
4. milestones
   
   
   
   • already implemented in create, edit, and get an issue
   
   
   • need POST, GET, and PATCH /api/v1/repos/:username/:reponame/milestones to create, get, and edit milestones of a repo's issue
   
   

I'd like to implement all above points, but i think it is better to start small, implementing a point first. If you are OK then we can continue to other points.

I think comments API is a good start, what do you think?

[unknwon]

@iwanbk

I think comments API is a good start, what do you think?

Yes, I think so too.

[yurivict]

What about pull requests?

[unknwon]

What about pull requests?

@yurivict eventually...

[iwanbk]

@yurivict @Unknwon
PRs submitted:

• client lib : https://github.com/gogits/go-gogs-client/pull/26
• server side implementation : https://github.com/gogits/gogs/pull/2966, it depends on client lib

[lstahlman]

I would like to assist with this as well.

I started working on extra labels support before I saw @iwanbk's list, so hopefully my work is not overlapping.

[iwanbk]

@Unknwon i will work on issue's assignee support, it seems there is no one working on it.

[unknwon]

@iwanbk isn't API already supports issue assignee?

[iwanbk]

@iwanbk isn't API already supports issue assignee?

Yes, issue already has assignee.
But there is also assignee API, see https://developer.github.com/v3/issues/assignees/

[unknwon]

@iwanbk Gogs only supports single assignee right now, so I don't think we need that list of APIs at current stage.

[iwanbk]

Gogs only supports single assignee right now

If you talk about List assignees, it actually list a repo's assigness, not an issue's assignee.

GET /repos/:owner/:repo/assignees

If you think this API is not important right now, i offer my help to other APIs.

How about the Administration API? Organizations and Repositories API seems still not complete.

[iwanbk]

Another thing to do related REST API is testing code, i don't see any test in the API code.

I think we should write common test code first that the API contributors can use it.

[unknwon]

If you talk about List assignees, it actually list a repo's assigness, not an issue's assignee.

@iwanbk oh you're right, I mislead by the page title. Yes, you can implement ones for repository.

[einarf]

This might be the wrong place, but I'll add a few cents. (I can create a separate issue if needed)

It would be fantastic if the organization could also return its owners so we remotely can know what users are allowed to create repos in the organization. At least for the users that are allowed to see this information.

{
  "id": 6,
  "username": "gogs",
  "full_name": "Gogs",
  "avatar_url": "/avatars/6",
  "description": "Gogs(Go Git Service) is a painless self-hosted Git Service.",
  "website": "https://gogs.io",
  "location": "USA"
  "owners": [{"id": 9, "username": "foo",. ..}, {"id": 10, "username": "bar", ...}, ...]
}

.. or at least for an admin endpoint that can fetch info from any organization info. That way we can know remotely what users can create repositories in the organization.. or maybe this is something that should be queried through teams.

Right now when looking at existing repos, I don't know if it's possible to separate a team admin and an owner.

[pyhedgehog]

Please add API for POST /api/v1/repos/:owner/:repo/forks. It's very important feature.

[psaavedra]

is there any chance to collaborate and contribute with this feature?

[estan]

Since I haven't seen it mentioned here, I'd like to add:

• [ ] Releases

That is, I'd like to be able to draft a release, including file attachments, using the API. It would be very convenient (e.g. as part of a CI job that builds packages (windows .exe, macOS .dmg et.c.)) to create a draft release using the REST API and attach those files.

[jannishuebl]

Hello, are there plans to add support for the https://developer.github.com/v3/git/ api?

We would really love to see support for querying our repositories.

Thank you so much for gogs btw. :)

[IssueHuntBot]

@0maxxam0 has funded $20.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

[achilleas-k]

Org and team management endpoints are currently available only for site admins (under the /admin path). I think these should be made available for all org owners.

I can prepare a PR if you agree.