| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Use gitlab-workhorse 0.7.11
Versions 0.7.9 and 0.7.10 crash on previously valid 'authBackend'
settings.
I don't know how many people are affected by this, 'normal' Omnibus
installations are not. (If they were gitlab.com would have stopped
working :) ). Still this is something we should not ship.
Unfortunately 8-11-stable uses 0.7.10 (but 8.11.0 does not). So I
think we need to put this in the next 8.11 patch release.
See merge request !5983
|
| | |
| |
| |
| |
| | |
Versions 0.7.9 and 0.7.10 crash on previously valid 'authBackend'
settings.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
expose 'only_allow_merge_if_build_succeeds' project setting in the API
## What does this MR do?
Adds the 'only_allow_merge_if_build_succeeds' project setting in the API.
## Are there points in the code the reviewer needs to double check?
No, but maybe this code is not enough for ACLs or the like.
## Why was this MR needed?
Because that's a very useful setting to change via automation (through the API)
## What are the relevant issue numbers?
Closes #21085, closes https://gitlab.com/gitlab-org/gitlab-ce/issues/20088.
## Screenshots (if relevant)
## 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)
- [X] API support added
- Tests
- [X] Added for this feature/bug
- [X] All builds are passing
- [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)
See merge request !5930
|
| | |/ |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
api: expose web_url for project entities
## What does this MR do?
Adds a `web_url` field to project snippet, issues, and merge request API returned objects.
## Are there points in the code the reviewer needs to double check?
Tests. Are they sufficient? (I'm working on getting them to pass.)
## Why was this MR needed?
Creating the URL for an MR or issue from the MR is tedious in API libraries; it's easy for Gitlab to just provide it.
## What are the relevant issue numbers?
N/A
## Screenshots (if relevant)
N/A
## 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)
- [x] API support added
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [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)
See merge request !5631
|
| | |/
| |
| |
| |
| | |
This allows web hooks to have a URL back to entities without having to
generate it themselves.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Update merge_requests.md with a simpler way to check out a merge request
## What does this MR do?
This MR updates `merge_requests.md` with a simpler way to check out a merge request
The previous way was put under the "By modifying `.git/config` for a given repository" section. The disadvantage of the old way is that one has to modify `.git/config` for each repository that one uses. The new way was put under the "By adding a git alias" section. One has to create this git alias once, and then it will work from any repository, without having to modify `.git/config` over and over again.
## Are there points in the code the reviewer needs to double check?
One should double check that the link provided by the "Check out branch" button in a MR, i.e. https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/workflow/merge_requests.md#checkout-merge-requests-locally, still works. I think it will, since I didn't modify the "Checkout merge requests locally" section name.
## Why was this MR needed?
This MR was needed because the old way of checking out a merge request locally requires to modify `.git/config` in all repositories that one has on a computer, which is a tedious task. The new way just requires adding a simple git alias, once. And the `git mr` command then works for all repositories.
## What are the relevant issue numbers?
I haven't created an issue for this.
## Screenshots (if relevant)
N/A
## 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 (N/A)
- Tests
- [ ] Added for this feature/bug (N/A)
- [x] All builds are passing
- [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)
See merge request !5944
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Now the alias should be used as:
git mr upstream 5
To check out a MR number 5 from the upstream remote, into a `mr-upstream-5`
local branch.
Also clarify that the `5` in the merge request is the number shown in GitLab.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The previous way was put under the
"By modifying `.git/config` for a given repository" section. The
disadvantage is that one has to modify `.git/config` for each repository
that one uses. The new way was put under the "By adding a git alias"
section. One has to create this git alias once, and then it will work
from any repository, without having to modify `.git/config` over and
over again.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Api project hook wiki page events
## What does this MR do?
Updates project hook API for wiki page events. Also updates docs and tests for forgotten hook fields.
See merge request !5969
|
| | | | | |
|
| | | |/
| |/| |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Issue created at docs
## What does this MR do?
Clarifies `created_at` for creating issues via the API.
## Are there points in the code the reviewer needs to double check?
No.
## Why was this MR needed?
Docs were unclear.
## What are the relevant issue numbers?
Closes #18458 and closes #19863.
## Screenshots (if relevant)
N/A
## Does this MR meet the acceptance criteria?
- [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [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)
See merge request !5967
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
See also #19863.
Fixes #18458.
|
| | |/ /
|/| | |
|
| |/ / |
|
| |/ |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Split Koding admin/user docs
Backend/Frontend MR https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5909
See merge request !5938
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Documentation for Issue Boards
## What does this MR do?
Add documentation for issue boards.
## What are the relevant issue numbers?
- Issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/17907
- Backend MR: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5548
- Frontend MR: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5554
See merge request !5713
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | | |
Change slash commands docs location
See merge request !5937
|
| | | | |
|
| | |/ |
|
| |\ \
| | |
| | |
| | |
| | | |
Fix typo in gitlab-workhorse header
See merge request !5891
|
| | | | |
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | | |
Document protected branches new behavior
See merge request !5934
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Koding: #index: landing page for Koding integration
If enabled it will provide a link to open remote Koding instance url
for now we are also providing the sneak preview video for how
integration works in detail.
Repository: check whether .koding.yml file exists on repository
Projects: landing page: show Run in IDE (Koding) button if repo has stack file
Projects: MR: show Run in IDE Koding button if repo has stack file on active branch
ProjectHelpers: add_koding_stack: stack generator for provided project
With this helper we will auto-generate the required stack template
for a given project. For the feature we can request this base template
from the running Koding instance on integration.
Currently this will provide users to create a t2.nano instance on aws
and it'll automatically configures the instance for basic requirements.
Projects: empty state and landing page provide shortcuts to create stack
projects_helper: use branch on checkout and provide an entry point
This ${var.koding_queryString_branch} will be replaced with the branch
provided in query string which will allow us to use same stack template
for different branches of the same repository.
ref: https://github.com/koding/koding/pull/8597/commits/b8c0e43c4c24bf132670aa8a3cfb0d634acfd09b
projects_helper: provide sha info in query string to use existing vms
With this change we'll be able to query existing vms on Koding side
based on the commit id that they've created.
ref: https://github.com/koding/koding/pull/8597/commits/1d630fadf31963fa6ccd3bed92e526761a30a343
Integration: Docs: Koding documentation added
Disable /koding route if integration is disabled
Use application settings to enable Koding
Projects_helper: better indentation with strip_heredoc usage
Projects_helper: return koding_url as is if there is no project provided
current_settings: set koding_enabled: false by default
Koding_Controller: to render not_found once integration is disabled
Dashboard_specs: update spec for Koding enabled case
Projects_Helper: make repo dynamic
ref: https://github.com/koding/koding/pull/8597/commits/4d615242f45aaea4c4986be84ecc612b0bb1514c
Updated documentation to have right format
|
