1. 29 Jan, 2019 2 commits
    • Adrian Moisey's avatar
      Add GitLab Pages predefined variables · 857be4e36e6b
      Adrian Moisey authored
      857be4e36e6b
    • Andreas Brandl's avatar
      Flush InternalId records after import · 08cbb3d84cef
      Andreas Brandl authored
      After the import has finished, we flush (delete) the InternalId records
      related to the project at hand. This means we're starting over with
      tracking correct internal id values, a new record will be created
      automatically when the next internal id is generated.
      
      The GitHub importer assigns iid values by using supplied values from
      GitHub. We skip tracking internal id values during the import in favor
      of higher concurrency. Deleting any InternalId records after the import
      has finished is an extra measure to guarantee consistency.
      
      Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/54270.
      08cbb3d84cef
  2. 16 Jan, 2019 2 commits
    • Yorick Peterse's avatar
      Refactor code for protecting default branches · 8ff5f72d9a09
      Yorick Peterse authored
      This refactors some of the logic used for protecting default branches,
      in particular Project#after_create_default_branch. The logic for this
      method is moved into a separate service class. Ideally we'd get rid of
      Project#after_create_default_branch entirely, but unfortunately
      Project#after_import depends on it. This means it has to stick around
      until we also refactor Project#after_import.
      
      For branch protection levels we introduce
      Gitlab::Access::BranchProtection, which provides a small wrapper around
      Integer based branch protection levels. Using this class removes the
      need for having to constantly refer to Gitlab::Access::PROTECTION_*
      constants.
      8ff5f72d9a09
    • Yorick Peterse's avatar
      Refactor checking personal project limits · da8b222b69e8
      Yorick Peterse authored
      This refactors the code used for checking if a user has exceeded the
      personal projects limit. As part of this refactor the method has been
      renamed from Project#check_limit to "check_personal_projects_limit", as
      this name makes it much more clear what the purpose of the method is.
      Standalone unit tests have also been added, as before we only had a
      single generic validation test that did not cover all cases.
      
      The old implementation of the refactored method also included a `rescue`
      statement. This code would only run when a project creator was not set.
      The error that would be added wasn't super useful, especially since
      there would already be errors for the creator not being present. As none
      of the other code in the "check_personal_projects_limit" raises, it has
      been removed.
      da8b222b69e8
  3. 14 Jan, 2019 2 commits
  4. 11 Jan, 2019 2 commits
  5. 09 Jan, 2019 1 commit
    • Steve Azzopardi's avatar
      Remove get_build method for find_by_id · 2f9c04015f7b
      Steve Azzopardi authored
      The original intention of `get_build` was as a workaround not to violate
      `CodeReuse/ActiveRecord`. `find_by_id` does the exact same thing but
      does not violate the rubocop rule.
      2f9c04015f7b
  6. 07 Jan, 2019 5 commits
    • Gabriel Mazetto's avatar
      Only set as `read_only` when starting the per-project migration · 10d9a7b13e9f
      Gabriel Mazetto authored
      In the previous code, we locked the project during the migration
      scheduling step, which works fine for small setups, but can be
      problematic in really big installations.
      
      We now moved the logic to inside the worker, so we minimize the time a
      project will be read-only. We also make sure we only do that if
      reference counter is `0` (no current operation is in progress).
      10d9a7b13e9f
    • Peter Leitzen's avatar
      Implement error tracking configuration · 6334ce10dfe7
      Peter Leitzen authored
      Re-use operations controller which already handles tracing settings.
      6334ce10dfe7
    • Reuben Pereira's avatar
      Add table and model for error tracking settings · 56c4cbadc13e
      Reuben Pereira authored
      56c4cbadc13e
    • Steve Azzopardi's avatar
      Create `get_build` for project model · 4f7020aeb1af
      Steve Azzopardi authored
      Inside of `Projects::ArtifactsController` and
      `Projects::BuildArtifactsController` we fetching the build by id using
      active record directly which violates `CodeReuse/ActiveRecord` rubocop
      rule. Create `get_build` inside of `project` model which does the same
      thing.
      4f7020aeb1af
    • Steve Azzopardi's avatar
      Refactor project.latest_successful_builds_for def · 50a1dd6a79ff
      Steve Azzopardi authored
      `project.latest_successful_builds_for(ref)` is being used to find a
      single job all the time. This results into us having to call `find_by`
      inside of the controller which violates our CodeReuse/ActiveRecord
      rubocop rule.
      
      Refactor `project.latest_successful_builds_for(ref)` to
      `project.latest_successful_build_for(job_name, ref)` which will execute
      the `find_by` inside of the model.
      
      Also create `project.latest_successful_build_for!(job_name, ref)` which
      raises an exception instead of returning nil.
      50a1dd6a79ff
  7. 04 Jan, 2019 2 commits
  8. 03 Jan, 2019 3 commits
  9. 02 Jan, 2019 3 commits
  10. 21 Dec, 2018 1 commit
  11. 19 Dec, 2018 3 commits
  12. 13 Dec, 2018 1 commit
  13. 12 Dec, 2018 1 commit
  14. 11 Dec, 2018 1 commit
    • Yorick Peterse's avatar
      Refactor Project#create_or_update_import_data · a96301852960
      Yorick Peterse authored
      In https://gitlab.com/gitlab-org/release/framework/issues/28 we found
      that this method was changed a lot over the years: 43 times if our
      calculations were correct. Looking at the method, it had quite a few
      branches going on:
      
          def create_or_update_import_data(data: nil, credentials: nil)
            return if data.nil? && credentials.nil?
      
            project_import_data = import_data || build_import_data
      
            if data
              project_import_data.data ||= {}
              project_import_data.data = project_import_data.data.merge(data)
            end
      
            if credentials
              project_import_data.credentials ||= {}
              project_import_data.credentials =
                project_import_data.credentials.merge(credentials)
            end
      
            project_import_data
          end
      
      If we turn the || and ||= operators into regular if statements, we can
      see a bit more clearly that this method has quite a lot of branches in
      it:
      
          def create_or_update_import_data(data: nil, credentials: nil)
            if data.nil? && credentials.nil?
              return
            else
              project_import_data =
                if import_data
                  import_data
                else
                  build_import_data
                end
      
              if data
                if project_import_data.data
                  # nothing
                else
                  project_import_data.data = {}
                end
      
                project_import_data.data =
                  project_import_data.data.merge(data)
              end
      
              if credentials
                if project_import_data.credentials
                  # nothing
                else
                  project_import_data.credentials = {}
                end
      
                project_import_data.credentials =
                  project_import_data.credentials.merge(credentials)
              end
      
              project_import_data
            end
          end
      
      The number of if statements and branches here makes it easy to make
      mistakes. To resolve this, we refactor this code in such a way that we
      can get rid of all but the first `if data.nil? && credentials.nil?`
      statement. We can do this by simply sending `to_h` to `nil` in the right
      places, which removes the need for statements such as `if data`.
      
      Since this data gets written to a database, in ProjectImportData we do
      make sure to not write empty Hash values. This requires an `unless`
      (which is really a `if !`), but the resulting code is still very easy to
      read.
      a96301852960
  15. 08 Dec, 2018 11 commits