heptapod issueshttps://foss.heptapod.net/groups/heptapod/-/issues2020-05-06T18:23:38Zhttps://foss.heptapod.net/heptapod/heptapod/-/issues/258Target branch of the new Merge Request suggestion2020-05-06T18:23:38ZGeorges RacinetTarget branch of the new Merge Request suggestionThis is related to #138, but has apparently never been filed.
The Merge Request creation suggested link that one gets upon pushes always relates to the default (GitLab) branch, but that's not expected for Mercurial topics, whose changes...This is related to #138, but has apparently never been filed.
The Merge Request creation suggested link that one gets upon pushes always relates to the default (GitLab) branch, but that's not expected for Mercurial topics, whose changesets already contain the logical target branch.
For a typical example, assuming the default GitLab branch to be `branch/default`: If I have a `stable` branch and I push changesets for that branch with the topic `bugfix`, hence creating a `topic/stable/bugfix` GitLab branch, but the MR suggestion link would be to merge into `branch/default` instead of the expected `branch/stable`.
On a project such as Heptapod itself, where the difference between a stable branch and the default is often several thousands of changesets, this stresses the web application with a huge diff. The target branch can be corrected afterwards, but that's painful for no good reason. In some cases, it can lead to unwanted merges, manual grafts or backports etc.Heptapod 0.12.2https://foss.heptapod.net/heptapod/heptapod/-/issues/256"New project" not displayed even if creation is possible2021-03-30T18:20:30ZGeorges Racinet"New project" not displayed even if creation is possible# Summary for users
If you have a group and can't find how to create a project, just go to your group.
The "New project" button will be visible if you have at least Developer rights on the group. Make sure then to
create the project i...# Summary for users
If you have a group and can't find how to create a project, just go to your group.
The "New project" button will be visible if you have at least Developer rights on the group. Make sure then to
create the project in the group, not in a user namespace.
# Details
For users that have reached their limit of project creation (which is 0 for "external users") and have at least Devloper rights in some group, the current state is inconsistent: GitLab won't display the "New project" button nor the option in the "+" dropdown menu **unless they are viewing the group**. In the context of the group, these are displayed and the creation succeeds.
One could argue that a user with a limit of 0 should not be able to create any project, but some prominent instances actually rely on this: they set all users to external by default to prevent project creation in *personal namespaces*. This is notably the case of the present one, but also of [heptapod.host](https://about.heptapod.host), for different reasons.
In the long term, it would probably be better to have a setting to disable personal namespaces without setting the users to external. For now, this is a major UX inconsistency bug.
- [x] if the current user actually can create a project, then the option should always been displayed.
- [x] if the user cannot create a project in the personal namespace, the latter should not be an option in the blank project creation page
- [x] if the current user can create a project, but not in the personal namespace, then the default namespace in the project creation page should be a suitable group
- [x] similar defaults and options for the Bitbucket import pageHeptapod 0.12.2Georges RacinetGeorges Racinethttps://foss.heptapod.net/heptapod/heptapod-tests/-/issues/7Functional tests for CI2020-05-06T18:20:32ZGeorges RacinetFunctional tests for CIIt will be necessary for the likes of heptapod#145
We need a new fixture, representing a pseudo runner that we register against the Heptapod server.
With that runner, we'll be able to query the jobs API, and check that the proper jobs ...It will be necessary for the likes of heptapod#145
We need a new fixture, representing a pseudo runner that we register against the Heptapod server.
With that runner, we'll be able to query the jobs API, and check that the proper jobs are dispatched.Heptapod 0.12.2https://foss.heptapod.net/heptapod/heptapod/-/issues/217Implement squash commits option2020-04-30T21:11:03ZPierre-Yves DavidImplement squash commits optionA new "Squash Commits" appears for merge request.
I don't expect this option to work. So we should hide it for now.
@gracinet speaking after analysis: not hideableA new "Squash Commits" appears for merge request.
I don't expect this option to work. So we should hide it for now.
@gracinet speaking after analysis: not hideableHeptapod 0.12.2https://foss.heptapod.net/heptapod/heptapod/-/issues/281Assertions for removal of Git auxiliary repository2020-05-29T10:48:44ZGeorges RacinetAssertions for removal of Git auxiliary repositoryWe need more assertions in project removal tests.
Original false alarm:
On the current heptapod-0-13 branches, I'm seeing cases of auxiliary Git repositories not being properly removed upon project removal.
Not clear at this point whe...We need more assertions in project removal tests.
Original false alarm:
On the current heptapod-0-13 branches, I'm seeing cases of auxiliary Git repositories not being properly removed upon project removal.
Not clear at this point when this regression happened, but I don't want it in Heptapod 0.13.0Heptapod 0.13.0https://foss.heptapod.net/heptapod/heptapod/-/issues/280Server-side rebase for topics2020-05-28T22:22:20ZGeorges RacinetServer-side rebase for topicsThis is a common requisite of #132 and #200.
Merge requests with the "fast-forward" and "semi-linear" methods display a "rebase" button if the history is not linear, but it isn't working because Mercurial rebase has not been implemented...This is a common requisite of #132 and #200.
Merge requests with the "fast-forward" and "semi-linear" methods display a "rebase" button if the history is not linear, but it isn't working because Mercurial rebase has not been implemented in Heptapod.
I was vaguely remembering we hid the button, but it's not the case on Heptapod ≥ 0.12 (hence the "Bug" label).
There is also a [Merge Request rebase API method](https://docs.gitlab.com/ce/api/merge_requests.html#rebase-a-merge-request).
To avoid some complications, we can for now consider only the case of topics – with the default settings they are logically equivalent to drafts.Heptapod 0.13.0https://foss.heptapod.net/heptapod/heptapod/-/issues/279Import Wikis from Bitbucket2020-05-28T20:57:18ZGeorges RacinetImport Wikis from BitbucketAll said in titleAll said in titleHeptapod 0.13.0https://foss.heptapod.net/heptapod/heptapod/-/issues/275Backup wikis2020-05-23T12:24:39ZGeorges RacinetBackup wikis(and test them)
On 0.13.0rc1, the backup of wikis fails with `[WARNING] Executing undefined method `vcs_type' for #<ProjectWiki:0x0000558696ee1d90>`(and test them)
On 0.13.0rc1, the backup of wikis fails with `[WARNING] Executing undefined method `vcs_type' for #<ProjectWiki:0x0000558696ee1d90>`Heptapod 0.13.0https://foss.heptapod.net/heptapod/heptapod/-/issues/271Provide Python version in help and admin pages2020-05-21T17:34:29ZGeorges RacinetProvide Python version in help and admin pagesWith the current plans for dual Python version support in 0.13.x, we'll need an easy way to know.With the current plans for dual Python version support in 0.13.x, we'll need an easy way to know.Heptapod 0.13.0https://foss.heptapod.net/heptapod/heptapod-docker/-/issues/5Main image: install Rails from a tarball2020-09-24T11:28:13ZGeorges RacinetMain image: install Rails from a tarballSince the very beginning of the Heptapod project, we've made a full repository of the various GitLab components in the Docker image, notably the Rails application.
It's been really useful for development, allowing to use Mercurial direc...Since the very beginning of the Heptapod project, we've made a full repository of the various GitLab components in the Docker image, notably the Rails application.
It's been really useful for development, allowing to use Mercurial directly to manage the sources, but it's very heavy and slow to build, even with the various mitigations that we have (prewarm in an early layer, pull a precise branch or revision).
Later on, the `heptapod-dev` image has been introduced, with its separate set of "live" revisions and some utilities. Because the `heptapod` clone is already there in the main image, `heptapod-dev` itself is relatively thin.
Nowadays, `heptapod-dev` is less important for development. It would be fair if the main image was constructed out of a tarball and the heavy conversion into a repository would be done in `heptapod-dev`. The build would be way faster, and the image would weigh some hundreds of megabytes less.
The external clone/pull of a source repository for exposition as a tarball to `Docker build` has to be done anyway for #4
Same could be done with heptapod-shell, but it's mildly more complicated and the benefits are smaller. Also, once we are on GitLab 12.4, it will be a pure Go component, externally compiled like `heptapod-workhorse`.Heptapod 0.13.0https://foss.heptapod.net/heptapod/heptapod-docker/-/issues/4Put Heptapod Workhorse in the Docker image2020-05-05T09:16:07ZGeorges RacinetPut Heptapod Workhorse in the Docker imageSince Heptapod Workhorse will be mandatory in Heptapod 0.13, this is necessary.
At this point, it won't be useful to have a separate Docker image for Heptapod Workhorse, because communication with the `hgserve` backend must still be loc...Since Heptapod Workhorse will be mandatory in Heptapod 0.13, this is necessary.
At this point, it won't be useful to have a separate Docker image for Heptapod Workhorse, because communication with the `hgserve` backend must still be local. Still we can use the [multistage build patter](https://docs.docker.com/develop/develop-images/multistage-build/), and later on decide to push `octobus/heptapod-workhorse` separately.Heptapod 0.13.0https://foss.heptapod.net/heptapod/heptapod/-/issues/255Always include Heptapod Workhorse2020-05-15T19:18:32ZGeorges RacinetAlways include Heptapod WorkhorseIn Heptapod 0.13, Heptapod Workhorse will be always provided and mandatory. That means:
- [x] remove temporary HTTP code in the Rails application that was circumventing the lack of Heptapod Workhorse
- [x] build and include in the Docke...In Heptapod 0.13, Heptapod Workhorse will be always provided and mandatory. That means:
- [x] remove temporary HTTP code in the Rails application that was circumventing the lack of Heptapod Workhorse
- [x] build and include in the Docker image
- [x] bump Heptapod Workhorse to the version needed for GitLab version in Heptapod 0.13.0Heptapod 0.13.0https://foss.heptapod.net/heptapod/heptapod/-/issues/245GitLab 12.32020-04-26T18:20:51ZGeorges RacinetGitLab 12.3Either we finalize before %"Heptapod 0.13.0" release by merging with 12.3.9, or we move along to 12.4 (heptapod#246)Either we finalize before %"Heptapod 0.13.0" release by merging with 12.3.9, or we move along to 12.4 (heptapod#246)Heptapod 0.13.0https://foss.heptapod.net/heptapod/heptapod/-/issues/243Cloning with a deploy token over HTTP doesn't work2020-05-27T17:34:02ZGeorges RacinetCloning with a deploy token over HTTP doesn't workAccording to the documentation, deploy tokens have been introduced in GitLab 10.7. In terms of Heptapod versions, the feature is new in 0.12.0
Unfortunately, all attempts to clone a Mercurial repository with them end up in 404. As an in...According to the documentation, deploy tokens have been introduced in GitLab 10.7. In terms of Heptapod versions, the feature is new in 0.12.0
Unfortunately, all attempts to clone a Mercurial repository with them end up in 404. As an indication that the authentication part does work, we get a 403 if we make a mistake in the token value.Heptapod 0.13.0https://foss.heptapod.net/heptapod/heptapod/-/issues/201webhooks: check tag push hook and full integrations2020-05-29T10:36:11ZGeorges Racinetwebhooks: check tag push hook and full integrationsThese are two uncompleted task of #196, that didn't make it to 0.8.3These are two uncompleted task of #196, that didn't make it to 0.8.3Heptapod 0.13.0https://foss.heptapod.net/heptapod/heptapod/-/issues/199list mercurial/evolve/topic version somewhere2020-05-21T17:34:29ZPierre-Yves Davidlist mercurial/evolve/topic version somewhereThis would be useful to list the version of mercurial and extensions somewhere. /help would be a good spot, but adding it to the version string might be a bit too much.This would be useful to list the version of mercurial and extensions somewhere. /help would be a good spot, but adding it to the version string might be a bit too much.Heptapod 0.13.0https://foss.heptapod.net/heptapod/heptapod/-/issues/173Support wikis2020-05-15T12:35:05ZGiliSupport wikisWhen I try to `hg push` an existing wiki to a repository, I get HTTP 403 error. Apparently this functionality is not implemented yet...?When I try to `hg push` an existing wiki to a repository, I get HTTP 403 error. Apparently this functionality is not implemented yet...?Heptapod 0.13.0https://foss.heptapod.net/heptapod/heptapod/-/issues/107Enable editing/contribution of files though the web interface2020-05-29T10:23:55ZArthur LutzEnable editing/contribution of files though the web interfaceQuite early on in heptapod, the edit through the interface was disabled.
Since we've discussed this chosen limitation with some colleagues for a use case, I'm adding an issue to track what would be required for this to be re enabled.Quite early on in heptapod, the edit through the interface was disabled.
Since we've discussed this chosen limitation with some colleagues for a use case, I'm adding an issue to track what would be required for this to be re enabled.Heptapod 0.13.0https://foss.heptapod.net/heptapod/heptapod/-/issues/260Pushing tag no longer trigger build2020-05-20T09:16:03ZSteevePushing tag no longer trigger buildPreviously on `0.8.x` pushing a tag was triggering a CI build with `CI_COMMIT_TAG` environment variable.
Since `0.12.1` (did not test `0.12.0`) it no longer works.Previously on `0.8.x` pushing a tag was triggering a CI build with `CI_COMMIT_TAG` environment variable.
Since `0.12.1` (did not test `0.12.0`) it no longer works.Heptapod 0.12.4https://foss.heptapod.net/heptapod/heptapod/-/issues/126Prevent the GitLab default branch to be a topic2020-05-28T16:27:57ZGeorges RacinetPrevent the GitLab default branch to be a topicIt seems that the GitLab default branch is initialized as one of the branches of first received Git push. If that happens to be a topic, this leads to various problems down the line, unless of course someone manually changes it to the se...It seems that the GitLab default branch is initialized as one of the branches of first received Git push. If that happens to be a topic, this leads to various problems down the line, unless of course someone manually changes it to the sensible choice: a named branch.
Especially with our current inner push in three steps (topics, then named branches, then pruning of topic GitLab branches), this has led me to rewrite some tests to avoid pushing with a topic right away.
It would be much better if we changed this so that topic GitLab branches are replaced by the GitLab branch of their Mercurial branch, if possible, i.e, unless we have topics only. In the latter case, I think that unfortunately, we'll still have to choose a topic for the GitLab default branch. If that happens, subsequent pushes should have the option to overwrite the default branch setting.
One more caveat: I don't think the sanity checks in our inner push that avoid attemps to prune the default GitLab branch would resist a change of default GitLab branch between the three steps.Heptapod 0.12.4