Skip to content
Snippets Groups Projects
  1. Oct 28, 2021
    • Georges Racinet's avatar
      Tests: force pytest<6 to workaround problem with error.Hint · 09870b83
      Georges Racinet authored
      This solves this problem in tests of testhelpers:
      
              # actual error is FilteredRepoLookupError up to 5.9 and will
              # be InputError in 6.0 (current default head of Mercurial, does not
              # bear the version yet)
      >       with pytest.raises(error.Hint) as exc_info:
      E       TypeError: expected exception must be a BaseException type, not Hint
      heptapod/testhelpers/tests/test_repo_wrapper.py:54: TypeError
      
      The queston would be whether it'd be reasonable to make `error.Hint`
      subclass `Exception` (or `BaseException`).
      
      Also pytest<6 works for me, but that doesn't mean pytest 6.0.0 was the
      one to start demanding exceptions to be subclass `BaseException`.
      09870b83
  2. Oct 25, 2021
  3. Oct 17, 2021
  4. Oct 12, 2021
  5. Oct 17, 2021
    • Georges Racinet's avatar
      test_integration: preparations to derive as tests without Git · 66f073f6
      Georges Racinet authored
      These should be only spelling and type changes, meant so that
      the diff with the future tests of a native state maintainer without
      a Git repository are easier to compare with these.
      
      This explains some weird line breaks, such as:
      
      ```
          wrapper.commit_file(
              'foo', message='some msg')
      ```
      
      because it will become in the tests for the future class something
      like
      
      ```
          ctx = wrapper.commit_file(
      ```
      
      with the second line unchanged.
      
      We also take the opportunity to modernize the calls to the
      deprecated `write_commit()`.
      66f073f6
    • Georges Racinet's avatar
      test_integration: fixed and factorized test_topic_rebase_publish() · 4c4b5369
      Georges Racinet authored
      Because of a missing `parent` keyword in `write_commit()`, the
      rebase was actually trivial.
      
      The factorization with `test_topic_add_rebase_publish()` will
      make it easier to adapt for the future state maintainer with no
      Git repo.
      4c4b5369
    • Georges Racinet's avatar
      prune_reasons.BranchClosed: keep tuples in native back-conversion · 7f4f24fa
      Georges Racinet authored
      The back conversion was converting the 2-tuple to a list of
      length 2.
      
      This didn't change anything in the end serialization (`json`
      converts tuples and lists alike anyway), but it was a small pain
      for the writing of uniform test cases for future native state
      maintainers without any back-conversion.
      7f4f24fa
    • Georges Racinet's avatar
      testhelpers.gitlab: new assert_default_gitlab_branch() method · c5b6b9f8
      Georges Racinet authored
      This makes `git.test_integration` more readable and will be used
      identically in tests for the future state maintainer with no Git
      repository.
      c5b6b9f8
  6. Oct 11, 2021
    • Georges Racinet's avatar
      Ensuring GitLab state files: do not create Git repository · bdf76740
      Georges Racinet authored
      In the fully native mode, without any conversion to Git, it will
      still be potentially useful to be able to read a leftover Git repo
      if the GitLab project was marked as fully native without the
      expected call to the various `ensure_*` methods.
      
      But we don't want any Git repo to be created, and that is a
      side effect of using `self.git.refs`.
      
      In Heptapod functional tests, we will add assertions on absence
      of Git repo to be 100% sure that they pass without any unwarranted
      help (one could imagine first an empty repo, then a push would
      trigger the mirror and suddenly one is not testing the fully native
      mode as expected).
      
      It would be tempting to init the default GitLab branch directly
      as `branch/default`, but that would be the implicit false promise
      that there is a commit on the `default` branch, and our logic
      to correct the initial default Gitlab branch name is probably not
      able to cope with that. So better keep the default Git value.
      bdf76740
    • Georges Racinet's avatar
      Test fixtures: extracted a GitLabStateMaintainerFixture base class · ebfb0b7b
      Georges Racinet authored
      It will be useful to test the future `NativeStateMaintainer` class
      ebfb0b7b
    • Georges Racinet's avatar
      testhelpers: testing the GitRepo helper class · 2eb152fa
      Georges Racinet authored
      Some methods of this class will soon not be used by py-heptapod's integration
      tests. Since they can be useful downstream in HGitaly, we need to keep them
      and cover them directly.
      2eb152fa
  7. Oct 13, 2021
  8. Oct 11, 2021
  9. Aug 03, 2021
  10. Jul 05, 2021
  11. Jul 01, 2021
    • Georges Racinet's avatar
      Merged heads on default branch · 1d2e5b26
      Georges Racinet authored
      That is why it's not so good an idea to make a topic for release
      matters (forgot to update after pull). In that precise case, it's
      not worth a new version
      1d2e5b26
    • Georges Racinet's avatar
      New dev cycle · a3cb1972
      Georges Racinet authored
      a3cb1972
    • Georges Racinet's avatar
      591b89a6
    • Georges Racinet's avatar
    • Georges Racinet's avatar
      GitLab Hooks: making sure repo object is used only for path and ui · 7b46103e
      Georges Racinet authored
      Because the post-receive hook is now called in the locks release
      callback, we need to make sure it doesn't use anything that the
      release just invalidated, notably weak refs.
      
      But the hooks were only using the repository object for
      
      - the path to the repository (taking sharing into account)
      - `repo.ui`
      
      We now extract these two elements, and immediately delete the
      reference to the repository object. Both linters and the tests
      with full coverage complete the proof that no other use is
      occurring.
      7b46103e
    • Georges Racinet's avatar
      post-receive: fire after locks release · c81b287a
      Georges Racinet authored
      This is a merge of change done on the stable branch, where
      it was restricted to Merge Request creations by pushvars to
      limit the risks.
      
      In all cases, it makes sense to send the post-receive only after
      new writes are permitted, because there's no telling what writes
      the Rails app would need to perform directly.
      
      As far as I understand, Git locking is weaker than Mercurial's,
      as it happens on a file-per-file basis. That's why the Rails app
      could easily grow new problematic writes that wouldn't be rejected
      by locks in the Git case.
      c81b287a
Loading