Read about our upcoming Code of Conduct on this issue

  1. 26 Nov, 2020 1 commit
  2. 08 Oct, 2020 1 commit
  3. 25 Nov, 2020 1 commit
  4. 18 Nov, 2020 1 commit
  5. 20 Nov, 2020 1 commit
    • Georges Racinet's avatar
      Re-separate GitLab and Heptapod Workhorse versions · 0fd9ec6fa027
      Georges Racinet authored
      The reason is that the RSpec launch sequence really
      installs GitLab Workhorse (that does not matter for
      the time being), using `Gitlab::Workhorse::version`.
      Of course if that is actually Heptapod Workhorse
      version we have a problem.
      
      In the helper (used only in the admin dashboard), it's
      taken from headers anyway, but still we provide
      an appropriate fallback method
      
      (grafted from 24ca3aba6354,
      this was a last-minute fix to let the CI do its job, that
      was validating the release)
      
      The question of really installing Heptapod Workhorse will
      stay irrelevant for a while: we would need to
      - launch tests that use Workhorse
      - that the difference between GitLab and
        Heptapod Workhorse actually matters.
      
      --HG--
      branch : heptapod
      0fd9ec6fa027
  6. 16 Nov, 2020 1 commit
    • Georges Racinet's avatar
      Branch acces checks: direct identification of legit merges · 948dac54b949
      Georges Racinet authored
      Closes #368
      
      To let merges done from the Rails application be checked
      against the distinct set of merge rules rather that push
      rules, GitLab looks for MRs matching the pre-receive changes by
      comparing with the merge commit sha that's always available
      (and set by the Repository Model) before the actual branch move.
      
      Because the Mercurial change can be atomic, we have no other
      option than passing a special parameter down from
      `Repository#merge` through the Mercurial backend, with the
      `HEPTAPOD_ACCEPT_MERGE_ID` environment variable.
      In turn the Mercurial process will add it to its pre-receive
      hook payload, and the target branch can be compared to switch
      from (direct) push to (Rails) merge mode.
      
      In the case of merges intended from the very beginning to be
      fast forwards, the commit sha is already known in advance,
      but we're using the same mechanism for consistency in the
      check.
      
      Finally, there was a good dose of wrestling with those RSpec
      examples that care about merging to a protected branch, because
      of the on-demand nature of instantiation.
      
      --HG--
      branch : heptapod-stable
      948dac54b949
  7. 15 Nov, 2020 1 commit
  8. 09 Nov, 2020 1 commit
  9. 07 Nov, 2020 5 commits
    • Georges Racinet's avatar
      multi-vcs: restrict Project creation Web UI according to app setting · 1c314c133569
      Georges Racinet authored
      In the helper, we're now making the distinction between all
      possible values and those that are enabled in the application settings.
      
      In the default value, we're in particular treating the corner case
      where the library-level default is not allowed by Application Settings.
      It is not expected with the current possible values to happen often,
      but one may even imagine people restricting to Git as part as a
      transition plan from upstream GitLab CE to Heptapod.
      
      We don't want to do the same for the API, because the default
      is quite arbitrary in that case, and it's not guaranteed a
      human being would be witnessing its value.
      
      --HG--
      branch : heptapod
      1c314c133569
    • Georges Racinet's avatar
      multi-vcs: validate Project vcs_type against Application Settings · e90fbe3ee00f
      Georges Racinet authored
      Now that we have the `vcs_types` Application Settings field,
      we use it to enforce upon Project creation that the selected
      `vcs_type` is among them.
      
      This validation has to be done by a separate method in order
      to access the `CurrentSettings` object.
      
      Also, we've considered making the default value for `vcs_type` in
      `CreateService` not to be the library-level default, so that
      explicitely passing a value is never required, even in the case where
      the library default is not allowed by Application Settings, but
      finally decided that failing with an explicit message in that case
      was better than such magic. Note also that the Web UI will always
      pass a value, so this case is in practice for API calls only.
      
      --HG--
      branch : heptapod
      e90fbe3ee00f
    • Georges Racinet's avatar
      multi-vcs: centralizing the default VCS type · e6e8952549c8
      Georges Racinet authored
      it's obviously bad to have a magic constant in the service,
      given that we already have one in `Gitlab::VCS`.
      
      --HG--
      branch : heptapod
      e6e8952549c8
    • Georges Racinet's avatar
      multi-vcs: application settings panel to set VCS types on new projects · dfa98ee0aa7a
      Georges Racinet authored
      This allows to fill in the new `vcs_types` field.
      
      --HG--
      branch : heptapod
      dfa98ee0aa7a
    • Georges Racinet's avatar
      Abiding to some Rubocop rules · 601956cea856
      Georges Racinet authored
      I'm especially not happy with the trailing comma rule in
      Hashes, but doing it anyway.
      
      --HG--
      branch : heptapod
      601956cea856
  10. 05 Nov, 2020 1 commit
  11. 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
  12. 03 Nov, 2020 7 commits
  13. 01 Nov, 2020 1 commit
    • Georges Racinet's avatar
      Displaying Heptapod versions in admin panel · 10ce53f8da96
      Georges Racinet authored
      While the Shell version is directly taken from the VERSION file
      (now HEPTAPOD_SHELL_VERSION), the Workhorse version is by
      default taken from the HTTP header that Workhorse adds, ultimately
      set at build time from the latest tag, with additional information
      if built on a changeset with no tag.
      We only change the way the header is parsed, to take into account
      the additional `heptapod-` prefix it has.
      
      --HG--
      branch : heptapod
      10ce53f8da96
  14. 30 Oct, 2020 1 commit
    • 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
  15. 29 Oct, 2020 1 commit
  16. 28 Oct, 2020 2 commits
  17. 26 Oct, 2020 2 commits
  18. 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
  19. 26 Oct, 2020 2 commits
    • Georges Racinet's avatar
      User#can_create_project_in_group? takes Group config into account · 15937daf2934
      Georges Racinet authored
      This concludes #361: the previous implementation was only
      checking if there's at least a group where the user has Developer
      role, whereas it actually depends on the group configuration.
      
      It's possible that this is partly redundant with
      `groups_with_developer_maintainer_project_access`, but it's
      hard to be sure, and we're careful to stop as soon as we have
      at least a match.
      
      --HG--
      branch : heptapod-stable
      15937daf2934
    • Georges Racinet on mutations.racinet.fr's avatar
      Projects::CreateService: enforce creation rights in personal namespace · 38367c18c1c8
      This is the non-UX part of #361: we're now enforcing at the
      service level that `User#can_create_project_in_personal_namespace?` is
      called, where it could have been bypassed.
      
      It would be arguably better to just add a similar check in
      `user.can?(:create_project, namespace)`, but that would be harder and
      perhaps more dangerous, especially on the stable branch.
      
      At least, we now have RSpec tests to back us for this.
      
      --HG--
      branch : heptapod-stable
      38367c18c1c8
  20. 24 Sep, 2020 2 commits
    • Georges Racinet's avatar
      Merge Requests: ability to change source branch via Web UI · 3a77d1e79440
      Georges Racinet authored
      This needs a JavaScript change, that we're performing trying to minimize
      impact (still storing the select on $this) while avoiding code duplication.
      
      We're trying to get duplication in the HAML template low, but there's only
      so much that can be done there.
      
      --HG--
      branch : heptapod-stable
      3a77d1e79440
    • Georges Racinet's avatar
      Merge Requests: allowing to change source branch, API only · 8705522bb21d
      Georges Racinet authored
      This is the inner part of #138: we have to lift the
      restrictions against the change of that column precisely,
      expose it in the API, and do the post-treatment (system note,
      cancellation of automatic merge).
      
      The diff invalidation in app/models/repository.rb was already
      taking this case into account.
      
      --HG--
      branch : heptapod-stable
      8705522bb21d
  21. 19 Sep, 2020 1 commit
  22. 21 Sep, 2020 2 commits