| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Add new API endpoint - list jobs of a specified runner
Closes #39699
See merge request gitlab-org/gitlab-ce!15432
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
Add new API endpoint - get a namespace by ID
Closes #40254
See merge request gitlab-org/gitlab-ce!15442
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
Fix ProtectedBranch access level validations
See merge request gitlab-org/gitlab-ce!15586
|
| | | |
| | |
| | |
| | |
| | | |
Before an access_level was required in EE even when an
it had been set for a user/group.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Renamed ProtectedBranches::ApiUpdateService to LegacyApiUpdateService
See merge request gitlab-org/gitlab-ce!15575
|
| | |/ / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Move identical merged branch check to merged_branch_names
Closes #39887
See merge request gitlab-org/gitlab-ce!15464
|
| | |/ / |
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | | |
Use foreign key to get latest MR diff
Closes #37631
See merge request gitlab-org/gitlab-ce!15126
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Compared to the merge_request_diff association:
1. It's simpler to query. The query uses a foreign key to the
merge_request_diffs table, so no ordering is necessary.
2. It's faster for preloading. The merge_request_diff association has to load
every diff for the MRs in the set, then discard all but the most recent for
each. This association means that Rails can just query for N diffs from N
MRs.
3. It's more complicated to update. This is a bidirectional foreign key, so we
need to update two tables when adding a diff record. This also means we need
to handle this as a special case when importing a GitLab project.
There is some juggling with this association in the merge request model:
* `MergeRequest#latest_merge_request_diff` is _always_ the latest diff.
* `MergeRequest#merge_request_diff` reuses
`MergeRequest#latest_merge_request_diff` unless:
* Arguments are passed. These are typically to force-reload the association.
* It doesn't exist. That means we might be trying to implicitly create a
diff. This only seems to happen in specs.
* The association is already loaded. This is important for the reasons
explained in the comment, which I'll reiterate here: if we a) load a
non-latest diff, then b) get its `merge_request`, then c) get that MR's
`merge_request_diff`, we should get the diff we loaded in c), even though
that's not the latest diff.
Basically, `MergeRequest#merge_request_diff` is the latest diff in most cases,
but not quite all.
|
| |/ |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| | |
'39461-notes-api-for-issues-no-longer-returns-label-additions-removals' into 'master'
Resolve "Notes API for issues no longer returns label additions/removals"
Closes #39461
See merge request gitlab-org/gitlab-ce!15080
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Adds Rubocop rule for line break after guard clause
Closes #18040
See merge request gitlab-org/gitlab-ce!15188
|
| | |/
| |
| |
| | |
Adds a rubocop rule (with autocorrect) to ensure line break after guard clauses.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| | |
Do not allow jobs to be erased
Closes #31771
See merge request gitlab-org/gitlab-ce!15216
|
| | |\ |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix acceptance of username for Mattermost service update
Closes #39895
See merge request gitlab-org/gitlab-ce!15275
|
| | | | | |
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
into '10-1-stable'
Include X-Content-Type-Options (XCTO) header into API responses
See merge request gitlab/gitlabhq!2211
(cherry picked from commit 6c818e77f2abeef2dd7b17a269611b018701fa79)
e087e075 Include X-Content-Type-Options (XCTO) header into API responses
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fail when issuable_meta_data is called on an unlimited collection
Closes #39845
See merge request gitlab-org/gitlab-ce!15249
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This method can be called with an array, or a relation:
1. Arrays always have a limited amount of values, so that's fine.
2. If the relation does not have a limit value applied, then we will load every
single object in that collection, and prevent N+1 queries for the metadata
for that. But that's wrong, because we should never call this without an
explicit limit set. So we raise in that case, and this commit will see which
specs fail.
The only failing specs here were the issues API specs, and the specs for
IssuableMetadata itself, and both have been addressed.
|
