Implement Commit Status API
This is preliminary implementation of Commit Status API, pretty much compatible with GitHub.
1. The Commit Statuses are stored in separate table: ci_commit_status.
2. The POST inserts a new row.
3. To POST execute GitLab API `post :id/repository/commits/:sha/status`. This accepts dual authorization:
- Using authorized user
- Using ci-token to allow easy posting from CI Services
4. This adds predefined variable to GitLab CI build environment: CI_BUILD_STATUS_URL, allowing to easy post status from within build (ex. with code coverage or other metrics).
5. This adds statuses to commit's builds view.
6. The commit's status is calculated taking into account status of all builds and all posted statuses.
7. The commit statuses doesn't trigger notifications.
8. The commit status API introduces two new privileges: `read_commit_statuses` and `create_commit_status`.
9. We still miss a few tests and documentation updates for API and CI.
@dzaporozhets @sytses What do you think?
See merge request !1530
LDAP email address downcasing
Fixes#2960
In the event we cannot match an LDAP user by DN we attempt to find an identity by email address and then update the DN. In this case the identity is matched by email address.
If the user's email address in LDAP has an upper case character we cannot find a match in the GitLab database. GitLab downcases emails before the user object is saved.
This merge request downcases the email from LDAP before we lookup by email. I also added a test to prevent a regression.
See merge request !1550
By using a JOIN we can remove the need for using 2 separate queries to
find a project by its namespace. Combined with an index (only needed for
PostgreSQL) this reduces the query time from ~245 ms (~520 ms for the
first call) down to roughly 10 ms (~15 ms for the first call).
Cleanup CI pages
- [x] Remove `ci/projects/:id` page
- [x] Remove Continuous integration from project menu
- [x] Remove unused css/js
- [x] Remove Ci::Commit and Ci::Build controllers
- [x] Move CI services to project settings area
cc @ayufan
Part of #2594
See merge request !1529
Change "+" icon under "Files" section to have three options:
* Create file
* Upload file
* New directory
Upload file is no longer accessible from the "Create file" page.
Users can now select a target branch in upload file as well.
Closes#2799: Fixes a bug where file modes were overwritten after a commit
Closes https://github.com/gitlabhq/gitlabhq/issues/8253: Existing files
can no longer be overwritten in the "Create file" section.
Closes#2557
This changes the query to use a COUNT nested in an INNER JOIN, instead
of a COUNT plus a GROUP BY. There are two reasons for this:
1. Using a COUNT in an INNER JOIN can be quite a bit faster.
2. The use of a GROUP BY means that method calls such as "any?"
(and everything else that calls "count") operate on a Hash that
counts the amount of notes on a per project basis, instead of just
counting the total amount of projects.
The query has been moved into Project.trending as its logic is simple
enough. As a result of this testing the TrendingProjectsFinder class
simply involves testing if the right methods are called, removing the
need for setting up database records.
Refactor Ci::Commit and Ci::Build to have all builds for same :sha on single page
This makes Ci::Commit to have only :sha and simplifies routing to have only :sha in path. The :ref and :push_data is now parameter of Ci::Build.
All commit related data (git author, message and .gitlab-ci.yml) is read directly from repository.
All code related for creating builds is moved to CreateBuildsService.
Status deduction is rewritten to make if more efficient and easier to integrate with Commit Status API.
This is partially working, tests are not yet touched.
This slightly changes view of Commit:
@dzaporozhets What do you think?
See merge request !1502
Basic RSpec/benchmark-ips powered benchmark suite
Corresponding issue: #2909, see the commit messages for more details.
A few things to note:
1. The current use of `subject` isn't exactly easy on the eyes due to them having to return a Proc, I'm not sure yet how (and if) we can work around this.
2. The maximum amount of iterations in the current `User.by_login` benchmark is arbitrary, we might have to adjust it once said method's performance has been improved.
3. Benchmarks currently take 2 seconds to warm up and 5 seconds to run (benchmark-ips defaults).
4. The custom RSpec matcher file (`benchmark_matchers.rb`) is a bit messy, any feedback on this would be appreciated
Any comments/feedback on this would be greatly appreciated.
See merge request !1503
Alex Lossent
Stan Hu
Dmitriy Zaporozhets
Kamil Trzciński
Valery Sizov
Robert Speicher
Robert Speicher
Ben Boeckel
Drew Blessing
Yorick Peterse
