This ensures that Project.find_with_namespace returns a row matching
literally as the first value, instead of returning a random value.
The ordering here is _only_ applied to Project.find_with_namespace and
_not_ Project.where_paths_in as currently there's no code that requires
Project.where_paths_in to return rows in a certain order. Since this
method also returns all rows that match there's no real harm in not
setting a specific order either. Another reason is that generating all
the "WHEN" arms for multiple values in Project.where_paths_in becomes
really messy.
On MySQL we have to use the "BINARY" operator to turn a "WHERE" into a
case-sensitive WHERE as otherwise MySQL may still end up returning rows
in an unpredictable order.
Fixesgitlab-org/gitlab-ce#18603
Add environments and deployments
This MR is a continuation of https://gitlab.com/gitlab-org/gitlab-ce/issues/17009.
The current implementation is as follow:
1. We have two new tables: `environments` and `deployments`.
2. We have a new tab: `Environments` under `Pipelines` where you can see all you environments and add a new one.
3. We add a new option to `.gitlab-ci.yml` to track where we should create a deployment for environment.
4. If environment in `.gitlab-ci.yml` is specified it will create a deployment. **If environment does not exist it will be created.** (this got changed)
5. The deployment is always successful and shows the time of the action, in that case a build that presumably should do deployment. In the future we could extend deployment with statuses: success, failure. We could extend deployments with information that this is partial or full deployment.
6. User have to create environments that he will track first.
7. User can remove environments.
8. User can retry/rollback past deployment (in that case we retry past build). The new build when succeeds it will create a new deployment.
9. Currently environment have only one parameter: `name`. In the future it should have: `variables`, `credentials` and possibly `runners` and maybe other resources.
10. Currently deployment have this parameters: `sha`, `ref`, `deployable (in this case a build)`, `user (who triggered a deployment)`, `created_at`.
The `.gitlab-ci.yml`:
```
deploy to production:
stage: deploy
script: dpl travis...
environment: production
```
What needs to be done:
- [x] Write initial implementation
- [x] Improve implementation (@ayufan)
- [x] Write tests (@ayufan)
- [x] Improve UX of the forms (cc @markpundsack) - reviewed by @markpundsack
- [x] Improve implementation of the views (cc @jschatz1) - done by @iamphill
- [x] Write .gitlab-ci.yml documentation for `environments` - done by @ayufan
- [ ] Write user documentation (@ayufan and @markpundsack)
See merge request !4605
+ Move 'Edit Project/Group' out of membership-related partial
+ Show the access request buttons only to logged-in users
+ Put the request access buttons out of in a more visible button
+ Improve the copy in the #remove_member_message helper
Signed-off-by: Rémy Coutable <remy@rymai.me>
Add Project.where_paths_in
In https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4410 I'm working on reducing the SQL queries needed to render Markdown. One reason for the large amount of queries is executing a large number of queries needed to find projects and related data. Basically `Project.find_with_namespace` is called in a loop and then any relations have to be retrieved separately.
By using `Project.where_paths_in` we can work around this by doing something like:
```ruby
project_paths = [...] # populated by some method
projects = Project.where_paths_in(project_paths).includes(:namespace, ...)
```
Ref: https://gitlab.com/gitlab-org/gitlab-ce/issues/18042
See merge request !4535
This method can be used to find multiple projects for multiple paths.
For example, take this snippet:
Project.where_paths_in(%w{gitlab-org/gitlab-ce gitlab-org/gitlab-ee})
This will return an ActiveRecord::Relation containing the GitLab CE and
GitLab EE projects.
This method takes care of matching rows both case-sensitively and
case-insensitively where needed.
Project.find_with_namespace in turn has been modified to use
Project.where_paths_in without nuking any scoping (instead it uses
reorder(nil)). This means that any default scopes (e.g. those used for
"pending_delete" stay intact).
The method Project.where_paths_in was added so the various Markdown
filters can use a single query to grab all the projects referenced in a
set of documents, something Project.find_with_namespace didn't allow.
Updated error message when project limit is zero
When the project limit is zero & the user tries to create a project, the
error displayed is now 'Personal project creation is not allowed. Please
contact your administrator with questions'
Closes#17691
See merge request !4280
In 8278b763d9 the default behaviour of annotation
has changes, which was causing a lot of noise in diffs. We decided in #17382
that it is better to get rid of the whole annotate gem, and instead let people
look at schema.rb for the columns in a table.
Fixes: #17382
This changes Project#protected_branch? to use a query to check if a
branch is protected, instead of loading all ProtectedBranch records into
memory just to check if the list of names includes a given branch name.
This caches the output of Repository#exists? in Redis while making sure
it's flushed properly when creating new repositories, deleting them,
etc.
For the ProjectWiki tests to work I had to make ProjectWiki#create_repo!
public as testing private methods in RSpec is a bit of a pain.
The queries that are UNION'd together don't need any eager loading
(since we really only use the resulting SQL instead of having
ActiveRecord actually run the queries). By dropping any eager loaded
associations queries such as the following work instead of producing a
SQL error:
Project.all.includes(:namespace).search('foo')
Similar to the changes made to Project.search the method
Project.search_by_title now also uses Arel so it can automatically use
ILIKE/LIKE instead of the lower() function.
This chance is broken up in two steps:
1. Use ILIKE on PostgreSQL and LIKE on MySQL, instead of using
"WHERE lower(x) LIKE lower(y)" as ILIKE is significantly faster than
using lower(). In many cases the use of lower() will force a slow
sequence scan.
2. Instead of using 1 query that searches both projects and namespaces
using a JOIN we're using 2 separate queries that are UNION'd
together. Using a JOIN would force a slow sequence scan, using a
UNION avoids this.
This method now uses Arel as Arel automatically uses ILIKE on PostgreSQL
and LIKE on MySQL, removing the need to handle this manually.
This ensures that if a project is later re-created using the old path it
doesn't end up re-using the old cache. This also ensures we don't keep
the cache around until its expired by Redis itself.
Fixesgitlab-org/gitlab-ce#13790
Yorick Peterse
Rémy Coutable
Kamil Trzcinski
Douglas Barbosa Alexandre
Robert Speicher
Paco GuzmanandYorick Peterse
Phil Hughes
Robert Speicher
Jeroen van Baarsen
Stan Hu
Zeger-Jan van de Weg
Douwe Maan
Felipe Artur
Tomasz Maczukin
Dmitriy Zaporozhets