1. 03 Jun, 2020 1 commit
  2. 30 May, 2020 1 commit
    • Georges Racinet's avatar
      Merge with GitLab 12.10 · 5d910dd2a9f9
      Georges Racinet authored
      We merge at the common ancestor between branches 12-10-stable
      and 13-0-stable, hoping that will be an ancestor of future
      versions, this time.
      The merge is not expected to work right away. Lots of conflicts
      were fixed, including some which really are porting efforts done
      without any kind of feedback.
      Notably the "raw" `Git::Repository` class is now responsible
      of more actions (rename, delete, imports) and our Mercurial
      counterpart will have to be made on par with that. Most of the
      callers are already adapted with appropriate calls to
      `Gitlab::VCS` in the present untested changeset.
      Also worthy of note:
      - `app/models/project.rb`: ssh_url_to_repo and http_url_to_repo
        will have to be modified again for hg, wherever they now are.
      - `app/models/project_wiki.rb`: the Repository model is now
        directly in charge of raw repo instantiation, to be checked.
      - ` app/services/destroy_service.rb` changed a lot, hg version
        will have to be ported down to `Repositories::ShellDestroyService`
        and `GitlabShellWorker`
      - `lib/gitlab/gl_repository.rb`: we'll need a `HgAccessSnippet`
      - `lib/gitlab/gitlab_access.rb`: our conflict inducing markers
        were successfull bringing a minor refactor to our attention.
        Ported to `hg_access.rb`.
      - `app/workers/post_receive.rb`: default branch initiatlization
        adapated, but not the avoidance of pipelines for identical
      - `db/schema.rb`: ported Heptapod changes to `db/structure.sql`
        will have to be proofread very carefully.
      - `lib/api/entities.rb`: was split. Heptapod changes are ported,
        need testing.
      - `lib/api/internal.rb`: not too scary resolution. Still needs
        extra scrunity (security critical path).
      - `config/routes/`: restructured upstream a bit. We're trying
        to restore the Git HTTP route, will see how it fares.
      - `lib/gitlab/bitbucket_import/importer.rb`: GitLab reduced duplication
        a lot, and split loops content in separate methods. Ported/resolved,
        will need testing.
      branch : heptapod
  3. 29 May, 2020 2 commits
  4. 28 May, 2020 3 commits
    • Georges Racinet's avatar
      Versions display: only if signed in · fea0de297e96
      Georges Racinet authored
      This is only consistent with the Heptapod and GitLab versions
      not being displayed unless signed in.
      branch : heptapod
    • Georges Racinet's avatar
      Squash: honouring squash_in_progress? · cfd7b187b509
      Georges Racinet authored
      This works with the same principle as rebase_in_progress?,
      see parent commit.
      branch : heptapod
    • Georges Racinet's avatar
      Rebase: honouring rebase_in_progress? · d7a0e368784b
      Georges Racinet authored
      We name the temporary working directory according to the given
      rebase_id and the question whether it's in progress boils down
      to the workdir being there.
      Ideally, some other kind of persistent storage should be used
      immediately, but we can use this as a better approximation for
      the time being. In upstream GitLab, this is handled by Gitaly,
      whose rebase RPC call receives the `rebase_id` and then answers
      the question. Later on HGitaly will do the same.
      branch : heptapod
  5. 27 May, 2020 1 commit
    • Georges Racinet's avatar
      Mercurial rebase for topics · 5f6de060df79
      Georges Racinet authored
      Closes #280
      This is enough for merge requests based on topics, which
      currently would display a 'rebase' button if the method is
      For now we add a hard check that the branch being rebased is
      related to a topic, that makes for a simple revset.
      As in the case of squashs, the protection against concurrent
      rebases seems at first sight to be unneeded (the rebase itself
      is atomic enough, and a subsequent would fail because it'd create
      instabilities) but because of #277 we have to be cautious
      with concurrency and avoid potential thundering herds of shares.
      This will be done for both squash and rebase in a follow-up that
      would simply test for presence of a share.
      branch : heptapod
  6. 28 May, 2020 6 commits
  7. 23 May, 2020 1 commit
  8. 19 May, 2020 1 commit
  9. 23 May, 2020 2 commits
    • Georges Racinet's avatar
      Temporary workdirs: switching to the closure style · 8211911f4bca
      Georges Racinet authored
      This is better style and it makes sense for the method that
      create the temporary working directory to take care of its
      cleanup. Overall, we lower the risk to forget an `ensure`
      We change the name of the method in the same move because
      - it's consistent with what the method does
      - it helps us being sure there isn't a leftover call to
        the old `hg_new_workdir` method.
      branch : heptapod
    • Georges Racinet's avatar
      Cleaning up temporary workdirs (shares) if creation fails · ac2102a384f3
      Georges Racinet authored
      Severe leaks of temporary workdirs are reported in #277.
      This change removes a potential source, not claiming to be a
      complete solution: if the update to revision failed, it would
      leave a directory behind, that maybe could be large already.
      That is because the begin … ensure clauses typically happen
      after the return from `hg_new_workdir`
      branch : heptapod
  10. 22 May, 2020 2 commits
    • Georges Racinet's avatar
      wikis: making backups work · 3f8f52d8d321
      Georges Racinet authored
      Closes #275
      We replicate the same logic we've been doing earlier
      for the main repos on Heptapod 0.13: conditional for both
      the Git and the Mercurial repo.
      delegating `vcs_type` and `mercurial?` makes `ProjectWiki` close
      enough to `Project` for the inner method to work (as it does on
      upstream GitLab)
      branch : heptapod
    • Georges Racinet's avatar
      wiki backups: avoid showing of main project config · bfd430d98774
      Georges Racinet authored
      Because `disk_path` doesn't have the `.git` extension,
      the removed `.ext()` would have been called on paths such
      as `my_project.wiki`, returning `my_project.hg` instead of
      the expected `my_project.wiki.hg`.
      branch : heptapod
  11. 21 May, 2020 2 commits
  12. 19 May, 2020 2 commits
    • Georges Racinet's avatar
      Unprotect topic branch that's not default any more · c1f43664c49e
      Georges Racinet authored
      If it stays protected, it won't be pruned when it has to,
      and that's quite unnatural.
      It's ok if it doesn't get pruned immediately, a subsequent push
      to Heptapod will do it.
      We didn't want to go through a separate service, because this
      should be unconditional, and in particular not depend onto who
      did the push that created the new default branch. Very usually,
      that should be the project owner right after creation, and currently
      creating a named branch (hence changing the default) entails be
      Maintainer anyway, but let's be a bit more cautious than that.
      The worst that can happen is a topic branch to be unprotected when
      it shouldn't have in the first place.
      branch : heptapod-stable
    • Georges Racinet's avatar
      Change automatically GitLab default branch if it's a topic · c538af777431
      Georges Racinet authored
      This is a practical solution for #126.
      Because we fear that a non empty repo without a default branch would
      be potentially blocking for GitLab, we prefer to allow the default
      branch to be a topic, provided we override it as soon as a named branch
      is available.
      In GitLab the source of truth about the default branch is the
      repository HEAD.
      One could think that the purpose of BranchHooksService.branch_create_hooks
      is to set the default branch, because it will in turn call
      `project.change_head`. But actually that's just repetition of what's
      already in cache, and the comparison to `nil` in `default_branch?`
      seems to be useless: currently something always writes at least something
      in HEAD, and that something doesn't seem to be part of the Rails app (
      not going through `Git::Repository.write_ref`). It's possible that
      Gitaly would actually check HEAD and set it to an existing branch if
      it is dangling, making this a side effect of a read operation.
      So we decided that Heptapod export code to Git would take care
      of setting a sensible HEAD in case
      - it points to a ref that doesn't exist (refs/heads/master on an empty repo)
      - it points to a topic but the current transaction creates a named branch head
      All we need then is to force GitLab to expire the caches involved, before handing
      over the changed refs to the appropriate services. That's what this patch
      branch : heptapod-stable
  13. 15 May, 2020 6 commits
  14. 13 May, 2020 6 commits
  15. 11 May, 2020 2 commits
    • Georges Racinet's avatar
      Wikis: add RST to possible formats · ba560959d518
      Georges Racinet authored
      Many of the wikis that we'll need to import from Bitbucket are
      written in reStructuredText (RST), that Gollum supports out of the
      box if the conversion utilities, such as `rst2html` are installed.
      It is important to use the official symbol for the format, `:rest`
      even though extension based rendering would work. For instance that
      is needed for the edit page to keep that format by default instead
      of selecting Markdown for lack of understanding.
      Unfortunately, at this point this is not enough for the preview to
      work in RST, making it only a second class citizen.
      branch : heptapod
    • Georges Racinet's avatar
      Wikis: write actions from the UI. · 1887d8ecf727
      Georges Racinet authored
      We need notably the converse of the hack exposing `branch/default`
      as `master`: the higher parts of Rails will write to
      `wiki.default_branch` which we had to leave at `master` for the
      display to work.
      branch : heptapod
  16. 09 May, 2020 2 commits
    • Georges Racinet's avatar
      Fixed response to workhorse for deploy tokens · 58402491a702
      Georges Racinet authored
      These simply don't have an `email` method. This produces
      a 500 error, which is not what has been reported for #243
      on Heptapod 0.12
      This change is enough to make deploy tokens work on the
      future Heptapod 0.13.
      branch : heptapod-stable
    • Georges Racinet's avatar
      workhorse payload: fixed raise of HgAccess::Unauthorized · 90e5adb7844e
      Georges Racinet authored
      The name of the exception to raise was just wrong. This
      didn't open any door, but produced a 500 error instead of
      the natural 403.
      As the comment explains, reaching this last layer of protection
      is (at least on Heptapod 0.12) to be considered a bug. Indeed
      we found this typo on the future Heptapod 0.13, because of such
      a bug after refactor of `HgAccess`. It's possible that some of
      the finer access control reenabled on Heptapod 0.13 make this
      case less exceptional
      branch : heptapod-stable