heptapod issueshttps://foss.heptapod.net/heptapod/heptapod/-/issues2024-03-21T13:27:26Zhttps://foss.heptapod.net/heptapod/heptapod/-/issues/764VCS type alignment on home panel2024-03-21T13:27:26ZGeorges RacinetVCS type alignment on home panelWith the move to upstream GitLab v15.9, the short VCS type in project home page is now in exponent position.
![home-panel-v15.9](/uploads/c6bba4a6c1060f863041978ecc06fe2d/home-panel-v15.9.png)
This should just be a matter of using the ...With the move to upstream GitLab v15.9, the short VCS type in project home page is now in exponent position.
![home-panel-v15.9](/uploads/c6bba4a6c1060f863041978ecc06fe2d/home-panel-v15.9.png)
This should just be a matter of using the appropriate CSS class in app/views/projects/_home_panel.html.hamlHeptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/763Document RHGitaly source installation2023-07-06T10:34:33ZGeorges RacinetDocument RHGitaly source installationGenerally speaking, our [install from source](INSTALL_HEPTAPOD.md) doc is probably in need of a serious overhaulGenerally speaking, our [install from source](INSTALL_HEPTAPOD.md) doc is probably in need of a serious overhaulhttps://foss.heptapod.net/heptapod/heptapod/-/issues/762Freeze requests python dependency2023-07-04T14:07:04ZGeorges RacinetFreeze requests python dependencyWhile upgrading to 0.36.3, we got new versions of the `urllib3` and `requests` libraries, and they were incompatible.
Freeze to the latest compatible set of versions in the release branchWhile upgrading to 0.36.3, we got new versions of the `urllib3` and `requests` libraries, and they were incompatible.
Freeze to the latest compatible set of versions in the release branchhttps://foss.heptapod.net/heptapod/heptapod/-/issues/760Implement change of storage for Mercurial projects2024-03-21T13:42:51ZGeorges RacinetImplement change of storage for Mercurial projectsHeptapod still supports having only one Mercurial-enabled repository storage (i.e Gitaly and HGitaly services). However, it will be in the not-so-far future.
At this point, `Projects::UpdateRepositoryStorageService` will have to support...Heptapod still supports having only one Mercurial-enabled repository storage (i.e Gitaly and HGitaly services). However, it will be in the not-so-far future.
At this point, `Projects::UpdateRepositoryStorageService` will have to support Mercurial projects, its point being to move repositories from one storage to the other. The already are some provisions toward that, but it's obviously incomplete (see in particular how `Concerns::updateRepositoryStorageMethods` handles the Project repository).Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/759Document how to enable Largefile extension2023-07-25T06:45:09ZnekopepDocument how to enable Largefile extension### Summary
We are migrating form rhodecode to heptapod and we are stuck with repos using largefile extension.
- We have tried to disable extension while migrating but as it change changeset sha1 into the repos it is not possible for re...### Summary
We are migrating form rhodecode to heptapod and we are stuck with repos using largefile extension.
- We have tried to disable extension while migrating but as it change changeset sha1 into the repos it is not possible for repos used as subrepos.
I've seen that heptapod seems to support lfs (see bug #118: https://foss.heptapod.net/heptapod/heptapod/-/issues/118)
-> lib/gitlab/hg_access.rb looks correclty modified on heptapod 0.35 (the one I use)
It looks like I need to modify `config/mercurial/repos.hgrc` but I can't find this file on my instance.
Can you update the doc to explain how to migrate largefile extension enabled repos to help switching to heptapod?
I can also help with the doc provided you explain what is missing :smile:https://foss.heptapod.net/heptapod/heptapod/-/issues/758Capability to upgrade a GitLab instance to Heptapod2024-03-21T13:42:50ZGeorges RacinetCapability to upgrade a GitLab instance to HeptapodIt should be possible to upgrade a GitLab CE instance to Heptapod, and it certainly has been possible for many Heptapod versions in the past.
However, some of our data migrations were breaking rules that once were soft and have since be...It should be possible to upgrade a GitLab CE instance to Heptapod, and it certainly has been possible for many Heptapod versions in the past.
However, some of our data migrations were breaking rules that once were soft and have since become mandatory. It was reasonable because many of these rules are geared towards high volumetry (as can be found on gitlab.com) which was not a concern to us at the time yet have become enforced upstream.
The typical case would be `AddHgAsDefaultVcs` as it was until the merge of GitLab 15.8: it changes the schema (default value on `application_settings`) and updates a column on the `namespaces` table: it wouldn't have passed upstream review at the time, but there is a strict enforcement nowadays that migrations have to use either Data Definition Language (DDL) or Data Manipulation Language (DML). It makes the migration fail if running anew on recent Heptapod versions (which won't happen unless upgrading from an upstream GitLab instance because it dates way back). Also it breaks all the RSpec test that contain *any* migration test.
The problem in RSpec tests will of course be solved with the [merge of GitLab 15.8](!491), yet in a minimal way that is not suitable to upgrade an upstream GitLab CE instance.
This issue to keep track of the work need for such upgrades to be supported:
- [ ] `application_settings.vcs_types` should be introduced by a single migration, with the correct default set in the schema (single row table)
- [ ] `namespaces.default_vcs_type` does not need a migration of the value if starting afresh on current Heptapod versions. A `NULL` value means to default to Application Settings, so we don't need any backfill.
- [ ] actual testing of an upgrade from GitLab (how to automate that?)Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/757Not possible to close protected branch2023-06-10T07:42:29ZCédric Kriercedric.krier@b2ck.comNot possible to close protected branchIt is not possible to closed a protected branch:
> No push is allowed to delete protected branches on Mercurial project. If that was your intent, you will have to unprotect it first
This is a little bit annoying because you have to unp...It is not possible to closed a protected branch:
> No push is allowed to delete protected branches on Mercurial project. If that was your intent, you will have to unprotect it first
This is a little bit annoying because you have to unprotect it so any one with mercurial publish right will be allowed to push during the time we unprotect the branch.
It is worse if using wildcard pattern to protect many branches at once like `branch/*`.https://foss.heptapod.net/heptapod/heptapod/-/issues/756Topic branches are marked as merged2023-06-05T13:09:28ZCédric Kriercedric.krier@b2ck.comTopic branches are marked as mergedWhen having a large project with many contributors creating topics, looking at the stale branches to find abandoned topics can be useful to make some cleaning. But all topics are labelled as `merged`.
Instead of this label, it will be b...When having a large project with many contributors creating topics, looking at the stale branches to find abandoned topics can be useful to make some cleaning. But all topics are labelled as `merged`.
Instead of this label, it will be better to have a link to the merge request if there are one.https://foss.heptapod.net/heptapod/heptapod/-/issues/755Can not find merge request linked to a topic2023-06-03T06:25:40ZCédric Kriercedric.krier@b2ck.comCan not find merge request linked to a topicOn large project we may have quite a lot of topics opened by contributors. But it is difficult to find the related merge request in heptapod.
I think we need a keyword to search by topic name.On large project we may have quite a lot of topics opened by contributors. But it is difficult to find the related merge request in heptapod.
I think we need a keyword to search by topic name.https://foss.heptapod.net/heptapod/heptapod/-/issues/751Hashed storage migration: robustness if wiki repo is missing2023-05-26T12:24:22ZGeorges RacinetHashed storage migration: robustness if wiki repo is missingA fix for an old version that will help migrate to the newer ones!
As seen in #742, in Heptapod 0.23, if a Project lacks its wiki repository, then the hashed storage migration fails. It should not.
I don't have on mind whether the wiki...A fix for an old version that will help migrate to the newer ones!
As seen in #742, in Heptapod 0.23, if a Project lacks its wiki repository, then the hashed storage migration fails. It should not.
I don't have on mind whether the wiki repo should exist if the feature is disabled in the Project settings, this has to be checked. If not, that is also an easy recommendation to administrators of the affected instance: just disable it on the offending Projects.Georges RacinetGeorges Racinethttps://foss.heptapod.net/heptapod/heptapod/-/issues/750Robustness if hgrc is missing2023-05-26T12:20:17ZGeorges RacinetRobustness if hgrc is missingNowadays, it'd be a major inconsistency for `.hg/hgrc` not to exist in a server-side Mercurial repository on Heptapod.
However, as was highlighted by #742, it can happen in long-standing instances of our early adopters, and we should ma...Nowadays, it'd be a major inconsistency for `.hg/hgrc` not to exist in a server-side Mercurial repository on Heptapod.
However, as was highlighted by #742, it can happen in long-standing instances of our early adopters, and we should make at least `mv_repository` more robust about that, as it can block the hashed storage migration.
Task list:
- [ ] make `mv_repository` create the `hgrc` file with default content if missing (perhaps with inheritance set to `False` in order not to change any behavioural aspect)
- [ ] chase down parts in the code base where the existence of the main `hgrc` is simply assumed (methods to change configuration, notably)
- [ ] backport to Heptapod 0.23Georges RacinetGeorges Racinethttps://foss.heptapod.net/heptapod/heptapod/-/issues/747Topics of closed merge request are still visible in local clone2024-02-10T10:07:37ZCédric Kriercedric.krier@b2ck.comTopics of closed merge request are still visible in local cloneWhen a merge request has been closed from heptapod UI, after pulling a local repository (which had the topic), the topic is still there.\
I would expect that the topic would be cleaned like when a merge request is merged.When a merge request has been closed from heptapod UI, after pulling a local repository (which had the topic), the topic is still there.\
I would expect that the topic would be cleaned like when a merge request is merged.https://foss.heptapod.net/heptapod/heptapod/-/issues/741about.heptapod.host needs „sign in“ button2023-04-13T07:34:18ZHartmut Goebelabout.heptapod.host needs „sign in“ buttonabout.heptapod.host is lacking a „sign in” button. Thus if one for any reason ended on about.haptapos.host, is not easy to sign in.
Please add some „sign in” button.
Gitlab: ![Sign in button at about.gitlab.com](/uploads/362c5f437dd8e20...about.heptapod.host is lacking a „sign in” button. Thus if one for any reason ended on about.haptapos.host, is not easy to sign in.
Please add some „sign in” button.
Gitlab: ![Sign in button at about.gitlab.com](/uploads/362c5f437dd8e20e229944d3c24c023a/grafik.png)
Github: ![Sign in button at github.com](/uploads/cee8db2d53381c4060aa7b2bb1c108cb/grafik.png)https://foss.heptapod.net/heptapod/heptapod/-/issues/738Ignore topic branches in commit info2023-04-08T14:20:29ZCédric Kriercedric.krier@b2ck.comIgnore topic branches in commit infoWhen looking at a commit, in the branch info box the branches, in which the commit is, are displayed. But there is also all the topics. This information is not very useful as almost all commits from the default branch are in all topics.\...When looking at a commit, in the branch info box the branches, in which the commit is, are displayed. But there is also all the topics. This information is not very useful as almost all commits from the default branch are in all topics.\
I think we should filter out all the "GitLab branches" that starts with `topic/`.https://foss.heptapod.net/heptapod/heptapod/-/issues/736Squashing a single commit can be selected, but fails (without clear reason)2023-04-05T13:53:17ZMathias De MareSquashing a single commit can be selected, but fails (without clear reason)### Summary
Squashing a single commit can be selected, but it fails.
### Steps to reproduce
Try to squash a merge request with only 1 changeset.
### Example Project
https://foss.heptapod.net/heptapod/testing-projects/mercurial-paris...### Summary
Squashing a single commit can be selected, but it fails.
### Steps to reproduce
Try to squash a merge request with only 1 changeset.
### Example Project
https://foss.heptapod.net/heptapod/testing-projects/mercurial-paris-workshop/proj2/-/merge_requests/2
### What is the current *bug* behavior?
The squash fails.
### What is the expected *correct* behavior?
The squash should do nothing.
### Relevant logs and/or screenshots
Mercurial returns return code 1 in this specific case (which is not handled separately by Heptapod?).
#### Details about the Heptapod instance where the bug occurs
foss.heptapod.net
### Possible fixes
Adapt to accept return code 1 for this case.https://foss.heptapod.net/heptapod/heptapod/-/issues/726Pipeline not triggered when pushing from remote but triggered when commiting ...2023-02-08T14:12:19ZFranck BretPipeline not triggered when pushing from remote but triggered when commiting from web IDE<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Regression" or "Bug" label:
- https://foss.heptapod.net/heptapod/heptapod/issues?label_name%5B%5D=Regression
- https://...<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Regression" or "Bug" label:
- https://foss.heptapod.net/heptapod/heptapod/issues?label_name%5B%5D=Regression
- https://foss.heptapod.net/heptapod/heptapod/issues?label_name%5B%5D=Bug
and verify the issue you're about to submit isn't a duplicate.
--->
### Summary
There is a behaviour inconsistency between client and Web IDE on git based projects.
The pipeline start after commiting from web IDE, but don't on classic push from client.
### Steps to reproduce
<!-- Describe how one can reproduce the issue - this is very important. Please use an ordered list. -->
* create a new Git repository from template (I tried with the pelican one)
* Pull, edit content and commit, push
* verify if a new pipeline is triggered
* Edit a file from the Web IDE
* verify if a new pipeline is triggered
### Example Project
<!-- If possible, please create an example project here on foss.heptapod.net or over at heptapod.host that exhibits the problematic
behavior, and link to it here in the bug report. If you are using an older version of Heptapod, this
will also determine whether the bug is fixed in a more recent version. -->
https://foss.heptapod.net/heptapod/testing-projects/trypelican
### What is the current *bug* behavior?
CI pipeline not triggered on push
### What is the expected *correct* behavior?
CI pipeline triggered on pushhttps://foss.heptapod.net/heptapod/heptapod/-/issues/725Add simple tool for 'gitlab-hg' for on server repository maintenance.2023-02-06T22:51:31ZJoshua PedrickAdd simple tool for 'gitlab-hg' for on server repository maintenance.Occasionally, I need to do repository maintenance(e.g. repo mirrors get out of sync and commits need to be stripped). On the [FAQ](https://heptapod.net/pages/faq.html), there's warning about using the wrong mercurial version/configuratio...Occasionally, I need to do repository maintenance(e.g. repo mirrors get out of sync and commits need to be stripped). On the [FAQ](https://heptapod.net/pages/faq.html), there's warning about using the wrong mercurial version/configuration.
I propose a small simplification that parses the `config/gitlab.yml` for the correct configuration, like the following:
```
#!/opt/gitlab/embedded/bin/python3
import yaml
import subprocess
import os
import sys
gitlab_yml = yaml.safe_load( open('/opt/gitlab/embedded/service/gitlab-rails/config/gitlab.yml', 'r') )
production = gitlab_yml.get('production')
hgrc = production.get('mercurial').get('hgrc')
hg_bin = production.get('mercurial').get('bin_path')
os.environ['HGRCPATH'] = ':'.join(hgrc)
subprocess.run([ hg_bin ] + sys.argv[1:])
```
If this is installed in the /opt/gitlab/embedded/bin directory the paths could be relative to the location of the script itself.https://foss.heptapod.net/heptapod/heptapod/-/issues/724Webhooks sent ' branch/default' as branch name2023-09-05T12:37:26ZCédric Kriercedric.krier@b2ck.comWebhooks sent ' branch/default' as branch nameTrying to use the gitlab webhook for weblate: https://docs.weblate.org/en/latest/admin/continuous.html#automatically-receiving-changes-from-gitlab
It does not work because the name of the branch sent is `branch/default` instead of `defa...Trying to use the gitlab webhook for weblate: https://docs.weblate.org/en/latest/admin/continuous.html#automatically-receiving-changes-from-gitlab
It does not work because the name of the branch sent is `branch/default` instead of `default`. So weblate does not find a matching branch then it ignore the webhook (instead of pulling the repository).
It will be great if Heptapod could sent the mercurial name of the branch.https://foss.heptapod.net/heptapod/heptapod/-/issues/7232 pipelines for 1 merge request2023-01-12T10:15:50ZCédric Kriercedric.krier@b2ck.com2 pipelines for 1 merge requestWithout `workflow`, Heptapod triggers 2 pipelines, 1 that does not seem to detect the changed files and another with the merge request content as modified files.
Here is an example: https://foss.heptapod.net/tryton/tryton/-/merge_reques...Without `workflow`, Heptapod triggers 2 pipelines, 1 that does not seem to detect the changed files and another with the merge request content as modified files.
Here is an example: https://foss.heptapod.net/tryton/tryton/-/merge_requests/152/pipelines
I cancelled the first one because it runs all the jobs which is resource consuming.
I tried to remove the workflow as it does not trigger a pipeline when:
* push directly to the protected branches
* when publish changeset from command line
The problem is that it is not clear how to use the CI variables in the Heptapod context because the documentation is based on Git design with fork.
But basically we could expect from a usage without `workflow`, Heptapod will trigger only 1 pipeline for a merge request and only another pipeline when the merge request is published.
It seems that `workflow` like this:
```
workflow:
- if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
when: never
- if: $CI_COMMIT_BRANCH =~ /^branch\/.*/
```
does not work when pushing directly or make changeset public from command line.https://foss.heptapod.net/heptapod/heptapod/-/issues/721Topic-branches of closed merge-requests are marked as “merged”2023-01-08T15:00:52ZHartmut GoebelTopic-branches of closed merge-requests are marked as “merged”When a merge-request gets closed, the respective topic-branch will be marked as “merged”.
Example:
- merge request which has been closed: https://foss.heptapod.net/tryton/tryton/-/merge_requests/63
![Info of this merge-request](/upl...When a merge-request gets closed, the respective topic-branch will be marked as “merged”.
Example:
- merge request which has been closed: https://foss.heptapod.net/tryton/tryton/-/merge_requests/63
![Info of this merge-request](/uploads/5d8f4f5c3539247247c174ac2463cde4/grafik.png)
- corresponding topic-branch: https://foss.heptapod.net/tryton/tryton/-/branches?state=all&sort=updated_desc&search=doc
![topic-branch in branch list](/uploads/41e1700be2f7749d7ac4848f9fd6a9b1/grafik.png)
Expected results:
Topic-branches of closed merge-requests are _not_ marked as “merged”, but as eg. “closed”.