| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Closes #15515
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Always read diff_view setting from the cookie
Prior, when the user had their view set to "parallel" and then visited a
merge request's changes tab _without_ passing the `view` parameter via
query string, the view would be parallel but the `Notes` class was
always instantiated with the default value from `diff_view` ("inline"),
resulting in broken markup when the form to add a line note was
dynamically inserted.
The cookie is set whenever the view is changed, so this value should
always be up-to-date.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/14557 and https://gitlab.com/gitlab-org/gitlab-ce/issues/15285
See merge request !3732
|
| | |
| |
| |
| | |
This invalidates one test, which we've removed.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes text color on labels in sidebar
Previously the labels in the sidebar would just have `#FFF` text color which could cause problems with a light background color.
With this, the text color comes from the JSON.
See merge request !3846
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Removed JS update templates
See merge request !3814
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Show project members only for members
fixes #5838
See merge request !3752
|
| | | | | | |
|
| | |/ / / |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Ci::Commit becomes a Pipeline object
1. Ci::Commit receives context: ref, :tag.
1. One Ci::Commit describes a one Pipeline
1. Pipeline is created from `.gitlab-ci.yml`
1. Pipeline is a ordered group of builds
1. We test MR against Pipeline
1. Pipelines have a separate view (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3703)
1. Pipeline can be triggered from UI (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3703)
1. Later we change `Trigger -> TriggerRequest -> Build` to `Trigger -> Pipeline` (future)
1. We add a Pipeline Hook that will be triggered on Pipeline status change (future)
1. We extend notifications to use `Pipeline Hook` to send summary on pipeline changes (future)
After merging that I'll prepare a separate MR that will unify naming, database columns, table names:
```
Ci::Commit -> Pipeline
Ci::Build -> Build
CommitStatus -> Job
GenericCommitStatus -> ExternalJob
ci_commits -> pipelines
ci_builds -> jobs
```
This MR implements first 5 points.
This is made to solve this issue https://gitlab.com/gitlab-org/gitlab-ce/issues/14149.
See merge request !3653
|
| | |\ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
# Conflicts:
# db/schema.rb
|
| | |\ \ \ \ \
| | | |/ / /
| | |/| | |
| | | | | |
| | | | | | |
# Conflicts:
# db/schema.rb
|
| | | | | | | |
|
| | | | | | | |
|
| | |\ \ \ \ \ |
|
| | |\ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
# Conflicts:
# app/views/projects/commits/_commit.html.haml
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | |_|_|_|_|/ /
|/| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Add due_date text field to sidebar issue#show
Add ability sorting issues by due date ASC and DESC
Add ability to filtering issues by No Due Date, Any Due Date, Due to tomorrow, Due in this week options
Add handling issue due_date field for MergeRequest
Update CHANGELOG
Fix ambigous match for issues#show sidebar
Fix SCREAMING_SNAKE_CASE offenses for due date contants
Add specs for due date sorting and filtering on issues
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Mutliple label filter
Fixes #989
See merge request !3438
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Created issuable singleton to house the filtering
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
characters in the templates to prevent xss attack
|
| | | |_|_|_|_|/
| |/| | | | | |
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
add slack notifications for wiki pages
## What does this MR do?
Lets the Slack service be configured to send notifications when wiki pages are created or edited.
## Are there points in the code the reviewer needs to double check?
I'm just starting to get familiar with the Gitlab codebase and I was unsure on how to get the wiki page url to pass it to the slack message, on whether or not I needed to refactor the create/update methods for wiki pages from the controller to a service (but seemed necessary to test it better), and if I needed to add a column to the web hooks table or if the services table would have been enough. Please let me know if I should change anything and I will improve the MR, thanks for checking :)
## Why was this MR needed?
Related to #563 and fixes #4233.
See merge request !2998
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
update changelog
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| |/ / / / / / / |
|
| |\ \ \ \ \ \ \ |
|
| | | |_|_|_|/ /
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/12785
Merge Request: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3514
|
| |\ \ \ \ \ \ \
| |_|_|_|_|_|/
|/| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Sanitize branch names for confidential issues
- When creating new branches for confidential issues, prefer a branch name like `issue-15` to `some-sensitive-issue-title-15`.
- The behaviour for non-confidential issues stays the same.
Closes #14566
See merge request !3671
|
| | | | | | | | |
|
| | |\ \ \ \ \ \
| | | |/ / / /
| | |/| | | |
| | | | | | | |
14566-confidential-issue-branches
|
| | |\ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | | |
14566-confidential-issue-branches
|
| | | |_|_|_|/ /
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
- Previously, the controller held the logic to calculate
related branches, which was:
`<branches ending with `issue.iid`> - <branches with a merge request referenced in the current issue>`
- This logic belongs in the `related_branches` method, not in the
controller. This commit makes this change.
- This means that `Issue#related_branches` now needs to take a `User`.
When we find the branches that have a merge request referenced in the
current issue, this is limited to merge requests that the current user
has access to.
- This is not directly related to #14566, but is a related refactoring.
|
| | | | | | | | |
|
| | | | | | | | |
|
| | |_|_|/ / /
|/| | | | |
| | | | | |
| | | | | | |
Closes #15330
|
| |\ \ \ \ \ \
| |_|_|/ / /
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Issuable can be assigned to author
Closes #9014
The only difference with #9014 is that I thoughed the author should also be
able to assign the issue. If this is unwanted behavior Ill revert it.
/cc @DouweM
See merge request !2765
|
| | |\ \ \ \ \ |
|
| | |\ \ \ \ \ \ |
|
| | |\ \ \ \ \ \ \ |
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Closes #9014
The only difference with #9014 is that I thoughed the author should also be
able to assign the issue. If this is unwanted behavior Ill revert it.
|
| | |_|_|_|_|_|_|/
|/| | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Currently this works by loading the HAML partials via XHR. While this is
not the nicest setup it _is_ the easiest setup using the tools we
currently have.
Loading this data asynchronously doesn't make loading the related
MRs/branches itself faster, it merely ensures that loading the issue
itself is not slowed down.
Fixes gitlab-org/gitlab-ce#14949
|
| |\ \ \ \ \ \ \ \
| |_|_|_|_|_|/ /
|/| | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Move RepositoryArchiveCacheWorker to sidekiq-cron
Closes #15105
See merge request !3663
|
| | | |_|_|_|/ /
| |/| | | | |
| | | | | | |
| | | | | | | |
Closes #15105
|
