1. 26 8月, 2016 2 次提交
  2. 23 8月, 2016 2 次提交
  3. 22 8月, 2016 1 次提交
  4. 20 8月, 2016 2 次提交
    • D
    • G
      Support integration with Koding (online IDE) · a927a9bf
      Gokmen Goksel 提交于
      Koding: #index: landing page for Koding integration
      
      If enabled it will provide a link to open remote Koding instance url
      for now we are also providing the sneak preview video for how
      integration works in detail.
      
      Repository: check whether .koding.yml file exists on repository
      
      Projects: landing page: show Run in IDE (Koding) button if repo has stack file
      
      Projects: MR: show Run in IDE Koding button if repo has stack file on active branch
      
      ProjectHelpers: add_koding_stack: stack generator for provided project
      
      With this helper we will auto-generate the required stack template
      for a given project. For the feature we can request this base template
      from the running Koding instance on integration.
      
      Currently this will provide users to create a t2.nano instance on aws
      and it'll automatically configures the instance for basic requirements.
      
      Projects: empty state and landing page provide shortcuts to create stack
      
      projects_helper: use branch on checkout and provide an entry point
      
      This ${var.koding_queryString_branch} will be replaced with the branch
      provided in query string which will allow us to use same stack template
      for different branches of the same repository.
      
      ref: https://github.com/koding/koding/pull/8597/commits/b8c0e43c4c24bf132670aa8a3cfb0d634acfd09b
      
      projects_helper: provide sha info in query string to use existing vms
      
      With this change we'll be able to query existing vms on Koding side
      based on the commit id that they've created.
      
      ref: https://github.com/koding/koding/pull/8597/commits/1d630fadf31963fa6ccd3bed92e526761a30a343
      
      Integration: Docs: Koding documentation added
      
      Disable /koding route if integration is disabled
      
      Use application settings to enable Koding
      
      Projects_helper: better indentation with strip_heredoc usage
      
      Projects_helper: return koding_url as is if there is no project provided
      
      current_settings: set koding_enabled: false by default
      
      Koding_Controller: to render not_found once integration is disabled
      
      Dashboard_specs: update spec for Koding enabled case
      
      Projects_Helper: make repo dynamic
      
      ref: https://github.com/koding/koding/pull/8597/commits/4d615242f45aaea4c4986be84ecc612b0bb1514c
      
      Updated documentation to have right format
      a927a9bf
  5. 19 8月, 2016 2 次提交
  6. 18 8月, 2016 1 次提交
  7. 17 8月, 2016 4 次提交
  8. 16 8月, 2016 6 次提交
  9. 12 8月, 2016 2 次提交
    • Z
      Method names changed to #includes_commit? · 07fc2f85
      Z.J. van de Weg 提交于
      07fc2f85
    • S
      Fix bug where destroying a namespace would not always destroy projects · cb8a425b
      Stan Hu 提交于
      There is a race condition in DestroyGroupService now that projects are deleted asynchronously:
      
      1. User attempts to delete group
      2. DestroyGroupService iterates through all projects and schedules a Sidekiq job to delete each Project
      3. DestroyGroupService destroys the Group, leaving all its projects without a namespace
      4. Projects::DestroyService runs later but the can?(current_user,
         :remove_project) is `false` because the user no longer has permission to
         destroy projects with no namespace.
      5. This leaves the project in pending_delete state with no namespace/group.
      
      Projects without a namespace or group also adds another problem: it's not possible to destroy the container
      registry tags, since container_registry_path_with_namespace is the wrong value.
      
      The fix is to destroy the group asynchronously and to run execute directly on Projects::DestroyService.
      
      Closes #17893
      cb8a425b
  10. 11 8月, 2016 3 次提交
    • K
      Remove stage parameter from send payload · ffa75a49
      Kamil Trzcinski 提交于
      ffa75a49
    • K
      Pre-create all builds for Pipeline when a trigger is received · 39203f1a
      Kamil Trzcinski 提交于
      This change simplifies a Pipeline processing by introducing a special new status: created.
      This status is used for all builds that are created for a pipeline.
      We are then processing next stages and queueing some of the builds (created -> pending) or skipping them (created -> skipped).
      This makes it possible to simplify and solve a few ordering problems with how previously builds were scheduled.
      This also allows us to visualise a full pipeline (with created builds).
      
      This also removes an after_touch used for updating a pipeline state parameters.
      Right now in various places we explicitly call a reload_status! on pipeline to force it to be updated and saved.
      39203f1a
    • Y
      Remove various redundant indexes · 7d39bc87
      Yorick Peterse 提交于
      One can see which indexes are used in PostgreSQL by running the
      following query:
      
          SELECT relname as table_name, indexrelname as index_name, idx_scan, idx_tup_read, idx_tup_fetch, pg_size_pretty(pg_relation_size(indexrelname::regclass))
          FROM pg_stat_all_indexes
          WHERE schemaname = 'public'
          AND "idx_scan" = 0
          ORDER BY pg_relation_size(indexrelname::regclass) desc;
      
      Using this query I built a list of indexes that could be potentially
      removed. After checking every single one by hand to make sure they
      really aren't used I only found 1 index that _would_ be used. This was a
      GitLab GEO index (EE) specific that's currently not used simply because
      the table is empty.
      
      Apart from this one index all indexes could be removed. The migration
      also takes care of 6 composite indexes that can be replaced with a
      single column index, which in most cases was already present.
      
      For more information see gitlab-org/gitlab-ce#20767.
      7d39bc87
  11. 10 8月, 2016 1 次提交
    • Y
      Remove trigram indexes for "ci_runners" · 17dd3e89
      Yorick Peterse 提交于
      These indexes are only used when you search for runners in the admin
      interface. This operation is so rarely used that it does not make sense
      to slow down every update in order to update the GIN trigram indexes.
      
      Removing these indexes should speed up queries such as those used for
      updating the last contact time of CI runners. Locally the timings of
      this query were reduced from ~50 ms to ~25 ms:
      
          UPDATE ci_runners SET updated_at = now(), contacted_at = now();
      17dd3e89
  12. 04 8月, 2016 3 次提交
  13. 02 8月, 2016 2 次提交
  14. 29 7月, 2016 4 次提交
    • Z
      Incorporate feedback · 76e9b684
      Z.J. van de Weg 提交于
      76e9b684
    • Z
      Add an URL field to Environments · be9aa7f1
      Z.J. van de Weg 提交于
      This MR adds a string (thus max 255 chars) field to the enviroments
      table to expose it later in other features.
      be9aa7f1
    • T
      Use `Gitlab::Access` to protected branch access levels. · 0a8aeb46
      Timothy Andrew 提交于
      1. It makes sense to reuse these constants since we had them duplicated
         in the previous enum implementation. This also simplifies our
         `check_access` implementation, because we can use
         `project.team.max_member_access` directly.
      
      2. Use `accepts_nested_attributes_for` to create push/merge access
         levels. This was a bit fiddly to set up, but this simplifies our code
         by quite a large amount. We can even get rid of
         `ProtectedBranches::BaseService`.
      
      3. Move API handling back into the API (previously in
         `ProtectedBranches::BaseService#translate_api_params`.
      
      4. The protected branch services now return a `ProtectedBranch` rather
         than `true/false`.
      
      5. Run `load_protected_branches` on-demand in the `create` action, to
         prevent it being called unneccessarily.
      
      6. "Masters" is pre-selected as the default option for "Allowed to Push"
         and "Allowed to Merge".
      
      7. These changes were based on a review from @rymai in !5081.
      0a8aeb46
    • T
      Add a series of migrations changing the model-level design of protected branch access levels. · f1e46d1e
      Timothy Andrew 提交于
      1. Remove the `developers_can_push` and `developers_can_merge` boolean
         columns.
      
      2. Add two new tables, `protected_branches_push_access`, and
         `protected_branches_merge_access`. Each row of these 'access' tables is
         linked to a protected branch, and uses a `access_level` column to
         figure out settings for the protected branch.
      
      3. The `access_level` column is intended to be used with rails' `enum`,
         with `:masters` at index 0 and `:developers` at index 1.
      
      4. Doing it this way has a few advantages:
      
         - Cleaner path to planned EE features where a protected branch is
           accessible only by certain users or groups.
      
         - Rails' `enum` doesn't allow a declaration like this due to the
           duplicates. This approach doesn't have this problem.
      
             enum can_be_pushed_by: [:masters, :developers]
             enum can_be_merged_by: [:masters, :developers]
      f1e46d1e
  15. 27 7月, 2016 1 次提交
  16. 26 7月, 2016 1 次提交
  17. 21 7月, 2016 1 次提交
  18. 20 7月, 2016 2 次提交