Age | Commit message (Collapse) | Author |
|
services: true, no_db: true, api: true
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
|
|
Don't mark empty MRs as merged on push to the target branch
Closes #32800
See merge request !12711
|
|
|
|
When we push to an MR's target branch, we check if the MR's HEAD commit is
contained in the push. This lets us mark MRs as merged if they were merged
manually.
However, we also added a feature where you can create an empty MR from an
issue. If that MR is created around the time of a merge to the default branch,
we would process the push after creating the MR, and consider it to be a manual
merge.
To fix that, we exclude empty MRs from this process. If they are empty, they
were empty before the push we're processing, so we shouldn't touch them!
|
|
checks before actual deletion
|
|
|
|
Fix https://gitlab.com/gitlab-org/gitlab-ce/issues/27070
Deprecate "chat commands" in favor of "slash commands"
We looked for things like:
- `slash commmand`
- `slash_command`
- `slash-command`
- `SlashCommand`
|
|
|
|
|
|
|
|
If our side of the conflict file has a trailing newline, and we are picking
sections, not editing the whole content, then add a trailing newline back.
|
|
Set head pipeline when creating merge requests
See merge request !11669
|
|
|
|
|
|
|
|
|
|
|
|
Fix conflict resolution from corrupted upstream
Closes gitlab-ee#2128
See merge request !11298
|
|
I don't know why this happens exactly, but given an upstream and fork repository
from a customer, both of which required GC, resolving conflicts would corrupt
the fork so badly that it couldn't be cloned.
This isn't a perfect fix for that case, because the MR may still need to be
merged manually, but it does ensure that the repository is at least usable.
My best guess is that when we generate the index for the conflict
resolution (which we previously did in the target project), we obtain a
reference to an OID that doesn't exist in the source, even though we already
fetch the refs from the target into the source.
Explicitly setting the source project as the place to get the merge index from
seems to prevent repository corruption in this way.
|
|
|
|
Use the EnforcedStyleForMultiline: no_comma option.
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Enable `RSpec/DescribedClass` cop and correct violations
See merge request !10930
|
|
Fix 404 when upstream disabled merge requests
Closes #26488
See merge request !10427
|
|
|
|
|
|
- Ignore JS fixtures
- Ignore qa directory
- Rewrite concern specs to put concern name first
|
|
Search for opened MRs - include reopened MRs
Closes #30291
See merge request !10407
|
|
|
|
Don’t show source project name when user does not have access
See merge request !2081
|
|
|
|
|
|
params
Closes #28890
|
|
|
|
|
|
Rename column in the database
Rename fields related to import/export feature
Rename API endpoints
Rename documentation links
Rename the rest of occurrences in the code
Replace the images that contain the words "build succeeds" and docs referencing to them
Make sure pipeline is green and nothing is missing.
updated doc images
renamed only_allow_merge_if_build_succeeds in projects and fixed references
more updates
fix some spec failures
fix rubocop offences
fix v3 api spec
fix MR specs
fixed issues with partials
fix MR spec
fix alignment
add missing v3 to v4 doc
wip - refactor v3 endpoints
fix specs
fix a few typos
fix project specs
copy entities fully to V3
fix entity error
more fixes
fix failing specs
fixed missing entities in V3 API
remove comment
updated code based on feedback
typo
fix spec
|
|
Only create unmergeable todos once
Closes #28555
See merge request !9513
|
|
Previously, we created an unmergeable todo when a merge request:
1. Had merge when pipeline succeeds set.
2. Became unmergeable.
However, when merge when pipeline succeeds fails due to unmergeability,
the flag isn't actually removed. And a merge request can become
unmergeable multiple times, as every time the target branch is updated
we need to re-check the mergeable status. This means that if the todo
was marked done, and the MR was checked again, a new todo would be
created for the same event.
Instead of checking this, we should create the todo from the service
responsible for merging when the pipeline succeeds. That way the todo is
guaranteed to only be created when we care about it.
|
|
|
|
This reverts commit e00fb2bdc2090e9cabeb1eb35a2672a882cc96e9.
# Conflicts:
# .rubocop.yml
# .rubocop_todo.yml
# lib/gitlab/ci/config/entry/global.rb
# lib/gitlab/ci/config/entry/jobs.rb
# spec/lib/gitlab/ci/config/entry/factory_spec.rb
# spec/lib/gitlab/ci/config/entry/global_spec.rb
# spec/lib/gitlab/ci/config/entry/job_spec.rb
# spec/lib/gitlab/ci/status/build/factory_spec.rb
# spec/lib/gitlab/incoming_email_spec.rb
|
|
This reverts commit cb10b725c8929b8b4460f89c9d96c773af39ba6b.
|
|
|
|
|
|
|