Exposing Project Labels in the REST API

The intent here is to expose the tag_list property of the Project entity over the REST API so that any project searches include the information. The specific reason I've implemented this change is for an environment in which multiple gitlab servers exist, where a central portal to the projects that are spread around the network will be useful. Having access to filtering on this fairly large project list based on their labels, will be of great use.

This satisfies the feature request http://feedback.gitlab.com/forums/176466-general/suggestions/6325819-project-labels-via-api

The change was made in the lib/api/entities.rb file.

The output of a GET to something like /projects or /projects/7 is now:

{
  "id": 7,
  "description": "Veritatis est eaque voluptas magni expedita.",
  "default_branch": "master",
  **"tag_list": [
    "typeahead",
    "twitter"
  ],**
  "public": false,
  "archived": false,
  "visibility_level": 0,
  ...
}

Milestone removed

@cabkarian Can you please update the API documentation for this feature as well as adding a testcase to verify the feature?

Added 1 new commit:

• c4290f86 - Updated projects.md to show tag_list field when performing GETs

Added 1 new commit:

• 6eae64b3 - Fixed typo at projects.md

Added 1 new commit:

• 29fc10f1 - Updated projects_spec.rb to include check for tag_list key in project list

All done... Hopefully we can get this in soon, I'm ready to start using the feature from an official release.

Milestone changed to 7.9

@cabkarian Can you please fix the changelog so your line is added to the 7.9 release?

/cc @DouweM Can we still merge this for 7.9?

How do you want to do this? This came from 7.8 code so the changelog doesn't have a 7.9 section. You want me to fork 7.9, make all the changes again and issue a new merge request? Or is there some other simpler way?

• switch to the master branch and pull in the current master
• switch to feature_expose_project_labels branch
• git rebase master
• modify the CHANGELOG (line goes to the 7.10 release now)
• squash the commits with git rebase -i master

Added 1086 commits:

• 29fc10f1...6c1074e3 - 1080 commits from branch gitlab-org:master
• c9057fa7 - Modified lib/api/entities.rb to expose Project class tag_list property to the API
• 314902e7 - Updated projects.md to show tag_list field when performing GETs
• 58071ee6 - Fixed typo at projects.md
• 8f4b893a - Updated projects_spec.rb to include check for tag_list key in project list
• 8a53d5af - Moved changes into 7.10 section of the CHANGELOG
• ffd3df3a - Merge branch 'feature_expose_project_labels' of gitlab.com:cabkarian/gitlab-ce i…

My question wasn't how to do a rebase, it was how you guys handled the first bullet in your comment (pulling the current master into my fork). Regardless, It's up to date now, I hope you use it.

@cabkarian Sorry. To answer you question:
You can solve that by adding a new remote to your git repository. In this case:
git remote add upstream git@gitlab.com:gitlab-org/gitlab-ce.git
Then you can simply use git pull upstream master.

It seems something went wrong whith your last push. You now add 10 commits and have 2 lines in the CHANGELOG.
Can you please fix that? Sorry for the hassle.

Added 359 commits:

• ffd3df3a...0d0042d2 - 358 commits from branch gitlab-org:master
• dfd98a2e - Modified lib/api/entities.rb to expose Project class tag_list property to the API

Added 1 commit:

• eaef7b34 - Modified lib/api/entities.rb to expose Project class tag_list property to the API

Added 1 commit:

• 21b21895 - Modified lib/api/entities.rb to expose Project class tag_list property to the API

Added 1 commit:

• f0454905 - Modified lib/api/entities.rb to expose Project class tag_list property to the API

Sorry I forgot to squash. For some reason this rebase gave me a whole bunch of trouble, doesn't help that it's 4:30am either... Should be clean now, thanks.-

@haynes Looks good to me, merge if you agree :)

Status changed to merged