Commit graph

18 commits

Author SHA1 Message Date
Duana Saskia
c322976032 Refactor ProtectedRefMatcher to be more generic 2018-08-13 13:36:22 +02:00
gfyoung
15b878e27e Enable more frozen string in app/models/**/*.rb
Partially addresses #47424.
2018-08-07 00:37:36 -07:00
Lin Jen-Shin
4ee08b77bc Updates from rubocop -a 2018-07-09 21:13:08 +08:00
Bob Van Landuyt
35a49922e6 Allow admins to push to empty repos 2018-04-24 14:06:59 +02:00
James Edwards-Jones
bd1be9bb43 Remove 'dependent: :destroy' from ProtectedRef has_many :"#{type}_access_levels" 2017-08-25 16:36:42 +00:00
Kamil Trzciński
ac948684fc Merge branch '30634-protected-pipeline' into 'master'
Implement "Block pipelines on protected branches"

Closes #30634, #34616, and #33130

See merge request !11910
2017-07-25 15:04:23 +00:00
Bob Van Landuyt
e13d75c38a Explicitly define inverse of acces_level relations 2017-07-25 11:26:22 +02:00
Lin Jen-Shin
a397a0eb1a Eliminate N+1 queries on checking different protected refs
I realized where the N+1 queries were actually coming from
project.protected_branches, but how come we cannot preload this,
or cache this at all?

Then I found that this is somehow a Rails limitation. What we're
doing before, eventually come to:

    project.protected_branches.matching

But why it's not cached? (project.protected_branches.loaded? is always
false) It's because matching is a class method, which is called on
the proxy. In this case, Rails cannot cache the result. I don't know
if this is possible to implement or not, because clearly this would
require some tricks to implement class methods on associations.

So instead, we could just pass project.protected_branches to
ProtectedRef.matching, then it would work regularly.

With this change, there's no more N+1 queries.
2017-07-19 19:12:11 +08:00
Yorick Peterse
8fbbf41e29
Added Cop to blacklist the use of dependent:
This is allowed for existing instances so we don't end up 76 offenses
right away, but for new code one should _only_ use this if they _have_
to remove non database data. Even then it's usually better to do this in
a service class as this gives you more control over how to remove the
data (e.g. in bulk).
2017-07-06 12:01:36 +02:00
James Edwards-Jones
0c1bf16d5f Backport EE refactorings for Protected Tag EE-only functionality
Improvements and refactorings were made while adding role based permissions for protected tags to EE. This doesn’t backport the feature, but should improve code quality and minimize divergence.
2017-05-31 13:06:29 +01:00
James Edwards-Jones
f16377e7dc Protected Tags backend review changes
Added changelog
2017-04-06 10:56:21 +01:00
James Edwards-Jones
d85471ac1a Fixed UserAccess#can_create_tag? after create_access_levels rename 2017-04-04 03:50:15 +01:00
James Edwards-Jones
1e15444ae6 Cleanup & tests for UserAccess#can_create_tag? 2017-04-04 02:05:42 +01:00
James Edwards-Jones
90c8bb8301 Fixed developers_can_push in RepoBranch API entity 2017-04-04 01:39:34 +01:00
James Edwards-Jones
ff2713a570 Fix typos in ProtectedRef concern and whitespace detected by rubocop 2017-04-03 22:04:37 +01:00
James Edwards-Jones
9f4b8dba80 Clean up non TODO rubocop errors 2017-04-03 20:06:06 +01:00
James Edwards-Jones
35b719f60b Use delegation in ProtectedRef concern 2017-04-03 20:04:43 +01:00
James Edwards-Jones
65f3d5062f Extract ProtectedRef Concern 2017-04-03 17:19:53 +01:00