1. 19 Oct, 2020 5 commits
  2. 18 Oct, 2020 2 commits
  3. 31 Oct, 2020 2 commits
  4. 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
      branch : heptapod
    • Georges Racinet's avatar
      Hgitaly Client spec: proper description · ab3f23fbc763
      Georges Racinet authored
      branch : heptapod
    • Georges Racinet's avatar
      HgGitRepository spec: adding a missing tear down · 604d53d6b822
      Georges Racinet authored
      That should spare us some headaches down the road
      branch : heptapod
    • 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.
      branch : heptapod
    • 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.
      branch : heptapod
  5. 29 Oct, 2020 1 commit
  6. 30 Oct, 2020 1 commit
  7. 29 Oct, 2020 1 commit
  8. 28 Oct, 2020 2 commits
  9. 26 Oct, 2020 2 commits
  10. 28 Oct, 2020 3 commits
  11. 25 Oct, 2020 2 commits
    • Georges Racinet on mutations.racinet.fr's avatar
      Commit: introducing hpd_display_id · b10c60a26265
      In some cases it makes sense to display a different commit ID than the
      one used for addressing. Of course our existing `HgGitRepository` is
      a prime example of that, but it's not hard to imagine other ones.
      Up to now, we've changed some templates and user-facing to code to
      use directly some 'hgid'. For dual VCS support, as well as intermediate
      steps towards Mercurial native support, we'll need something more
      abstract than that.
      The method name, `hpd_display_id`, is voluntary obnoxious: we want
      to recognize at first glance that it's Heptapod-specific, and we want
      it to be easy to find all occurrences in the code base, in preparation
      for potential future times when we won't be needing it any more.
      branch : heptapod
    • Georges Racinet on mutations.racinet.fr's avatar
      archive_sha: fixing HGitalyRepository · e457db6b841d
      The position of the overriding method was just wrong. This went
      unnoticed because the Mercurial archive feature is for now tested
      with HgGitRepository only.
      branch : heptapod
  12. 26 Oct, 2020 1 commit
  13. 25 Oct, 2020 1 commit
  14. 26 Oct, 2020 7 commits
  15. 14 Oct, 2020 2 commits
    • Georges Racinet's avatar
      Repository archives: dispatching to HGitaly for Mercurial repos · 2e2da0334c73
      Georges Racinet authored
      For archive production, the Rails app duty is to return
      direct connection information to Workhorse, so that it can call
      Gitaly directly.
      We're reusing the dispatching logic for our existing (yet unplugged)
      HGitaly integration: by prefixing the storage (shard) with `hg:` for
      Mercurial repositories, we have the `GitalyClient.address` return
      connection information for the HGitaly server.
      For this to work, we need `archive_metadata` method of the
      Mercurial Repository classes to provide the Mercurial SHA, which we do
      by intoducing the dedicated `archive_sha` method.
      branch : heptapod
    • Georges Racinet's avatar
      Python dependencies: adding HGitaly · f1f3ff16acc1
      Georges Racinet authored
      Of course in the long term, HGitaly will be installed potentially
      on another system, and it wouldn't be the role of the Rails
      application to require it – but the same applies to this whole
      dependencies list, actually.
      Note: hgitaly 0.1.0 already implies py-heptapod>=0.17.0dev0
      branch : heptapod
  16. 13 Oct, 2020 2 commits
    • Georges Racinet's avatar
      Heptapod CI: upgrading hg-evolve · 9431f6af7970
      Georges Racinet authored
      While investigating some failed builds, I found that the
      HGitaly repo couldn't be updated for them (failed pull) and
      that upgrading hg-evolve fixed that, as well as the whole build.
      branch : heptapod
    • Georges Racinet's avatar
      Heptapod CI: putting the HGitaly socket somewhere safet. · 8b67b5f59572
      Georges Racinet authored
      The `tmp/tests` gets wipped except for certain subdirectories
      by `TestEnv` during the actual run, including
      the Unix socket. The `gitaly` subdirectory is preserved, let's
      put the socket in there.
      I've been investigating unrelated build failures, but it's anyway
      a better idea to put that kind of trouble away (if only not to
      waste time on that hypothesis if it's not the cause)
      branch : heptapod
  17. 10 Oct, 2020 1 commit