| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Added keyboard shortcut to navigate to issue boards
## What does this MR do?
Adds a keyboard shortcut of `g l` to navigate to issue boards.
`g b` would work nicer. However that is taken by builds. Open to suggestions.
## What are the relevant issue numbers?
Closes #21218
See merge request !6248
|
| | |
| |
| |
| | |
Added wait for vue helper
|
| | |
| |
| |
| | |
Closes #21218
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
'master'
Update snippets UI
## What does this MR do?
Updates snippets UI _(mainly mobile view)_ to new UI proposed in #18849.
## Are there points in the code the reviewer needs to double check?
Does anyone know the implementation difference between `app/views/snippets/show.html.haml` and `app/views/projects/snippets/show.html.haml`? I have only been updating the latter as it's the only one I can find implemented. I assume the former is rendered somewhere seeing as there is controllers for it too. But this doesn't seem very DRY from my current perspective.
## Why was this MR needed?
## Screenshots (if relevant)
## Does this MR meet the acceptance criteria?
- [ ] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [ ] API support added
- Tests
- [ ] Added for this feature/bug
- [ ] All builds are passing
- [ ] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
## What are the relevant issue numbers?
Closes #18849
See merge request !6210
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Rearranged datetime created line
Added `avatar_class` option to `link_to_member` so it can be hidden
Made snippet title font heavier
Added file title bar
Hidden unneeded info from xs screens
Added visibility icon
Reveal file-actions on xs screens
Added comments icon to snippets list items
Refactored no-comments declaration into framework stylesheet
Final touch ups
Fixed snippets_spec
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Improve validity of spec/features/todos/todos_filtering_spec.rb
Previously, we were checking that a CSS selector string didn't have some
page-related content, which, of course it didn't.
Now we check against the actual content of the selector, we use a more
semantic selector, and we add an additional expectation for the text
that _should_ be there, as an additional sanity check.
See merge request !6356
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously, we were checking that a CSS selector string didn't have some
page-related content, which, of course it didn't.
Now we check against the actual content of the selector, we use a more
semantic selector, and we add an additional expectation for the text
that _should_ be there, as an additional sanity check.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Group similar builds
We group builds by removing from the builds name two numbers which are delimited by whitespace or colon:
* `name 0 1` => `name`
* `name 0:1` => `name`
* `name 0/1` => `name`
* `name 0:1 ruby` => `name ruby`
* `name 0/1 ruby` => `name ruby`
* `0 1 name ruby` => `name ruby`
* `0:1 name ruby` => `name ruby`
* `0/1 name ruby` => `name ruby`
See merge request !6242
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Trigger autosize update after template selection
## What does this MR do?
Triggers an autosize update after selecting an issue template.
The autosize plugin doesn't react to value changes and therefore doesn't automatically update when the user selects the template. This merge request adds it so that it detects if the editor the template selector is a jQuery object (not Ace editor) & then triggers the autosize event to allow the user to scroll the textarea.
## Screenshots (if relevant)
## What are the relevant issue numbers?
Closes #21982
See merge request !6282
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Closes #21982
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Fix the ordering of transition callbacks
Because pipeline status could be changed for the builds in the next
stages, if we process next stages first, the current build would be
out of synchronized, and would need a reload for that matter.
Alternatively, like what I did in this commit, we could process the
next stages later (by using `after_transition` rather than
`around_transition`), and complete what're doing for the current
build first. This way we don't have to reload because nothing is
out synchronized.
Note that since giving `false` in `after_transition` would halt the
callbacks chain, according to:
https://github.com/state-machines/state_machines-activemodel/blob/v0.4.0/lib/state_machines/integrations/active_model.rb#L426-L429
We'll need to make sure we're not returning false because we don't
intend to interrupt the chain.
This fixes #22010.
After this fix, both pipeline events and build events would only show
up once.
See merge request !6305
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6305#note_15230024
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The observed faulty state transition is probably hard to test,
because we need to hook into internal states to observe them.
Namely this:
07:30:16 | Build#ruby-2.2 enqueue: created -> pending
07:30:16 | Pipeline#32 enqueue: created -> pending
07:30:16 | Build#ruby-2.3 enqueue: created -> pending
07:30:16 | Build#ruby-2.2 run: pending -> running
07:30:16 | Pipeline#32 run: pending -> running
07:30:29 | Build#ruby-2.2 drop: running -> failed
07:30:29 | Pipeline#32 run: running -> running
07:30:29 | Build#ruby-2.3 run: pending -> running
07:30:30 | Pipeline#32 run: running -> running
07:30:57 | Build#gem:build skip: created -> skipped
07:30:57 | Pipeline#32 drop: running -> failed
07:30:57 | Build#gem:release skip: created -> skipped
07:30:57 | Pipeline#32 drop: failed -> failed
07:30:57 | Build#ruby-2.3 drop: running -> failed
07:30:57 | Pipeline#32 drop: running -> failed
^^^ Should be failed -> failed
However, the consequence of this, executing hooks twice would be
easy enough to observe. So we could at least test against this.
Keep in mind that if we ever changed how we execute the hooks
this won't be testing against faulty state transition.
|
| | | | | | | |
|
| | | | | | | |
|
| |\ \ \ \ \ \
| |_|_|_|/ /
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Fix wiki headeline linking
Fixes #21817
See merge request !6300
|
| | | | | | | |
|
| |\ \ \ \ \ \ |
|
| | |\ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Exclude some pending or inactivated rows in Member scopes
An unapproved request or not-yet-accepted invite should not give access rights. Neither should a blocked user be considered a member of anything.
One visible outcome of this behaviour is that owners and masters of a group or project may be blocked, yet still receive notification emails for access requests.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/21650
See merge request !1994
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
An unapproved access request should not give access rights, and blocked users
should not be considered members of anything.
One visible outcome of this behaviour is that owners and masters of a group or
project may be blocked, yet still receive notification emails for access
requests. This commit prevents this from happening.
|
| |\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Update gitlab_git to 10.6.6
## What does this MR do?
This updates gitlab_git to version 10.6.6
## Are there points in the code the reviewer needs to double check?
No.
## Why was this MR needed?
10.6.4/10.6.5/10.6.6 contains some changes regarding marking blobs as binary, this can improve page loading times.
## Does this MR meet the acceptance criteria?
- [x] ~~[CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added~~
- Tests
- [ ] All builds are passing
- [x] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
## What are the relevant issue numbers?
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/22144
See merge request !6279
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
gitlab_git 10.6.4 relies on Rugged marking blobs as binary or not,
instead of relying on Linguist. Linguist in turn would mark text blobs
as binary whenever they would contain byte sequences that could not be
encoded using UTF-8.
However, marking such blobs as binary is not correct. If one pushes a
Markdown document with invalid character sequences it's still a text
based Markdown document and not some random binary blob.
This commit overwrites Blob#data so it automatically converts text-based
content to UTF-8 (the encoding we use everywhere else) while taking care
of replacing any invalid sequences with the UTF-8 replacement character.
The data of binary blobs is left as-is.
|
| |\ \ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Back-port from EE. This MR just moves the `parse_search_results` method from models/repository.rb to search_helper.rb
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/699
See merge request !6341
|
| | | | | | | | | | | |
|
| |/ / / / / / / / /
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
add tests with dependent destroy
add tests with dependent destroy
add tests
add tests to projects spec
update it title and remove let
update it title and remove let
remove changes after rebase
remove changes after rebase
update changelog
|
| |\ \ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Move pushes_since_gc to Redis
## What does this MR do?
This moves tracking of the pushes since the last Git GC to Redis to reduce DB load.
## Are there points in the code the reviewer needs to double check?
Styling mostly.
## Why was this MR needed?
Updating this column can lead to a lot of writes which in turn puts a lot of load on table vacuuming. For example, in the last hour alone we had 5067 UPDATEs for this column (per InfluxDB):
```
> select count(increment_pushes_since_gc_call_count) from sidekiq_transactions where time > now() - 1h;
name: sidekiq_transactions
--------------------------
time count
1473780996567714622 5067
```
## What are the relevant issue numbers?
https://gitlab.com/gitlab-org/gitlab-ce/issues/22125
See merge request !6326
|
| | |/ / / / / / / /
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
This moves tracking of the pushes since the last Git GC from PostgreSQL
to Redis. This reduces the number of writes on the "projects" table.
This in turn reduces the vacuuming overhead.
The lease used for incrementing the counter has been removed. This lease
was mostly put in place to prevent high database load but this isn't
needed anymore due to the counter now being stored in Redis.
Fixes gitlab-org/gitlab-ce#22125
|
| |\ \ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Allow trailing newline in secret base64 data
Fixes https://gitlab.com/gitlab-org/omnibus-gitlab/issues/1575
See merge request !6327
|
| | | |_|_|/ / / / /
| |/| | | | | | | |
|
| |\ \ \ \ \ \ \ \ \
| |/ / / / / / / /
|/| | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Change response for /ci/api/v1/builds/register.json from 404 to 204
## What does this MR do?
To check if there are new builds scheduled for a runner, runner is sending `POST /ci/api/v1/builds/register.json` requests. If there is a build then a `200` response with build data is returned. However if there is no builds scheduled for this runner it receives a `404 Not Found` response. This may end with a lot of `404 Not Found` lines in logs that are an expected behavior (please read #14445 for a reference).
Since `v1.0.1` version GitLab Runner is ready to receive a `204 No Content` response in case of no builds.
This MR adds a support for this status code for each Runner's version that can be determined while handling `POST /ci/api/v1/builds/register.json` request.
## Are there points in the code the reviewer needs to double check?
Specs in `spec/requests/ci/api/builds_spec.rb`
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [ ] ~~API support added~~
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [ ] ~~Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)~~
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
## What are the relevant issue numbers?
Fixes #14445
See merge request !6225
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Restore SSH Key title auto-population behavior
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/21823
See merge request !6186
|
| | |/ / / / / / / /
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/21823
|
| |\ \ \ \ \ \ \ \ \
| |/ / / / / / / /
|/| | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Import GitHub release notes
## Why was this MR needed?
Release notes aren't currently migrated over when importing from GitHub
## What are the relevant issue numbers?
#20780
See merge request !5981
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
# Conflicts:
# lib/gitlab/github_import/importer.rb
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
