1. 21 Jan, 2020 1 commit
    • Georges Racinet's avatar
      Bitbucket import: provider defaulting to `bitbucket` · 188e9f9d08b6
      Georges Racinet authored
      With this, if the `bitbucket_import` provider doesn't exist, the
      import will use the `bitbucket` one.
      
      In other words, this restores backwards compatibility after
      introduction of `bitbucket_import`
      
      --HG--
      branch : heptapod
      188e9f9d08b6
  2. 20 Jan, 2020 1 commit
    • Georges Racinet's avatar
      Bitbucket import: changing the OAuth provider name · f21e3f072abd
      Georges Racinet authored
      All Bitbucket imports now use a specific OAuth provider,
      `bitbucket_import`, solving #156.
      
      Simple SSO operations (sign-up/sign-in) are not affected:
      they still work with the `bitbucket` provider.
      Users will probably want to exclude `bitbucket_import`
      from SSO options on the sign-in page (can be done in
      the application settings page).
      
      --HG--
      branch : heptapod
      f21e3f072abd
  3. 22 Jan, 2020 2 commits
    • Georges Racinet's avatar
      Bitbucket PR import: robustness if source branch/sha is missing from Git · 891d2150cbdd
      Georges Racinet authored
      This should take care of #168 (not exported to Git because of
      closed hg heads) and similar cases:
      
      - if the Git counterpart is unknown (previously ignored, leading
        to inevitable later failure)
      - if the Git branch does not exist
      - if the Git commit is unknown or unreachable from the branch head
      
      --HG--
      branch : heptapod
      891d2150cbdd
    • Georges Racinet's avatar
      Bitbucket PR import: robustness if target branch/sha is missing · 7658f6e266c6
      Georges Racinet authored
      This should take care of #167.
      The mentioned case of target sha being nil is treated right away
      and we go through exceptional cases, defaulting to the target
      branch head if possible.
      
      This wouldn't yet be strong enough to take care of cases where
      the whole target branch is missing (e.g, has been closed)
      
      --HG--
      branch : heptapod
      7658f6e266c6
  4. 19 Jan, 2020 1 commit
    • Georges Racinet's avatar
      Bitbucket PR import: case when we already have all changesets · 3216e732c19e
      Georges Racinet authored
      This is the simplest case of #169. In case `hg pull_force_topic`
      does not pull anything (now corresponding to exit code 1),
      and the wanted changeset is visible,
      we can just adapt by reading the branch/topic information on it,
      which gives us all needed info to create the MR.
      
      The more complex case in which the target changeset is known but is
      obsolete will maybe be handled entirely in `hg pull_force_topic`:
      for now the `hg log` call will refuse it, and we couldn't do anything
      with it on the Rails side, because the corresponding Git commit is
      not there or has become unreachable.
      
      --HG--
      branch : heptapod
      3216e732c19e
  5. 18 Jan, 2020 6 commits
  6. 16 Jan, 2020 1 commit
  7. 23 Feb, 2020 5 commits
    • Georges Racinet's avatar
      Time to set the future version to 0.12.0.dev · b7ab88aad50e
      Georges Racinet authored
      --HG--
      branch : heptapod
      b7ab88aad50e
    • Georges Racinet's avatar
      Merge Requests detection done in the Rails app · 9d427fcd9d51
      Georges Racinet authored
      For GitLab 12, we won't send prunes for topics that have
      been published, so that the Rails app can have enough information
      to mark the MRs as merged.
      
      That is because the processing is done branch by branch (from the
      post-receive data) and therefore our efforts to send the topic updates
      before the named branch updates are essentially useless.
      
      The approach done here works, but we don't have a solution to
      update the list of commits to be displayed in the MR yet.
      
      The normal GitLab way of doing is to perform that detection upon
      pushes on the target branches, but for Mercurial, we have to do it
      both ways, because after detection comes the `reload_diff` that
      makes the diff empty (and breaks further detection) in the common
      cases of rebase/publish.
      
      What we do for source-based detection looks simpler, because we
      didn't try to call any high-level service in the hope that
      it would give us an appropriate list of commits.
      
      We'll probably revise this to make it more symmetrical
      once we have a plan for the list of commits. It could be that we'll
      need a direct call from hg-git to some internal API (bearing more data)
      if that's unavoidable.
      
      --HG--
      branch : heptapod
      9d427fcd9d51
    • Georges Racinet's avatar
      Merge Requests: deletion of source branch now taken care of by Rails app · b72154b722bf
      Georges Racinet authored
      In `MergeService` we handle the case where the merge is done from the
      Rails app whereas `PostMergeService` is about manual merges, those done
      by a push.
      
      That leaves all Mercurial pruning and closing of named branches to
      be treated. For these, it's reasonable to suppose that `hg-git` should
      send prunes (to be reviewed)
      
      --HG--
      branch : heptapod
      b72154b722bf
    • Georges Racinet's avatar
      MergeRequest: source branch deletion rules on the model · 50fb17b18735
      Georges Racinet authored
      On the model, this is mostly about displaying something meaningful
      in the checkbox, since it can't be easily removed.
      
      The "force" variant is a bit puzzling in the Mercurial case: what
      should we do of it? Usually it's in a "||" boolean condition, after
      the "should" so we still have to return the same value as the "should".
      
      --HG--
      branch : heptapod
      50fb17b18735
    • Georges Racinet's avatar
      Crucial reimport · 8252e5c750d2
      Georges Racinet authored
      GitLab upstream `Git::Repository` does not launch subprocesses anymore,
      but our Mercurial commands do. Thankfully `Popen` has not been removed,
      just moved a step in the module hierarchy
      
      --HG--
      branch : heptapod
      8252e5c750d2
  8. 22 Feb, 2020 8 commits
  9. 11 Feb, 2020 1 commit
    • Georges Racinet's avatar
      Experimental merge with v12.2.0.pre · cf4530676fc1
      Georges Racinet authored
      This time, we'll commit the simple merge resolution before
      it passes the tests.
      
      The reason is that `lib/gitlab/hg_access.rb` needs to be patched
      and this will maybe have to be backported (even partially) to
      the merge with v11.2.0.pre. Therefore we want subsequent changes
      to be really visible.
      
      --HG--
      branch : heptapod
      cf4530676fc1
  10. 09 Feb, 2020 2 commits
    • Georges Racinet's avatar
      repository: removed unnecessary hgsha_from_ref · d579cb1e9d6e
      Georges Racinet authored
      All occurrences have been checked to be about full Git SHAs,
      and hence replaced by hgsha_from_sha.
      
      Beyond code reading and functional tests, tried to peek in the UI
      as well (notably in MRs). Nothing suspicious, but surprises are
      still possible.
      
      --HG--
      branch : heptapod
      d579cb1e9d6e
    • Georges Racinet's avatar
      Merged and adapted GitLab v11.2.0.pre into heptapod · 1b92f4183309
      Georges Racinet authored
      The removal of direct filesystem access to Git repository is
      unsurprisingly stronger in this version, with methods in
      `lib/gitlab/shell.rb` no longer taking full paths, `path_to_repo()`
      in the `Repository` model no longer working due to `legacy_disk_path`
      now raising errors. All of this has us expand the separate code path
      for filesystem access on Mercurial repositories that's been
      introduced in the merge with 10.8.0.pre and now expose it on the
      model, on the internal API for consumption by heptapod-shell etc.
      
      Also notable is the deprecation of `hgsha_from_ref`, that should
      be removed soon after this merge.
      
      In the `hg_merge` method, we had to adapt not to use
      `lib/git/operation_service.rb` any more because it relies on the
      now broken `path`, deciding that our direct `hg` calls are enough
      (it seems we were doing both the Git and Mercurial merges up to now).
      Also, the expected return type is now a `BranchUpdate` that the
      Git version would init from the Gitaly merge return, and that
      we create directly.
      
      Finally, `config/initializers/2_app.rb` has been removed, now
      just including `lib/gitlab.rb`. we had to port the `HEPTAPOD_VERSION`
      and `REVISION` init over there
      
      --HG--
      branch : heptapod
      1b92f4183309
  11. 30 Jan, 2020 3 commits
    • Georges Racinet's avatar
      Using a distinct accessor for Mercurial repos root · 6bea24badad2
      Georges Racinet authored
      legacy_disk_path won't be there anymore in v11.0 (full Gitaly),
      but we'll need it in Heptapod as long as we aren't using HGitaly,
      or even as long as we have `hg_git` repositories.
      
      Until the HGitaly project is ready, we won't be able to shard
      Mercurial repositories anyway.
      
      This is expected to conflict in the intializer of
      GitalyClient::StorageSettings upon merge to v11.x, and that's
      a good thing.
      
      --HG--
      branch : heptapod
      6bea24badad2
    • Georges Racinet's avatar
      Resolved two rubocop warnings · 2a6e53b89631
      Georges Racinet authored
      Being primarily a Pythonist, I actually love it when
      it's about adding parentheses to method calls.
      
      --HG--
      branch : heptapod
      2a6e53b89631
    • Georges Racinet's avatar
      Merged and adapted GitLab v10.8.0.pre into heptapod · 3ebbcd276249
      Georges Racinet authored
      Reasons to stop by at this version:
      
      - it gets us past the date of our db schema change, resolving
        also a potentially fatal inconsisteny.
      - heptapod-runner v0.1 is based on a late revision from the
        v10.8.x series
      
      One can see in this version preparations for the upcoming v11 that
      makes Gitaly mandatory: repo manipulation methods in `shell.rb` or
      `repository.rb` never get a full path, just a storage and a relative
      path, converting these into a full path spits deprecation warnings.
      
      To support these, we split out more hg specific methods than
      previously done in the work to support Gitaly features on 10.5.x,
      with dispatch done in the Rails app proper, and based on the `vcs_type`
      project field.
      
      After adaptation, all functional tests pass, with the default Gitaly
      activation of the GDK.
      
      --HG--
      branch : heptapod
      3ebbcd276249
  12. 26 Jan, 2020 1 commit
    • Georges Racinet's avatar
      Gitaly compat: fixing merge initiated from Rails app · 31b88907a857
      Georges Racinet authored
      Same as we did for repository creation, we restore the upstream
      `rugged_merge` lib/ method and put the Mercurial subprocess (popen)
      based version in its own method, that the app/ method calls for
      `hg_git` projects.
      
      There are good chances this does not conflict in lib/ when later on
      we'll climb GitLab versions.
      
      --HG--
      branch : heptapod
      31b88907a857
  13. 25 Jan, 2020 5 commits
    • Georges Racinet's avatar
      Gitaly compat: Commit @parent_ids can be nil · 4be8f5d65a11
      Georges Racinet authored
      Of course that means the commit is a root commit.
      
      Not sure why it couldn't be true in rugged case, but with
      Gitaly, that breaks the init. hg map conversions seem to work fine
      at this point.
      
      --HG--
      branch : heptapod
      4be8f5d65a11
    • Georges Racinet's avatar
      add_hg_repository: simplification and abid to rubocop rules · 95d993e7f48f
      Georges Racinet authored
      - removed useless block
      - yes that `system()` was nasty
      - unless is nicer
      
      --HG--
      branch : heptapod
      95d993e7f48f
    • Georges Racinet's avatar
      add_hg_repository: readability · 5f1874c53fa8
      Georges Racinet authored
      Instead of this shell-like <<EOF that breaks indentation,
      the default HGRC content is now in two constants. They
      could also be imported from elsewhere, or read from a
      configuration file, etc.
      
      --HG--
      branch : heptapod
      5f1874c53fa8
    • Georges Racinet's avatar
      Gitaly compat: Mercurial repo creation · c6194361da75
      Georges Racinet authored
      Before this change, Mercurial repo creation wasn't
      executed if the Git repo was to be created with Gitaly.
      
      This is also the occasion to simplify the diff with respect
      to GitLab.
      
      The add_hg_repository method has useless blocks in this
      commit, just so that the diff against the parent stays
      minimal
      
      We also take care of the wiki even though it's not it use
      within Heptapod so that
      
      - we don't make it worse
      - we don't got in the way of repo destruction (the Git wiki
        repo is removed only after successful remove of the Mercurial)
      
      --HG--
      branch : heptapod
      c6194361da75
    • Georges Racinet's avatar
      Defined the vcs_type Project field for 'heptapod' branch · a16f03e76b31
      Georges Racinet authored
      This is *not* a graft of 57eeafc918c4, but see its
      (long) description to understand the context and our
      choices of migration numbers.
      
      This is expected to conflict in `db/schema.rb` over the
      version number upon merge of `v0.8.0.pre` and that's
      a good thing:
      the merge operator should then
      change the migration file name to be as in 57eeafc918c4
      and keep the schema version number of `0.8.0.pre`.
      
      We needed this
      immediately on the heptapod branch for our attempt to
      support that inner Git access be done with Gitaly (not
      to be confused with Mercurial access be done with HGitaly).
      This attempt is itself a first step towards supporting
      much more recent GitLab versions.
      
      We first tried to merge `v10.8.0.pre` proper as a working
      basis, changes too much of the interplay
      between Rails, Workhorse and Gitaly. We preferred to make
      this workable version first, and deal with
      such potential complications only afterwards.
      
      --HG--
      branch : heptapod
      a16f03e76b31
  14. 02 Jan, 2020 1 commit
    • Georges Racinet's avatar
      source install: using a working version of bcrypt · dd9cefb0ec1e
      Georges Racinet authored
      This unfortunately incompatible with the Docker install for
      the 10.5 series, unless we patch back Gemfile.lock from the
      Dockerfile. This problem will go away as soon as we reach
      v11.2.0.pre, which is the main reason we're using 3.1.12 instead
      of the more recent 3.1.13.
      
      With 3.1.11 on the 10.5 series, we were getting an awful raw memory
      dump instead of the wanted hash. Perhaps that's some mismatch
      with inner crypto libs, anyway this one works for us.
      
      Thankfully, password hashing is followed by immediate check that
      the hash is correct, that's how it's been detected
      
      --HG--
      branch : heptapod
      dd9cefb0ec1e
  15. 16 Jan, 2020 2 commits