This instance will be upgraded to Heptapod 0.31.0rc on 2022-05-19 at 11:00 UTC+2 (a few minutes of down time)

  1. 08 May, 2020 1 commit
    • Georges Racinet's avatar
      Gitlab::Mercurial adopted method for repo creation · d9eac4fb23dd
      Georges Racinet authored
      The main advantage is that this looks more uniform from the
      upper layers, at the price of making
      `Git::Repository.create_repository` accept arbitrary
      arguments.
      
      Also `Gitlab::Shell` is slowly being faded away. By
      calling the raw repo's `create_repository` we are
      actually anticipating on later versions.
      
      The saner structure can be also be felt in that we
      don't need to give some methods a classmethod
      version any more.
      
      --HG--
      branch : heptapod
      d9eac4fb23dd
  2. 01 May, 2020 1 commit
  3. 30 Apr, 2020 2 commits
    • Georges Racinet's avatar
      Gitlab::Mercurial moved highest level changeset methods to HgGitRepository · 566aed1f5eae
      Georges Racinet authored
      This is enough to remove the dispatching in the Repository model
      class, and keeps the call flow in a single direction: the parent
      Git::Repositroy never calls a method of HgGitRepository
      
      --HG--
      branch : heptapod
      566aed1f5eae
    • Georges Racinet's avatar
      Gitlab::Mercurial started using a dedicated repo class · 972ed4e01239
      Georges Racinet authored
      We're calling it HgGitRepository to keep open the future
      possibility to have also a HGitalyRepository later on.
      Although it's possible we won't be needing it.
      
      This changeset defines the class and calls it from
      the Repository *model*.
      
      A final remark for people not familiar with Rails: it's
      absolutely necessary to respect the file/class convention.
      Otherwise, everything will look fine for the main app in development
      mode, but the class may not be loaded in some other cases, notably
      from rake in production mode (if mode is even relevant to rake)
      
      --HG--
      branch : heptapod
      972ed4e01239
  4. 09 May, 2020 4 commits
  5. 08 May, 2020 1 commit
  6. 06 May, 2020 1 commit
  7. 04 May, 2020 3 commits
    • Georges Racinet's avatar
      Restablish Git hooks from Rails hg operations, triggering pipelines · 3bb507357531
      Georges Racinet authored
      Closes #145
      Pipelines are actually always created from the `post-receive` hook.
      
      Long ago, we disabled Git hooks in the case of operations like commit
      and publication done from the Rails app. At the time, it was necessary,
      probably because of the race conditions related to pruning topics and
      maybe more. In Heptapod 0.12, we've had to solve most of these anyway.
      
      We still had a race condition in branch deletions for topics. Since
      the merge is examined both by two workers for branch updates (target and
      source), it was possible for example that
      `PostMergeService`, running from the target branch would delete the
      source topic branch in concurrency with `RefreshService`. Both go through
      `DeleteBranchService` which does a 2 step pass: existence test, then
      deletion. In the deletion we don't have a specific Gitaly error to ignore
      the case of the branch being already deleted, so we do it from the callers.
      
      In case we perform several operations (such as commit+publish
      for a merge), we avoid launching two set of hooks in fast succession: it
      would be a waste of resources at best (in the merge example,
      twice the same pipeline for the target branch).
      
      In principle, authentication being already guaranteed, we could skip
      the `pre-receive` hook, but we didn't dare to at this point.
      
      --HG--
      branch : heptapod-stable
      3bb507357531
    • Georges Racinet's avatar
      Mercurial repo: make it possible to fire Git hooks · 5b20c8a3cb06
      Georges Racinet authored
      For now, those hooks are disabled, but they wouldn't work
      for lack of `HEPTAPOD_PROJECT_ID` in Heptapod 0.12 or
      `GL_REPOSITORY` in Heptapod 0.13
      
      --HG--
      branch : heptapod-stable
      5b20c8a3cb06
    • Georges Racinet's avatar
      Pipelines: avoid creation on a trivial branch update · 4fd7b37e7bb5
      Georges Racinet authored
      Our Mercurial backend sends identity changes for topics, so that
      the prune (Git branch deletion) can be done safely after the merge
      detection by the Rails app.
      
      We don't want a pipeline to be created for this: at best it's a
      waste of resources, potentially delaying an important build/deploy from
      the target branch, and it can fail if the topic head has become
      obsolete.
      
      --HG--
      branch : heptapod-stable
      4fd7b37e7bb5
  8. 02 May, 2020 3 commits
  9. 30 Apr, 2020 3 commits
  10. 29 Apr, 2020 3 commits
    • Georges Racinet's avatar
      Squash: inner implementation · ab2e518bd992
      Georges Racinet authored
      This provides the core functionality, allowing to squash
      Merge Requests with the API. The web UI still has to be checked
      and maybe fully restablished.
      
      GitLab already expected that a squash could fail, same as for
      a merge or a rebase. Therefore, the strong protections
      provided by the `hg fold` command and the `allowunstable=no`
      setting do the trick for us.
      
      GitLab has a way to detect that a squash already is in progress,
      presumably to avoid inconsistencies. In the case of Mercurial,
      will always be `False` and that's not problematic, because the
      operation is atomic and if the working directory is used, it is
      a single usage temporary one anyway. In case of race between
      two squashes, the worst that can happen is the second one
      completing before assessment of the successor changeset of the
      first one. Of course it would be even better to have the
      successor immediately (that's mercurial/evolve#13).
      
      --HG--
      branch : heptapod-stable
      ab2e518bd992
    • Georges Racinet's avatar
      Repository: split a hg_prepare_user_encoding method · 9d3d1a5c84a3
      Georges Racinet authored
      it sets the `HGENCODING` variable after checking its
      consistency and prepares a suitable string for `--user` from
      a `User` instance.
      
      --HG--
      branch : heptapod-stable
      9d3d1a5c84a3
    • Georges Racinet's avatar
      repository: fixed hg/git map invalidation · d7350032b5a4
      Georges Racinet authored
      Up to now, all our invalidations were actually about the
      the git -> hg mapping only. It worked because the hg -> git mapping
      is used only after we've created commits, and a new Repository
      is created soon enough anyway.
      
      For instance, starting afresh in hg_merge uses the git -> hg
      mapping several times, produces a commit then invalidates the
      git -> hg mapping. Here comes the first resolution of hg -> git
      ever, which starts by reverting the (fresh) git -> hg mapping.
      
      But in the forthcoming squashed merge support, we're creating
      two commits in a row. Hence in hg_merge, before this changeset,
      we started with a stale version of the hg -> git mapping,
      and failed miserabily at the end, returning `nil` for the new
      commit SHA.
      
      --HG--
      branch : heptapod-stable
      d7350032b5a4
  11. 28 Apr, 2020 1 commit
  12. 27 Apr, 2020 3 commits
    • Georges Racinet's avatar
      Bitbucket import page: personal namespace option only if possible · e4b02c72c668
      Georges Racinet authored
      Again, for users that can't create projects in their personal
      namespaces, we don't present the option.
      
      Should be weird if they also cannot select namespaces, because the
      default is… the personal namespace. This will be investigated in
      a follow-up.
      
      --HG--
      branch : heptapod-stable
      e4b02c72c668
    • Georges Racinet's avatar
      New project page: personal namespace option only if possible · 764b490e40f6
      Georges Racinet authored
      Part of #256
      
      Without an explicit `namespace_id` parameter, the new project page
      would list the personal namespace as an option, even if creation
      there is not actually possible. It would even be the default.
      
      With this change, only groups where creation is possible would be
      listed in this situation, and the first returned would be the
      default (a priori not consistent with the option list, which is
      sorted by path, but that's a detail).
      
      Users that would be redirected explicitely to the project creation
      page with the `namespace_id` parameter pointing to their personal
      namespace would probably have it as an option that will end in
      error. This should be so rare that we don't need to tackle this
      case right now compared to the major UX problem that #256 is for
      new users.
      
      --HG--
      branch : heptapod-stable
      764b490e40f6
    • Georges Racinet's avatar
      Synced user.can_create_project? with actual ability · 82b3f14d0ee8
      Georges Racinet authored
      This is the most part of #256: since creation of projects
      in groups (not personal namespaces) doesn't depend on
      the value of `project_limit_left`, better have the general
      `can_create_project?` reflect that. At least they will get
      prompted with their real options.
      
      --HG--
      branch : heptapod-stable
      82b3f14d0ee8
  13. 26 Apr, 2020 7 commits
    • Georges Racinet's avatar
      hg_access: renamed user_can_publish? for clarity · f7731429eae6
      Georges Racinet authored
      We felt it necessary to stress that this method does not perform
      the basic write permission checks. This is motivated by the
      fact that some of these tests are transversal (database being
      read-only would be one case), and is about to become even
      more true with the forthcoming wiki support.
      
      --HG--
      branch : heptapod
      f7731429eae6
    • Georges Racinet's avatar
      GitAccess: maximizing conflicts for subsequent changes · 7a15f01717f7
      Georges Racinet authored
      This is a case where a VCS conflict is a feature: if anything
      changes in `GitAccess::check`, we want to be warned. An explicit
      conflict on next merge will do exactly that.
      
      This littering is not pretty, the same job could be done by a
      dedicated merge tool, but then we wouldn't be so sure it's active
      on all our working copies and shares of this repo.
      
      --HG--
      branch : heptapod
      7a15f01717f7
    • Georges Racinet's avatar
      Making HgAccess inherit from GitAccess · a9b2d561996a
      Georges Racinet authored
      Since the origins of Heptapod, this had been a separate class,
      with some advantages, but also the risk of becoming too much out
      of sync, which could turn into security issues.
      
      Since then, GitAccess has grown more features, such as the deploy
      tokens (see #243), and more restrictions. An instance can
      be set up to refuse HTTP pulls or even pushes.
      
      The main specificity of HgAccess is that we cannot always rely on the
      command, because it's known only in HTTP, but we can always pass over
      whether the actor should have read/write/publish permission: Mercurial
      will always check based on that.
      
      For the subclassing to work, we had to make GitAccess more open to it:
      using explicitely constants of the current class with `self.class::`
      syntax and moreover making all private methods just protected.
      
      --HG--
      branch : heptapod
      a9b2d561996a
    • Georges Racinet's avatar
      check_project_move: adapted message for Mercurial · fe365a488082
      Georges Racinet authored
      --HG--
      branch : heptapod
      fe365a488082
    • Georges Racinet's avatar
      Internal REST API `hg_access` uses same helpers as `/allowed` (Git) · a3a69f01b794
      Georges Racinet authored
      Making the factory in `internal_helpers.rb` able to dispatch
      a Mercurial access class allows us to remove a good chunk of
      code duplication.
      
      It will also support wikis transparently as soon as we have
      a `HgAccessWiki` class.
      
      --HG--
      branch : heptapod
      a3a69f01b794
    • Georges Racinet's avatar
      RepoType: introducing hg_checker_class · 724678cabcbb
      Georges Racinet authored
      The RepoType instances defined in `gl_repository.rb` are
      used by the factory patterns of `lib/helpers/internal_helpers.rb`.
      With this change, we are close to make the latter Mercurial aware.
      
      The idea is that later on, we'll have a `HgAccessWiki` class
      for `GlRepository::WIKI`.
      
      --HG--
      branch : heptapod
      724678cabcbb
    • Georges Racinet's avatar
      hg_access: support same instance variables as git_access · af7f016babbf
      Georges Racinet authored
      These project and namespace path arguments are related to the
      automatic repository creation feature. We need at least minimal
      support for them so that `hg_access` can be used in factories such as
      `access_checker_for` in `lib/api/helpers/internal_helpers`.
      
      --HG--
      branch : heptapod
      af7f016babbf
  14. 25 Apr, 2020 1 commit
    • Georges Racinet's avatar
      Merged with GitLab v12.3.5 · 0707f8e4abc3
      Georges Racinet authored
      In the 12.3 to 12.4 cycle, a new branch management style has been
      adopted: the stable branch always starts from a released version or
      very shortly after and is merged back later
      
      In the 12.3 to 12.4 case, the branching point is essentially v12.3.5
      (actually the merged-back of the very short release branch where it's
      sitting, that doesn't matter), which is a direct ancestor of v12.4.0
      
      Conflict resolution:
      
      - lib/api/internal.rb
        has been renamed to lib/api/internal/base.rb
        something that the Git to Mercurial conversion clearly did not track
        well. Also the protection against SSH Git operation on `hg_git`
        projects was really conflicting (quick and dirty resolution)
      - app/views/admin/dashboard/index.html.haml
        statistics are now provided by some JavaScript. We used to remove
        forks stats, we won't any more. A good thing for when we support Git
        again
      - app/views/projects/_merge_request_merge_method_settings.html.haml
        method to display detailed explanation has been short...
      0707f8e4abc3
  15. 24 Apr, 2020 1 commit
  16. 23 Apr, 2020 2 commits
  17. 04 May, 2020 2 commits
    • Georges Racinet's avatar
      Bitbucket import: setting default branch · d6a1c5cdb282
      Georges Racinet authored
      Closes #251
      
      If we don't do this, GitLab will set it to the first seen
      and committed through post-receive hooks.
      
      The minor complication here is that we can't do it upfront
      in `BitbucketImport::ProjectCreator`, because it's not stored
      in the SQL database, but rather in the Git repo itself (as its HEAD).
      
      Through the Bitbucket importer we can be confident that the branch indeed
      exists, without resorting to call Mercurial. Otherwise the project would
      be no more broken than on the Bitbucket side.
      
      --HG--
      branch : heptapod-stable
      d6a1c5cdb282
    • Georges Racinet's avatar
      Bitbucket import: fixed status page for users that can create groups · 0676ac4ae169
      Georges Racinet authored
      Closes #263
      
      That was a stupid mistake, really. The `Group.new` is here to display
      an option to create implicitely a GitLab group named after the namespace
      of the Bitbucket repo. Of course it can't be preset outside of Bitbucket
      repo context.
      
      And it was doubly stupid, because it just does not make sense for
      the free import form.
      
      --HG--
      branch : heptapod-stable
      0676ac4ae169
  18. 23 Apr, 2020 1 commit