Snippet spam EE
EE version of https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8911.
Merge request reports
Activity
added 2 commits
This has been applied manually to GitLab.com to combat the massive increase in spam. This was done as follows:
knife ssh -aipaddress 'role:gitlab-cluster-worker' 'curl https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1148.patch -o /tmp/1148.patch; sudo patch -d /opt/gitlab/embedded/service/gitlab-rails -p1 -N -f < /tmp/1148.patch'
assigned to @rymai
@smcgivern do we have to wait for this or can we tag the release without it?
@jameslopez this is already on GitLab.com, so maybe we should cut the release without it, and manually apply again after (or during) deploy?
@yorickpeterse feel free to tell me if that's a dumb idea.
@smcgivern Considering the amount of spam I'd rather have this in the next release, instead of having to re-apply things.
@jameslopez I've created these branches, which should be fast-forwardable from the current stable branches, but please check:
@smcgivern yep, they are FF - tested them branching off stable and pulling from those new ones. Thanks a lot!
enabled an automatic merge when the pipeline for d364d7d0 succeeds
mentioned in commit 3a8437af
@smcgivern Yeah, it's because the check is trying to apply the CE patch to EE but I believe an actual
merge
is more intelligent (the check was doing amerge
before but there were issues with that too...):Conflicting files: - app/models/snippet.rb:7
Anyways, better be safe than sorry...
@smcgivern Previous comment was about:
Just to note, I got a failure on the EE compatibility check, but I didn't have any conflicts when cherry-picking my commits into this EE branch