heptapod issueshttps://foss.heptapod.net/heptapod/heptapod/-/issues2022-12-13T18:09:41Zhttps://foss.heptapod.net/heptapod/heptapod/-/issues/716Mercurial specific CI variables2022-12-13T18:09:41ZGeorges RacinetMercurial specific CI variablesThey are apparently missing from the builtin "predefined variables" doc.They are apparently missing from the builtin "predefined variables" doc.https://foss.heptapod.net/heptapod/heptapod/-/issues/714Default branch value overridden by topic2024-03-21T13:27:26ZGeorges RacinetDefault branch value overridden by topicIt happened today here on mercurial/mercurial-devel>: `topic/stable/uninstall-issue6762` became the default branch.
From the logs, it's not clear why, except that it was made through HGitaly:
```
[2022-11-28 12:15:00,917] [501] [DEBUG]...It happened today here on mercurial/mercurial-devel>: `topic/stable/uninstall-issue6762` became the default branch.
From the logs, it's not clear why, except that it was made through HGitaly:
```
[2022-11-28 12:15:00,917] [501] [DEBUG] [hgitaly.interceptors] Starting to process RPC CountCommitsRequest { repository { storage_name: "default" relative_path: "@hashed/78/5f/785f3ec7eb32f30b90cd0fcf3657d388b5ff4297f2f9716ff66e9b69c05ddd09.git" gl_repository: "project-22" gl_project_path: "mercurial/mercurial-devel" } revision: "topic/stable/uninstall-issue-6762" }
[2022-11-28 12:15:03,045] [501] [DEBUG] [hgitaly.interceptors] Starting to process RPC FindAllBranchNamesRequest { repository { storage_name: "default" relative_path: "@hashed/78/5f/785f3ec7eb32f30b90cd0fcf3657d388b5ff4297f2f9716ff66e9b69c05ddd09.git" gl_repository: "project-22" gl_project_path: "mercurial/mercurial-devel" } }
[2022-11-28 12:15:03,245] [501] [DEBUG] [hgitaly.interceptors] Starting to process RPC WriteRefRequest { repository { storage_name: "default" relative_path: "@hashed/78/5f/785f3ec7eb32f30b90cd0fcf3657d388b5ff4297f2f9716ff66e9b69c05ddd09.git" gl_repository: "project-22" gl_project_path: "mercurial/mercurial-devel" } ref: "HEAD" revision: "refs/heads/topic/stable/uninstall-issue-6762" }
```
The above extract is all requests for the project, from the first involving the topic up to the one setting default branch, it case it helps understanding the sequence.
We should at least add logs in the Mercurial-specific code in `PostReceiveWorker` that is supposed to set the default branch if needed.Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/713Tag created in a not merged topic2022-12-15T13:13:17ZPierre AugierTag created in a not merged topicSome times ago, I created a test tag "tag_test" in a topic that I didn't merge.
https://foss.heptapod.net/fluiddyn/fluidsim/-/commit/e5c27a9f2a19f371eac14674da70200ff2fac969/
The tag does not appear in https://foss.heptapod.net/fluiddy...Some times ago, I created a test tag "tag_test" in a topic that I didn't merge.
https://foss.heptapod.net/fluiddyn/fluidsim/-/commit/e5c27a9f2a19f371eac14674da70200ff2fac969/
The tag does not appear in https://foss.heptapod.net/fluiddyn/fluidsim/-/tags (good).
However, some pipelines are sometimes triggered related to this tags: https://foss.heptapod.net/fluiddyn/fluidsim/-/pipelines
There is a pipeline associated with the commit that created the tag
https://foss.heptapod.net/fluiddyn/fluidsim/-/pipelines/58808
and another pipeline associated with the commit pointed by the tag
https://foss.heptapod.net/fluiddyn/fluidsim/-/pipelines/58807
There is a link towards the page of this tag https://foss.heptapod.net/fluiddyn/fluidsim/-/commits/tag_test in the pipelines page, but this link gives a Page Not Found error (which is normal since the tag does not exist anymore in the hg repo).https://foss.heptapod.net/heptapod/heptapod/-/issues/708Tags unavailable2022-11-19T21:54:43ZCédric Kriercedric.krier@b2ck.comTags unavailableOn our mono-repository we have more than 8000 tags, so GitLab can not show the tags for a commit due to https://gitlab.com/gitlab-org/gitlab/-/issues/20733
But as tags are different from branches in mercurial, we may have a higher limit ...On our mono-repository we have more than 8000 tags, so GitLab can not show the tags for a commit due to https://gitlab.com/gitlab-org/gitlab/-/issues/20733
But as tags are different from branches in mercurial, we may have a higher limit than 1000?https://foss.heptapod.net/heptapod/heptapod/-/issues/706Forking a Git repository if personal quota is 02024-03-21T13:42:50ZGeorges RacinetForking a Git repository if personal quota is 0On foss.heptapod.net and heptapod.host, most users don't have the rights to create projects in their personal namespaces. In the former, that is because we want to control what people upload on a very public instance. In the latter, beca...On foss.heptapod.net and heptapod.host, most users don't have the rights to create projects in their personal namespaces. In the former, that is because we want to control what people upload on a very public instance. In the latter, because invoicing is tied to top-level (actual) groups.
But the Git fork page still proposes the personal namespace to host the fork. Similarly to what has already been done with creation / import pages, we must exclude it, and perhaps even add a message urging users to make personal subgroups of their top-level / company groups.Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/705Runner does not find obsolet changeset2024-03-22T08:58:00ZCédric Kriercedric.krier@b2ck.comRunner does not find obsolet changeset<!---
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
When pipeline as started but the changeset has been amended, jobs that has not yet pull the repository fails.
### Steps to reproduce
Make a changeset that trigger a pipeline
Amend and push this changeset before the jobs of the pipeline are finished
### Example Project
https://foss.heptapod.net/tryton/tryton-mono-test/-/pipelines/58435/failures
### What is the current *bug* behavior?
The jobs fails due to external condition.
### What is the expected *correct* behavior?
I would expect that the jobs pull the obsolete changeset and keep running.Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/703Migration to native, failed Notes on Heptapod Rails2024-03-21T13:27:26ZGeorges RacinetMigration to native, failed Notes on Heptapod RailsThe migration of this very project to native Mercurial produced a couple of errors in Notes:
```
there are errors for {:notes=>[143179, 142308, 142256, 142301, 142303, 142305, 142310]}. Please check application log for details
```
The ...The migration of this very project to native Mercurial produced a couple of errors in Notes:
```
there are errors for {:notes=>[143179, 142308, 142256, 142301, 142303, 142305, 142310]}. Please check application log for details
```
The error logs are the same for all these 7 Notes:
```json
{
"severity": "ERROR",
"time": "2022-10-01T11:44:09.615Z",
"correlation_id": null,
"message": "Failed to migrate Note id=143179",
"backtrace": [
"lib/gitlab/timeless.rb:11:in `timeless'",
"lib/heptapod/native_mercurial/migrator.rb:40:in `timeless_save'",
"lib/heptapod/native_mercurial/migrator.rb:253:in `save_note_if_changed'",
"lib/heptapod/native_mercurial/migrator.rb:262:in `block in migrate_notes'",
"lib/heptapod/native_mercurial/migrator.rb:259:in `migrate_notes'",
"lib/heptapod/native_mercurial/migrator.rb:189:in `do_migrate'",
"lib/heptapod/native_mercurial/migrator.rb:135:in `block in migrate!'",
"lib/heptapod/native_mercurial/migrator.rb:124:in `block (4 levels) in enter'",
"lib/heptapod/native_mercurial/migrator.rb:107:in `with_record'",
"lib/heptapod/native_mercurial/migrator.rb:123:in `block (3 levels) in enter'",
"lib/heptapod/native_mercurial/migrator.rb:50:in `vcs_type_enforcer'",
"lib/heptapod/native_mercurial/migrator.rb:122:in `block (2 levels) in enter'",
"lib/heptapod/native_mercurial/migrator.rb:61:in `with_project_readonly'",
"lib/heptapod/native_mercurial/migrator.rb:121:in `block in enter'",
"lib/heptapod/native_mercurial/migrator.rb:87:in `try_obtain_exclusive_lease'",
"lib/heptapod/native_mercurial/migrator.rb:120:in `enter'",
"lib/heptapod/native_mercurial/migrator.rb:133:in `migrate!'",
"lib/tasks/migrate/migrate_to_native_hg.rake:37:in `block (3 levels) in <top (required)>'"
],
"project_id": 5,
"project_full_path": "heptapod/heptapod"
}
```
Given this backtrace, it's possible that a simple retry would fix them (will attempt that later)Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/702(Legacy Mercurial) problem reopening old branches2024-03-21T13:42:50ZGeorges Racinet(Legacy Mercurial) problem reopening old branchesIn case a named branch has been closed long ago, it is possible that GitLab holds no references to what its head was before the closing changeset. In that case, pushing a new child of the former head can fail during the conversion to the...In case a named branch has been closed long ago, it is possible that GitLab holds no references to what its head was before the closing changeset. In that case, pushing a new child of the former head can fail during the conversion to the internal Git repository with a bad Git object message.
This happened to me with the `heptapod-0-23` branch of this very project: the former head was da810f85b7e1 and had exactly one child, the closing changeset f89d0daa76b0. The fact that da810f85b7e1 is a tagging changeset does not imply that it has itself a GitLab reference).
The root cause is likely that the Git commit converted from this former head has been garbage collected. A solution could be to add closing changesets (and tagging changesets) to the "keep around" special references, but it's dubious that it would be worth the effort, and that wouldn't restore the missing Git commits (they would need to be reexported, which is a bit painful).
At this point in the development of Heptapod, the simplest solution is to migrate the project to native Mercurial, which I just did for heptapod/heptapod>. Afterwards, I was able to push the reopening (with the `--force` modifier because of the client-side protection against multiple heads). This confirms that native projects are not affected.
The migration to native is still deemed to be experimental, though. Hopefully, it will become more mainstream soon.Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/701Comment is shown with a date in the future2022-09-27T16:14:39Zphp4fanComment is shown with a date in the future
### Summary
I posted a comment to an issue report on a project on Heptapod (namely mercurial/tortoisehg), and right after publishing my comment, it was displayed like this:
![image](/uploads/8b7799fcd28f3610f5c72f7ee665669d/image.png)...
### Summary
I posted a comment to an issue report on a project on Heptapod (namely mercurial/tortoisehg), and right after publishing my comment, it was displayed like this:
![image](/uploads/8b7799fcd28f3610f5c72f7ee665669d/image.png)
Note the date is "in 14 seconds", that is, in the future
### Steps to reproduce
I don't know if you can reproduce, as my guess is it depends on the date on your computer, i.e. on the client side (that is my guess because I can't imagine in what other way you can get such an error).
Anyway what I did to reproduce the issue was:
- comment on an issue
- look at the comment you just posted
### What is the current *bug* behavior?
The date of the comment is shown as being in the future
### What is the expected *correct* behavior?
Right after posting the comment, the date should be displayed as "just now". After a while, it should be some date and time in the past (whether it's expressed as an absolute date and time, or in terms of "XXX ago"), NEVER under any circumstances can it be in the future. I don't expect it to be 100% accurate, but I do expect not to see an impossible value.
I can imagine a couple of ways this could happen, both if the time in my computer's clock (or your server's, or both) is slightly off:
A) When you receive and store the comment, you store the date as submitted by the client, so if the client's clock is off, the date of the comment is stored wrong
B) much more likely: when displaying the date, on the client side, you compare the date of the comment as it comes from the database (which was determined by the server) with the current date from the client's clock.
Either way it's wrong. You can't ever compare two dates that come from different clocks and assume they are correctly synchronized. If you have no other option than doing that (but that's not the case), then a small error is acceptable; but saying that something happened in the future is not.
You shouldn't assume that the time on the user's computer is _even remotely_ correct. But if you do decide, for the sake of simplicity, to assume that the clock on the user's computer is _reasonably_ correct, then you have to take into account the possibility of a reasonable error, say a few seconds or minutes. That basically boils down to clamping the "time ago" value to >= zero.
If it's none of those and you are only using server-side times, as you should, then I have no idea how you can be ending up with a negative time-ago value.https://foss.heptapod.net/heptapod/heptapod/-/issues/691Review logos and branding2024-03-21T13:42:50ZGeorges RacinetReview logos and brandingIn upstream GitLab 15.0, there is a change of logos and the way they are used in various pages, emails. There is notably a possibility to add variable text in some of the logos.
The resulting conflicting merge will necessarily need furt...In upstream GitLab 15.0, there is a change of logos and the way they are used in various pages, emails. There is notably a possibility to add variable text in some of the logos.
The resulting conflicting merge will necessarily need further fixes, assessment will better be done in a production-style installation, hence when we make some pre-0.33 Docker images.Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/690Consider upstream GitLab registry statistics2024-03-21T13:42:51ZGeorges RacinetConsider upstream GitLab registry statisticsIn version 15.0, a new projects (and root namespaces?) statistics field `container_registry_size` appears, hence duplicating our own `container_registry_size_share`.
We should consider whether it is appropriate to simply drop ours. Thi...In version 15.0, a new projects (and root namespaces?) statistics field `container_registry_size` appears, hence duplicating our own `container_registry_size_share`.
We should consider whether it is appropriate to simply drop ours. This isn't a trivial question, as the deduplicating of layers might be vastly different.Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/687no-git: problems with default GitLab branch2022-11-28T17:01:09ZGeorges Racinetno-git: problems with default GitLab branchSee today on mercurial/mercurial-devel>:
```
remote: File "/home/hg/venv/lib/python3.9/site-packages/hgext3rd/heptapod/__init__.py", line 162, in gitlab_mirror
remote: no_git.NoGitStateMaintainer(ui, repo).sync()
remote: File "/...See today on mercurial/mercurial-devel>:
```
remote: File "/home/hg/venv/lib/python3.9/site-packages/hgext3rd/heptapod/__init__.py", line 162, in gitlab_mirror
remote: no_git.NoGitStateMaintainer(ui, repo).sync()
remote: File "/home/hg/venv/lib/python3.9/site-packages/hgext3rd/heptapod/no_git.py", line 86, in sync
remote: self.update_gitlab_references()
remote: File "/home/hg/venv/lib/python3.9/site-packages/hgext3rd/heptapod/state_maintainer.py", line 1060, in update_gitlab_references
remote: self.heptapod_apply_changes(prune_reasons, changes)
remote: File "/home/hg/venv/lib/python3.9/site-packages/hgext3rd/heptapod/state_maintainer.py", line 1071, in heptapod_apply_changes
remote: self.update_default_gitlab_branch(changes)
remote: File "/home/hg/venv/lib/python3.9/site-packages/hgext3rd/heptapod/state_maintainer.py", line 1132, in update_default_gitlab_branch
remote: self.set_default_gitlab_ref(new_default_ref)
remote: File "/home/hg/venv/lib/python3.9/site-packages/hgext3rd/heptapod/no_git.py", line 99, in set_default_gitlab_ref
remote: b"Setting GitLab branch to %s" % new_gl_branch)
remote: TypeError: %b requires a bytes-like object, or an object that implements __bytes__, not 'NoneType'
```
The root of the problem is that the stored default GitLab branch is wrong:
```
$ cat .hg/default_gitlab_branch; echo
topic/default/rhg.errors
```
and that should never have happened, but it should nevertheless get updated correctly in that case.
To complicate things further, the Rails app sees the correct default branch (`branch/default').https://foss.heptapod.net/heptapod/heptapod/-/issues/686Empty archive downloads2023-09-05T10:50:29ZGeorges RacinetEmpty archive downloads<!---
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
It happens that the download links for some Mercurial projects can provide empty archives
### Steps to reproduce
1. Go to a repo, e.g. hg repo https://heptapod.host/intevation/py3o.formats
2. Press the download selection button (to the right of the branch selection)
3. Select any format and save the file.
### Example Project
This public project on heptapod.hosts exhibits the problem : https://heptapod.host/intevation/py3o.formats
As the feature is tested within Heptapod functional tests, it is almost sure not to be systematic.
### What is the current *bug* behavior?
Downloaded archive is empty
### What is the expected *correct* behavior?
An non-empty archive, the same as produced with `hg archive` on a local clone.Georges RacinetGeorges Racinethttps://foss.heptapod.net/heptapod/heptapod/-/issues/681Branch removal by obsmarkers2024-03-21T13:27:25ZGeorges RacinetBranch removal by obsmarkersIn case a whole named branch is removed by changeset obsolescence, the corresponding GitLab branch is not removed.
As a result, the branch is lingering in the interface, and the Gitlab state file within the Mercurial repository has an en...In case a whole named branch is removed by changeset obsolescence, the corresponding GitLab branch is not removed.
As a result, the branch is lingering in the interface, and the Gitlab state file within the Mercurial repository has an entry for an obsolete changeset, which should not happen.
An example occured on this very project:
- I started the Heptapod 0.24 release branch as `heptapod-0.24` (that's a typo)
- Later on, I realised the error and rebased the changeset, with the new, correct `heptapod-0-24` branch name.
Expected behaviour: the GitLab branch should have been removed, same as if the branch was closed with `hg commit --close-branch`
This has bad consequences, see hgitaly#102Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/680Show last user to touch commit per obslog2022-06-10T05:10:15ZKim AlvefurShow last user to touch commit per obslogWhen a commit has been edited by someone other than the commit author using evolve, it could be helpful to display this somewhere prominently in order to improve clarity. E.g. during review it might be useful to know who to contact, or p...When a commit has been edited by someone other than the commit author using evolve, it could be helpful to display this somewhere prominently in order to improve clarity. E.g. during review it might be useful to know who to contact, or provide an explanation in a "wait I didn't write this" scenario.
gracinet on IRC suggested filing an issuehttps://foss.heptapod.net/heptapod/heptapod/-/issues/678Using the rebase button fails to update the current page, needs reloading2023-01-16T10:37:04ZRaphaël GomèsUsing the rebase button fails to update the current page, needs reloading### Summary
Using the "rebase" button on a MR, the loading button appears, but then the page comes back the same "rebase" button, you need to reload the page to see the "Merge when pipeline succeeds" button.
### Steps to reproduce
Reb...### Summary
Using the "rebase" button on a MR, the loading button appears, but then the page comes back the same "rebase" button, you need to reload the page to see the "Merge when pipeline succeeds" button.
### Steps to reproduce
Rebase a MR that needs rebasing, observe the button not changing to the intended state after the loading state.
### What is the expected *correct* behavior?
The AJAX request should put the MR page in the state we get after a full page reload.
#### Details about the Heptapod instance where the bug occurs
Heptapod 0.31.1 (GitLab CE 14.9.5)
Mercurial 6.1.3 / Python 3.9.13 / hg-evolve 10.5.1https://foss.heptapod.net/heptapod/heptapod/-/issues/677Useless hunks dividers in diff view between contiguous hunks2022-12-26T12:43:16ZRaphaël GomèsUseless hunks dividers in diff view between contiguous hunks### Summary
When viewing a diff, contiguous hunks are not merged in the UI, resulting in confusing (and useless) "Show 20 lines" etc. buttons between them.
### Steps to reproduce
Go to any diff with contiguous hunks like https://foss....### Summary
When viewing a diff, contiguous hunks are not merged in the UI, resulting in confusing (and useless) "Show 20 lines" etc. buttons between them.
### Steps to reproduce
Go to any diff with contiguous hunks like https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/138/diffs?commit_id=0dc5d69c179bd8ed63314210619afb3e3ac098fd and observe.
### What is the current *bug* behavior?
The "show X lines..." divider is shown between contiguous hunks
### What is the expected *correct* behavior?
Contiguous hunks should be detected and the divider should only be present when useful (including after using it to expand between two non-contiguous hunks that then become contiguous).
Seen on foss.heptapod.net (but very likely still broken in Heptapod dev itself).
Heptapod 0.31.1 (GitLab CE 14.9.5)
Mercurial 6.1.3 / Python 3.9.13 / hg-evolve 10.5.1https://foss.heptapod.net/heptapod/heptapod/-/issues/674Compare changes on "changed this line in version x of the diff" not completing2022-06-07T12:11:12ZGeorges RacinetCompare changes on "changed this line in version x of the diff" not completingIt happens for example under [this change suggestion](https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/110#note_185298): the expected diff never gets displayed, the placeholder stays forever
The corresponding async r...It happens for example under [this change suggestion](https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/110#note_185298): the expected diff never gets displayed, the placeholder stays forever
The corresponding async request is made on the `note/:id/outdated_line_change` path, e.g, `https://foss.heptapod.net/mercurial/mercurial-devel/notes/185356/outdated_line_change` and results immediately in an empty 200 response.
No log line in `exceptions_json.log`.https://foss.heptapod.net/heptapod/heptapod/-/issues/672Timeout error while rendering a commit diff2024-03-21T13:27:24ZGeorges RacinetTimeout error while rendering a commit diffSeveral occurrences on this instance of errors while highlightneing MR commit diffs:
```
Exception:
class: Timeout::Error
message: execution expired
backtrace:
lib/rouge/formatters/html_gitlab.rb:26:in `block (2 levels) in s...Several occurrences on this instance of errors while highlightneing MR commit diffs:
```
Exception:
class: Timeout::Error
message: execution expired
backtrace:
lib/rouge/formatters/html_gitlab.rb:26:in `block (2 levels) in stream'
lib/rouge/formatters/html_gitlab.rb:25:in `each'
lib/rouge/formatters/html_gitlab.rb:25:in `block in stream'
lib/rouge/formatters/html_gitlab.rb:19:in `stream'
lib/gitlab/highlight.rb:75:in `block in highlight_rich'
lib/gitlab/highlight.rb:75:in `highlight_rich'
lib/gitlab/highlight.rb:64:in `highlight_text'
lib/gitlab/highlight.rb:31:in `highlight'
lib/gitlab/highlight.rb:10:in `highlight'
app/presenters/blob_presenter.rb:15:in `highlight'
lib/gitlab/diff/highlight.rb:156:in `highlighted_blob_lines'
lib/gitlab/diff/highlight.rb:148:in `new_lines'
lib/gitlab/diff/highlight.rb:124:in `blob_highlighting'
lib/gitlab/diff/highlight.rb:89:in `highlight_line'
lib/gitlab/diff/highlight.rb:60:in `apply_syntax_highlight'
lib/gitlab/diff/highlight.rb:34:in `block in highlight'
lib/gitlab/diff/highlight.rb:29:in `map'
lib/gitlab/diff/highlight.rb:29:in `with_index'
lib/gitlab/diff/highlight.rb:29:in `highlight'
lib/gitlab/diff/file.rb:238:in `highlighted_diff_lines'
lib/gitlab/diff/parallel_diff.rb:17:in `parallelize'
lib/gitlab/diff/file.rb:243:in `parallel_diff_lines'
app/views/projects/diffs/_parallel_view.html.haml:5
app/views/projects/diffs/viewers/_text.html.haml:6
app/views/projects/diffs/_viewer.html.haml:14
app/views/projects/diffs/_content.html.haml:11
app/views/projects/diffs/_file.html.haml:42
app/views/projects/diffs/_diffs.html.haml:39
app/views/projects/commit/show.html.haml:15
```
I thought for a while it was due to memory pressure created by HGitaly, but it also happened while its footprint was small.Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/671API: POST /projects with import_url results in: "is not a valid HTTP Git repo...2022-06-12T09:01:05Zmarc-guentherAPI: POST /projects with import_url results in: "is not a valid HTTP Git repository"I try to use the Rest API to create a new project (`POST /projects`) and have it automatically import from an existing Mercurial repository by specifying `import_url`.
This works just fine in the UI, but fails in the API with:
`{"messag...I try to use the Rest API to create a new project (`POST /projects`) and have it automatically import from an existing Mercurial repository by specifying `import_url`.
This works just fine in the UI, but fails in the API with:
`{"message":"http://.... is not a valid HTTP Git repository"}`
From a quick glance at the source code, in `lib/api/projects.rb` there is a call to `validate_git_import_url()`, which seems to check for a Git repository and doesn't know about Mercurial.
Example `curl` call:
```
curl -s --header 'PRIVATE-TOKEN: API_TOKEN' --header 'Content-Type: application/json' --data '{"path":"my-repository","import_url":"http://user:password@hg.local/my_repository"}' http://gitlab.local/api/v4/projects
```