Skip to content
Snippets Groups Projects
  1. Jun 28, 2020
    • Georges Racinet's avatar
      subrepos: forbid any pull of subrepos on the server side · 75d393740150
      Georges Racinet authored
      See heptapod#311
      
      Subrepos are not needed to update a file, or to perform a
      merge. In a later version, we could simply neutralize the
      pull, but then we'd have to make sure that the commit logic
      is consistent (that's why commits are forbidden separately,
      too).
      
      In current Heptapod, the use of updates is always within
      shares used for server side operations and mergeability
      assessment. This change will prevent
      projects using subrepos to trigger hundreds of pulls that will
      take too much time, and create resource problems (maybe
      banning risks even) for hazardeous success anyway.
      75d393740150
    • Georges Racinet's avatar
      subrepos: a hook to forbid server-side commits · 89aaf7286fe7
      Georges Racinet authored
      See heptapod#311 for rationale
      89aaf7286fe7
  2. Jun 29, 2020
    • Georges Racinet's avatar
      git for subrepos: more robust parsing of .hgsub · eec9087800f7
      Georges Racinet authored
      We'd still have a long way to go for proper subrepositories
      support in Heptapod. With this change, at least, we won't get
      errors because a `.hgsub` file has a `subpaths` section.
      
      More precisely, we're using the same config parser as Mercurial
      does for this file.
      eec9087800f7
  3. Jun 26, 2020
  4. Jun 24, 2020
  5. Jun 18, 2020
  6. Jun 17, 2020
    • Georges Racinet's avatar
      branch: branchmap to gitlab branch conversion utilities · 9b95ea74c395
      Georges Racinet authored
      The provided `branchmap_branch_from_gitlab_branch()` is not
      equivalent to the `GitHandler.git_branch_for_branchmap_branch()`
      method, whose purpose is also to gate invalid new content, and
      needs a `ui` object for user feedback.
      
      When we drop the hg-git conversion, we'll do such validations
      separately.
      9b95ea74c395
    • Georges Racinet's avatar
      heptapod.gitlab.branch, split out of hgext3rd.heptapod.git · 311cd85da3bc
      Georges Racinet authored
      The pure bytes-string manipulation functions will need to
      be cleanly reused from elsewhere, and notably in HGitaly.
      
      This is also an opportunity to normalize and explain the
      terminology.
      311cd85da3bc
    • Georges Racinet's avatar
      git: setting default branch from Mercurial side · 6686c1b1d714
      Georges Racinet authored
      With the new storage of the default GitLab branch in the Mercurial
      repository, we need to set it as soon as possible,
      in preparation for when that's the
      only thing GitLab will see (instead of the Git HEAD).
      
      We need to set it, even if we have to choose a topic or a bookmark
      for that, and therefore we're doing it also for the Git repository,
      in order for the information to be consistent.
      
      So instead of choosing a named branch only if a previous value randomly
      chosen by other GitLab component was a topic, we build two sets
      of candidates, and pick among non named branches only if there's
      no named branch.
      
      The only case where we don't set it is if there are only wild
      heads *and* the special config item to refuse to choose among them
      is in place (there would be a "non wild" head otherwise)
      6686c1b1d714
    • Georges Racinet's avatar
      Storing and retrieving the default GitLab branch name · bd087392abb5
      Georges Racinet authored
      This new data is used often by GitLab, sometimes in an
      indirect way, as a default, that's why it's about the first
      thing to implement for Mercurial to get native in Heptapod.
      bd087392abb5
    • Georges Racinet's avatar
      testhelpers: timestamp parameter for write_commit() · 2072491733e4
      Georges Racinet authored
      This new option was available on the HGitaly side, so we'll need to
      provide it from here.
      2072491733e4
    • Georges Racinet's avatar
      testhelpers: returning changectx from write_commit() by default · e83bea02e7c5
      Georges Racinet authored
      This had been done long ago on the HGitaly side, which had actually
      until recently the only Python 3 version of those test helpers.
      
      We're keeping the slightly awkward `return_ctx` though, just changing
      its default value. The `parent` parameter now accepts both `changectx`
      instances and binary node ids, so that we don't have to update all
      the tests that make use of it.
      
      Finally, we keep the coverage at 100%, even if launching only
      the tests of the test helpers.
      e83bea02e7c5
    • Georges Racinet's avatar
      heptapod-ci: make sure we test with the expected Python version · d56fbe7f9427
      Georges Racinet authored
      with recent (and future) changes in the base images, with pytest
      for Python3 not necessarily having the '3' in its executable name,
      this felt necessary: otherwise we'd keep wondering all the time.
      d56fbe7f9427
    • Georges Racinet's avatar
      63d6a4113c7a
  7. Jun 16, 2020
  8. Jun 15, 2020
  9. Jun 14, 2020
  10. Jun 10, 2020
  11. Jun 13, 2020
    • Georges Racinet's avatar
      pull-force-topic: fixed py3 compat issue · 7f69f2b216b7
      Georges Racinet authored
      Closes heptapod#292
      
          File "mercurial/bundlerepo.py", line 481, in makebundlerepository
            url = b'bundle:%s+%s' % (util.expandpath(repopath), bundlepath)
        TypeError: %b requires a bytes-like object, or an object that
                   implements __bytes__, not 'str'
      
      Not detected by test because `makebundlerepository()` is called
      only for non-local repositories.
      7f69f2b216b7
  12. Jun 10, 2020
  13. Jun 09, 2020
  14. Jun 08, 2020
    • Georges Racinet's avatar
      GitLab hooks: sending hg_prune payload · 11949a1466bc
      Georges Racinet authored
      We need to serialize the hg_prune field itself as JSON, since the
      GitLab internal API would accept only plain string as values on the
      other side (or we'd have to go to great length with the `Hash` param
      type to produce the flexibility we need).
      
      GitLab branch names are received as bytes and output as base64 in the
      resulting payload, leaving the burden to guess the encoding to the Rails
      application. This is less cowardly as it sounds: on the Rails side, there's
      already a layer of decoding and encoding guesswork for the `changes`
      parameter (identical to a Git post-receive stdin payload). Hence, we'll
      be able to use the same system for consistent results.
      11949a1466bc
  15. Jun 07, 2020
    • Georges Racinet's avatar
      GitLab hooks: reduced duplication · 561605221ea1
      Georges Racinet authored
      The request firing and first error treatments are
      now done in the base Hook class, thanks to the new
      'api_endpoint` class attribute.
      561605221ea1
    • Georges Racinet's avatar
      Git: extracting prune reasons and passing them to gitlab.hooks · 85141e35eca6
      Georges Racinet authored
      Part of heptapod#269
      
      The prune reasons are given as a dict mapping GitLab branch names to
      `HeadPruneReason` instances.
      
      At this point the `gitlab.hooks.PostReceive` class will just
      ignore the prune reasons, the next move will be to send them
      alongside the usual changes (now called `git_changes`) to the
      new API endpoint.
      
      This is almost compatible with the previous operation, except
      that merge request detection wouldn't work for topics, since
      we're pruning them right away and we don't have the new GitLab
      logic yet.
      
      No details are provided for closed branches, but we have the
      infrastructure to do so.
      85141e35eca6
    • Georges Racinet's avatar
      GitLab hooks: reorganized in subclasses · 0aeb0de073dc
      Georges Racinet authored
      The design dated back to the time when the Hook class was
      merely a wrapper to call external executables provided by
      GitLab, whose file name was actually `self.name`.
      
      It's much clearer to specialize them in the `PreReceive` and
      `PostReceive` classes.
      
      On the `hgext3rd.heptapod.git` side, we had the `_gl_repos`
      attribute to avoid multiple instantiations (dating back from
      the triple inner push era) and everything was also string oriented.
      It's much simpler and no less efficient to instantiate the
      proper hooks in `heptapod_apply_changes`.
      0aeb0de073dc
    • Georges Racinet's avatar
      Representation for reasons a GitLab branch can be pruned · 132b19233a88
      Georges Racinet authored
      The idea is that we are going to develop a "post-receive" hook
      to pass additional Mercurial information to GitLab. This new
      hook and its supporting data classes should survive the move to
      native Mercurial, hence `heptapod.gitlab` should be the right
      place to put them.
      
      It would be tempting to use `attrs` for these simple data
      classes, and maybe we will. For now, let's just not add
      dependencies.
      132b19233a88
Loading