1. 07 Nov, 2020 3 commits
  2. 05 Nov, 2020 1 commit
  3. 08 Nov, 2020 3 commits
  4. 07 Nov, 2020 2 commits
    • Georges Racinet's avatar
      gitaly_client: plugging in HGitaly in CommitService · d3f9a208d676
      Georges Racinet authored
      This is more complicated than what we've done earlier for
      `RefService`:
      
      - Upstream passes down storage to `GitalyClient.call` as
        `@repository.storage`. We don't want to change all methods
        of CommitService because it wouldn't apply readily to new
        methods from upstream.
        Hence we actually re-instantiate `@repository`,
        with the VCS-qualified storage, with the new `vcs_storage_clone`
        method. On the side, this also requires a small change
        in HgGitRepository to make the value admissible.
      - only a subset of Commit service methods are actually involved
        in our first round of HGitaly implementation (getting rid of
        Git SHAs, see HGitaly1 milestone). We're deciding here that
        the other methods will use directly the original storage name,
        that we store as a new instance variable, `@git_storage`.
        In particular, we're trying to avoid the implementation of the
        various methods for Commit content (files, trees, diffs…) for
        the HGitaly1 milestone. This part is WIP (we'll need to
        convert back to Git revisions to complete it).
      - Finally, this hack also requires to make sure that the resulting
        Commit instances refer to the original Repository, so that further
        (H)Gitaly calls done from these Commits don't reuse a VCS-qualified
        storage, which would defeat the very purpose of separation.
      
      This is all very hacky. The only thing that makes it admissible is
      that it is temporary scaffolding. For the HGitaly2 milestone, all
      methods will go to HGitaly, and perhaps we can convince upstream to
      use a `@storage` instance variable here for the sake of uniformity.
      
      --HG--
      branch : heptapod
      d3f9a208d676
    • Georges Racinet's avatar
      HGitalyRepository: comments about SHA/ID conversion methods · 3639ef277c7e
      Georges Racinet authored
      --HG--
      branch : heptapod
      3639ef277c7e
  5. 31 Oct, 2020 3 commits
    • Georges Racinet's avatar
      Multi VCS UI: vcs_type now visible on Project · caf61ae7e63d
      Georges Racinet authored
      This is the bare minimum to avoid confusion. Of course, it would
      be nicer to have icons.
      
      We decided not to display anything for
      the default VCS type, partly because it would perhaps be puzzling
      for instances that only allow the default type (instance-level
      settings will probably be introduced later) and also because it's
      too early in the multi VCS effort to loudly show that something's
      changed.
      
      --HG--
      branch : heptapod
      caf61ae7e63d
    • Georges Racinet's avatar
      Multi VCS UI: choice of type upon creation · 1c4a3416125f
      Georges Racinet authored
      --HG--
      branch : heptapod
      1c4a3416125f
    • Georges Racinet's avatar
      Project model: validation of vcs_type · 53af134a42a1
      Georges Racinet authored
      This is simply ensuring the value is a support type
      
      We're testing this twice (model and service) because `project_spec`
      is not yet in the Heptapod CI shortlist and it takes too much time
      that such a trivial test would be worth it. Of course, it has
      its intrinsic value, and we will activate it soonish, but that's not
      the current concern. Also this prepares for potentially more advanced
      behaviour at the service level.
      
      --HG--
      branch : heptapod
      53af134a42a1
  6. 03 Nov, 2020 7 commits
  7. 28 Oct, 2020 1 commit
  8. 02 Nov, 2020 1 commit
  9. 01 Nov, 2020 5 commits
  10. 30 Oct, 2020 5 commits
    • Georges Racinet's avatar
      Heptapod CI: now running for Merge Requests · 4d26d7c5b353
      Georges Racinet authored
      The big drawback of the manual triggering is that we have
      to allow failures, which makes it dangerous for MRs with the
      "Merge when pipeline succeeds button" (happened with !119).
      
      Now we're running for MR events, still keeping the manual option
      in other cases, but without a default rule in order to be spared
      warnings.
      
      --HG--
      branch : heptapod
      4d26d7c5b353
    • Georges Racinet's avatar
      Hgitaly Client spec: proper description · ab3f23fbc763
      Georges Racinet authored
      --HG--
      branch : heptapod
      ab3f23fbc763
    • Georges Racinet's avatar
      HgGitRepository spec: adding a missing tear down · 604d53d6b822
      Georges Racinet authored
      That should spare us some headaches down the road
      
      --HG--
      branch : heptapod
      604d53d6b822
    • Georges Racinet's avatar
      RSpec HGitalyRepository: fixes for hgsha_from_sha now being identity · 23494d896c42
      Georges Racinet authored
      Since the HGitaly `CommitService` is not in use yet, the `commit` method
      of `HGitalyRepository` still returns the Git commit converted from the
      Mercurial commit. Before we changed `hgsha_from_sha` to just return the
      incoming SHA for HGitalyRepository (which is eventually the proper behaviour),
      we had it actually converting to Mercurial (as with `HgGitRepository`).
      Since that's not the case any more, we have to use another way to
      find the Mercurial SHA.
      
      Also, in the tag case, the lazyness was making *both* SHAs being for
      the changeset creating the tag and its Git counterpart, because they
      were evaluated after tag creation. The simples solution here is to make
      it imperative.
      
      --HG--
      branch : heptapod
      23494d896c42
    • Georges Racinet on mutations.racinet.fr's avatar
      Git Merge Requests detection: restoring upstream call · 447be67b55d1
      I honestly can't find where this `head_source_sha` did come from.
      It actually looks like a plain mistake. Anyway, the point is that
      in the Git case, outside of the conditionals triggering Mercurial
      specific code, we should do the same thing as upstream.
      
      This is enough to fix a basic MR detection functional test.
      
      --HG--
      branch : heptapod
      447be67b55d1
  11. 29 Oct, 2020 1 commit
  12. 30 Oct, 2020 1 commit
  13. 29 Oct, 2020 1 commit
  14. 28 Oct, 2020 2 commits
  15. 26 Oct, 2020 2 commits
  16. 28 Oct, 2020 2 commits
    • Georges Racinet on mutations.racinet.fr's avatar
      Commit model: hpd_short_display_id · 9c9230fcb76f
      Whereas `#hpd_display_id` is implemented on the raw commit, this
      one is easier at the model level, the intended result depending only
      on whether it's Mercurial or not.
      
      It seems like a good idea to let only the "app" layer of the Rails
      application bother about short ids, which are after all presentation
      businesss - unless we later find out the dance with the `truncate_sha`
      classmethod is a performance sink.
      
      Test is minimal, but enough to guarantee we're calling other methods
      with the proper arguments.
      
      --HG--
      branch : heptapod
      9c9230fcb76f
    • Georges Racinet on mutations.racinet.fr's avatar
      Commit model: making truncate_sha optionally VCS-aware · 2cd1251472b2
      This being a class method, we have to pass a `context` explicitely,
      but it'll give us a chance to keep duplication low on generation of
      short SHAs.
      
      --HG--
      branch : heptapod
      2cd1251472b2