heptapod issueshttps://foss.heptapod.net/heptapod/heptapod/-/issues2021-07-21T13:55:29Zhttps://foss.heptapod.net/heptapod/heptapod/-/issues/518Error on MediaWiki page2021-07-21T13:55:29ZGeorges RacinetError on MediaWiki pageSaw this while watching the logs on foss.heptapod.net:
```
lib/gitlab/other_markup.rb:11:in `render'
app/helpers/markup_helper.rb:281:in `other_markup_unsafe'
app/helpers/markup_helper.rb:146:in `markup_unsafe'
app/helpers/markup_helper...Saw this while watching the logs on foss.heptapod.net:
```
lib/gitlab/other_markup.rb:11:in `render'
app/helpers/markup_helper.rb:281:in `other_markup_unsafe'
app/helpers/markup_helper.rb:146:in `markup_unsafe'
app/helpers/markup_helper.rb:131:in `render_wiki_content'
app/views/shared/wikis/show.html.haml:30
```
Extra log fields:
```
'extra.file_name': 'FAQ.wiki',
'extra.project_id': 314,
```
The wiki for project 314:
```
hg clone https://foss.heptapod.net/mercurial/tortoisehg/thg-hgtk.wiki
```
Although other files in the Wiki look to be MediaWiki, it's not clear they are understood as such (extension would be `.mediakiwi` instead of `.wiki`)https://foss.heptapod.net/heptapod/heptapod/-/issues/509Switch post-receive API calls to JSON for Mercurial projects2024-03-21T13:42:51ZGeorges RacinetSwitch post-receive API calls to JSON for Mercurial projectsBecause GitLab's internal API relies on request parsing provided by Grape and/or Rack, the `post_receive` internal API endpoint accepts both `multipart/form-data` and `application/json`. For Mercurial repositories, we've always used the ...Because GitLab's internal API relies on request parsing provided by Grape and/or Rack, the `post_receive` internal API endpoint accepts both `multipart/form-data` and `application/json`. For Mercurial repositories, we've always used the former, but GitLab components that send post-receives actually use the latter.
This is problematic for nested structures, such as lists (e.g. `push_options`) where only the last element is actually visible after parsing. In the case of `hg_prunes`, we've settled for JSON serialization of the *value* from the onset, which didn't create more divergence with upstream, since it's specific.
It would be much better to switch to JSON for the whole payload. This requires careful treatment of the `bytes` vs `str` pain on the Python side.Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/504Bump config-express to a version compatible with pushvars2021-06-19T09:35:53ZGeorges RacinetBump config-express to a version compatible with pushvarsOnce mercurial/config-express#19 is solved and a new version is released, we need to require it in Heptapod.Once mercurial/config-express#19 is solved and a new version is released, we need to require it in Heptapod.https://foss.heptapod.net/heptapod/heptapod/-/issues/499Native migration: Issues and Merge Requests2021-06-17T18:39:41ZSushil KhanchiNative migration: Issues and Merge RequestsReplace Git shas with Hg shas for following columns of issues and MRs:
1) description
2) title
3) and their _html derivatives
Subtask of #420Replace Git shas with Hg shas for following columns of issues and MRs:
1) description
2) title
3) and their _html derivatives
Subtask of #420https://foss.heptapod.net/heptapod/heptapod/-/issues/483Probe a repository URL2021-05-18T14:54:25ZSushil KhanchiProbe a repository URLProbing a URL to find the `vcs_type` of a repository would be nice to have and would probably be a help for #406.
After discussing with @gracinet `hg debugpeer` seems a good choice to do this.Probing a URL to find the `vcs_type` of a repository would be nice to have and would probably be a help for #406.
After discussing with @gracinet `hg debugpeer` seems a good choice to do this.https://foss.heptapod.net/heptapod/heptapod/-/issues/481Accessing closed branches is difficult with Heptapod2021-05-12T08:56:47ZMichael McNeil ForbesAccessing closed branches is difficult with Heptapod### Summary
Closed branches are not easily accessible from Heptapod since the related issue #93 was resolved. In particular:
1. It appears not to be possible to download closed branches. For example, the following fail since branch 0...### Summary
Closed branches are not easily accessible from Heptapod since the related issue #93 was resolved. In particular:
1. It appears not to be possible to download closed branches. For example, the following fail since branch 0.9 was closed by [commit 93981e1c](https://hg.iscimath.org/forbes-group/persist/-/commit/93981e1cfccf8278de9498c199046f090abeed87)
* https://hg.iscimath.org/forbes-group/persist/-/tree/branch/0.9
* https://hg.iscimath.org/forbes-group/persist/-/archive/branch/0.9/persist-branch-0.9.tar.bz2
This works for branches that have not been closed:
* https://hg.iscimath.org/forbes-group/persist/-/tree/branch/2.0
* https://hg.iscimath.org/forbes-group/persist/-/archive/branch/2.0/persist-branch-2.0.tar.bz2
The difficulty this causes for us is that these tarballs were available on Bitbucket, and we were relying on this to provide version-specific access through a URL and the pip `--find-links` option. Now this fails.
2. These branches are invisible in the Heptapod UI. This is probably fine, but it would be useful if they could be explicitly referenced i.e. with https://hg.iscimath.org/forbes-group/persist/-/tree/branch/0.9.
3. Mirroring does not push these branch tags to git, so, although the commits exist in the mirrored git repo (e.g. [github commit 93981e1c](https://github.com/forbes-group/persist/commit/93981e1cfccf8278de9498c199046f090abeed87)), there is no way to refer to them from the cloned git repo like there is from the cloned mercurial repo. `hg update --closed 0.9` for example.
4. I don't see an easy workaround to re-open these branches so that our previous `--find-links` usage will work with Heptapod.
Our previous workflow is obviously not in tune with the current Heptapod workflow: we should probably have just left the branches open as dangling heads. Still, it seems like it could be useful if thinks like the direct tarball downloads could work and maybe if the branch names could somehow be pushed to git. (Is there an equivalent to `--closed` for git branches? Sorry: don't know that much about git internally.)
Any suggestions for how to easily repair these repos would be appreciated.https://foss.heptapod.net/heptapod/heptapod/-/issues/478API error when trying to get branches information for hg native repos2021-04-29T08:47:13ZArthur LutzAPI error when trying to get branches information for hg native reposWe started using https://github.com/mvisonneau/gitlab-ci-pipelines-exporter to monitor our pipeline and jobs in heptapod. It's not fully working yet, but it's pretty promising. While testing it, we found some issues and hope to report th...We started using https://github.com/mvisonneau/gitlab-ci-pipelines-exporter to monitor our pipeline and jobs in heptapod. It's not fully working yet, but it's pretty promising. While testing it, we found some issues and hope to report them to the project so that future users can easily set it up with heptapod.
One of them is related to hg native repos. They seem to serve a 500 error when the software queries for branches :
```
{"error":"GET https://forge.extranet.logilab.fr/api/v4/projects/open-source/gitlab-ci-templates/repository/branches: 500 {message: 500 Internal Server Error}","level":"warning","msg":"pulling refs from project","project-name":"open-source/gitlab-ci-templates","time":"2021-04-29T06:23:25Z"}
```
If you check https://forge.extranet.logilab.fr/open-source/gitlab-ci-templates it shows it's a `hg (native)` repo.
I can dig further in the logs if needed.
If you want to use the project, you have to customize which refs it looks for (since there is no `main` or `master` :
```
[snip]
project_defaults:
pull:
refs:
regexp: "^main|master|default$"
```
(might try to get that into the default value...)https://foss.heptapod.net/heptapod/heptapod/-/issues/465Native projects and GitLab branches and tags escaping2024-03-21T13:27:24ZGeorges RacinetNative projects and GitLab branches and tags escapingThe escaping we currently have for GitLab branches and tags will be a source of trouble with the transitional state of native projects:
- if we stop doing it, we can't convert to Git any more, which is obviously the ultimate end goal bu...The escaping we currently have for GitLab branches and tags will be a source of trouble with the transitional state of native projects:
- if we stop doing it, we can't convert to Git any more, which is obviously the ultimate end goal but wrecks all the intermediate steps we want to go through to reach it.
- if we keep on doing it, we will be creating unresolvable references. Actually, we already are with current (HGitaly1) native projects.
Solutions to this will need to take #451 into account, either as a further complication (e.g, we can't just change the escaping to make it bijective) or as a way to accept the imperfection. See #464 for the kind of consequences that can arise if it's slightly wrong.Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/457Remaining New project link for users that can't create one2021-09-21T08:46:29ZGeorges RacinetRemaining New project link for users that can't create one
### Summary
There are some remaining "New Project" links being displayed to users that don't have any project creation rights.
The creation process then fails as it should with "invalid namespace".
We previously removed most of these ...
### Summary
There are some remaining "New Project" links being displayed to users that don't have any project creation rights.
The creation process then fails as it should with "invalid namespace".
We previously removed most of these links, see #256 and #361 for background.
### Steps to reproduce
1. Create an "external user"
2. Impersonate the user
3. Go to the user profile (should be `/username` URI)
Behold, there's a new project green link as attached.
### What is the current *bug* behavior?
A "New project" link get displayed where arguably it should not, the creation process then fails with an obscure error.
### What is the expected *correct* behavior?
Even if there is a link to the "New project" page displayed to users that don't have creation rights, it should not lead to an obscure error.
#### Details about the Heptapod instance where the bug occurs
Happens on foss.h.n, probably generic.Georges RacinetGeorges Racinethttps://foss.heptapod.net/heptapod/heptapod/-/issues/454Server-side amends for MR link2024-03-21T13:42:50ZGeorges RacinetServer-side amends for MR linkIn the Git world, one of the advantages of explicit merge commits upon MR acceptance is to play the role of the cover letter that some email-based workflow use: namely, a summary of what the entire series of changesets does.
I've been r...In the Git world, one of the advantages of explicit merge commits upon MR acceptance is to play the role of the cover letter that some email-based workflow use: namely, a summary of what the entire series of changesets does.
I've been reluctant to use the semi-linear merge method because it is heavy handed for MRs that consist of exactly one commit. But the MR can have interesting discussions. In some cases, most of the motivation behind the changes is actually in the MR description and comments.
So here's an idea: for MR with a single changeset and semi-linear method, the server could amend the unique changeset to add the MR link. Maybe we could do that as well in other cases (squash come to mind, but it's already almost there, with the message of the resulting commit being under user control).Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/453500 Error - possibly related to wild heads.2021-05-13T09:39:20ZMichael McNeil Forbes500 Error - possibly related to wild heads.### Summary
When attempting to view commits, branches, or files for the following repo, we get a 500 error:
* https://hg.iscimath.org/mforbes/forbes_group_website/-/commits/branch/default
* https://hg.iscimath.org/mforbes/forbes_group_...### Summary
When attempting to view commits, branches, or files for the following repo, we get a 500 error:
* https://hg.iscimath.org/mforbes/forbes_group_website/-/commits/branch/default
* https://hg.iscimath.org/mforbes/forbes_group_website/-/branches
Cloning also fails.
### Details
This is a self-hosted version of Heptapod running as a Docker image on AWS and the repo was imported from Bitbucket (hence, a little hard to reproduce since Bitbucket has stopped hosting!)
I suspect that the issue is due to the presence of wild heads that were in the original repo, but do not know how to delve deeper to see if this is actually the issue underneath, nor how to clone, close the wild heads, and fix the underlying repo.
### Example Project
* https://hg.iscimath.org/mforbes/forbes_group_website/
### What is the current *bug* behavior?
The following return 500 errors (with any branch)
* https://hg.iscimath.org/mforbes/forbes_group_website/-/commits/branch/default (Any branch)
* https://hg.iscimath.org/mforbes/forbes_group_website/-/branches
* https://hg.iscimath.org/mforbes/forbes_group_website/-/blob/branch/default/README.md (Any file)
Cloning fails:
```bash
$ hg clone ssh://git@hg.iscimath.org:11022/mforbes/forbes_group_website
abort: no suitable response from remote hg!
$ hg clone https://hg.iscimath.org/mforbes/forbes_group_website
abort: HTTP Error 404: Not Found
```
### What is the expected *correct* behavior?
Able to access the files, for example, as with other projects on the server:
* https://hg.iscimath.org/mforbes/super_hydro/-/commits/branch/default
* https://hg.iscimath.org/mforbes/super_hydro/-/branches
* https://hg.iscimath.org/mforbes/super_hydro/-/blob/branch/default/README.md
Able to clone:
```bash
$ hg clone ssh://git@hg.iscimath.org:11022/mforbes/super_hydro
destination directory: super_hydro
requesting all changes
adding changesets
adding manifests
adding file changes
added 213 changesets with 881 changes to 228 files
34 new obsolescence markers
new changesets e11e307ed831:cc8237504acc
updating to branch default
65 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg clone https://hg.iscimath.org/mforbes/super_hydrodestination directory: super_hydro
requesting all changes
adding changesets
adding manifests
adding file changes
added 213 changesets with 881 changes to 228 files
34 new obsolescence markers
new changesets e11e307ed831:cc8237504acc
updating to branch default
65 files updated, 0 files merged, 0 files removed, 0 files unresolved
```
### Relevant logs and/or screenshots
Logs reported with `docker exec -it ${heptapod_id} gitlab-ctl tail` on the AWS host while attempting to load https://hg.iscimath.org/mforbes/forbes_group_website/-/commits/branch/default:
<p>
<details>
<summary>Detailed Log Reports.</summary>
```bash
==> /var/log/gitlab/gitlab-rails/production.log <==
Started GET "/mforbes/forbes_group_website/-/commits/branch/default" for 134.121.19.154 at 2021-03-24 22:01:44 +0000
Processing by Projects::CommitsController#show as HTML
Parameters: {"namespace_id"=>"mforbes", "project_id"=>"forbes_group_website", "id"=>"branch/default"}
==> /var/log/gitlab/gitaly/current <==
{"correlation_id":"01F1K4400Y16G9M0J1XE8S30VC","grpc.code":"OK","grpc.meta.auth_version":"v2","grpc.meta.client_name":"gitlab-web","grpc.meta.deadline_type":"regular","grpc.method":"FindAllTagNames","grpc.request.deadline":"2021-03-24T22:01:54.005Z","grpc.request.fullMethod":"/gitaly.RefService/FindAllTagNames","grpc.request.glProjectPath":"mforbes/forbes_group_website","grpc.request.glRepository":"project-56","grpc.request.repoPath":"@hashed/76/88/7688b6ef52555962d008fff894223582c484517cea7da49ee67800adc7fc8866.git","grpc.request.repoStorage":"default","grpc.request.topLevelGroup":"@hashed","grpc.service":"gitaly.RefService","grpc.start_time":"2021-03-24T22:01:44.835Z","grpc.time_ms":59.494,"level":"info","msg":"finished streaming call with code OK","peer.address":"@","pid":2096,"remote_ip":"134.121.19.154","span.kind":"server","system":"grpc","time":"2021-03-24T22:01:44.895Z","username":"mforbes"}
{"correlation_id":"01F1K4400Y16G9M0J1XE8S30VC","grpc.code":"OK","grpc.meta.auth_version":"v2","grpc.meta.client_name":"gitlab-web","grpc.meta.deadline_type":"regular","grpc.method":"FindCommit","grpc.request.deadline":"2021-03-24T22:02:14.097Z","grpc.request.fullMethod":"/gitaly.CommitService/FindCommit","grpc.request.glProjectPath":"mforbes/forbes_group_website","grpc.request.glRepository":"project-56","grpc.request.repoPath":"@hashed/76/88/7688b6ef52555962d008fff894223582c484517cea7da49ee67800adc7fc8866.git","grpc.request.repoStorage":"default","grpc.request.topLevelGroup":"@hashed","grpc.service":"gitaly.CommitService","grpc.start_time":"2021-03-24T22:01:44.897Z","grpc.time_ms":69.954,"level":"info","msg":"finished unary call with code OK","peer.address":"@","pid":2096,"remote_ip":"134.121.19.154","span.kind":"server","system":"grpc","time":"2021-03-24T22:01:44.967Z","username":"mforbes"}
{"correlation_id":"01F1K4400Y16G9M0J1XE8S30VC","grpc.code":"OK","grpc.meta.auth_version":"v2","grpc.meta.client_name":"gitlab-web","grpc.meta.deadline_type":"regular","grpc.method":"FindCommits","grpc.request.deadline":"2021-03-24T22:02:14.078Z","grpc.request.fullMethod":"/gitaly.CommitService/FindCommits","grpc.request.glProjectPath":"mforbes/forbes_group_website","grpc.request.glRepository":"project-56","grpc.request.repoPath":"@hashed/76/88/7688b6ef52555962d008fff894223582c484517cea7da49ee67800adc7fc8866.git","grpc.request.repoStorage":"default","grpc.request.topLevelGroup":"@hashed","grpc.service":"gitaly.CommitService","grpc.start_time":"2021-03-24T22:01:44.978Z","grpc.time_ms":45.31,"level":"info","msg":"finished streaming call with code OK","peer.address":"@","pid":2096,"remote_ip":"134.121.19.154","span.kind":"server","system":"grpc","time":"2021-03-24T22:01:45.023Z","username":"mforbes"}
{"correlation_id":"01F1K4400Y16G9M0J1XE8S30VC","grpc.code":"OK","grpc.meta.auth_version":"v2","grpc.meta.client_name":"gitlab-web","grpc.meta.deadline_type":"regular","grpc.method":"RepositoryExists","grpc.request.deadline":"2021-03-24T22:01:55.008Z","grpc.request.fullMethod":"/gitaly.RepositoryService/RepositoryExists","grpc.request.glProjectPath":"mforbes/forbes_group_website","grpc.request.glRepository":"project-56","grpc.request.repoPath":"@hashed/76/88/7688b6ef52555962d008fff894223582c484517cea7da49ee67800adc7fc8866.git","grpc.request.repoStorage":"default","grpc.request.topLevelGroup":"@hashed","grpc.service":"gitaly.RepositoryService","grpc.start_time":"2021-03-24T22:01:45.299Z","grpc.time_ms":0.129,"level":"info","msg":"finished unary call with code OK","peer.address":"@","pid":2096,"remote_ip":"134.121.19.154","span.kind":"server","system":"grpc","time":"2021-03-24T22:01:45.299Z","username":"mforbes"}
==> /var/log/gitlab/gitlab-rails/production.log <==
Completed 500 Internal Server Error in 503ms (ActiveRecord: 15.7ms | Elasticsearch: 0.0ms | Allocations: 130236)
==> /var/log/gitlab/gitlab-rails/production_json.log <==
{"method":"GET","path":"/mforbes/forbes_group_website/-/commits/branch/default","format":"html","controller":"Projects::CommitsController","action":"show","status":500,"time":"2021-03-24T22:01:45.303Z","params":[{"key":"namespace_id","value":"mforbes"},{"key":"project_id","value":"forbes_group_website"},{"key":"id","value":"branch/default"}],"remote_ip":"134.121.19.154","user_id":2,"username":"mforbes","ua":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.2 Safari/605.1.15","correlation_id":"01F1K4400Y16G9M0J1XE8S30VC","meta.user":"mforbes","meta.project":"mforbes/forbes_group_website","meta.root_namespace":"mforbes","meta.caller_id":"Projects::CommitsController#show","meta.remote_ip":"134.121.19.154","meta.feature_category":"source_code_management","gitaly_calls":4,"gitaly_duration_s":0.186025,"redis_calls":58,"redis_duration_s":0.027582,"redis_read_bytes":5723,"redis_write_bytes":7193,"redis_cache_calls":57,"redis_cache_duration_s":0.027215,"redis_cache_read_bytes":5540,"redis_cache_write_bytes":6322,"redis_shared_state_calls":1,"redis_shared_state_duration_s":0.000367,"redis_shared_state_read_bytes":183,"redis_shared_state_write_bytes":871,"db_count":14,"db_write_count":0,"db_cached_count":1,"cpu_s":0.279139,"queue_duration_s":0.043445,"exception.class":"ActionView::Template::Error","exception.message":"undefined method `[]' for nil:NilClass","exception.backtrace":["app/models/commit.rb:80:in `truncate_sha'","app/models/commit.rb:208:in `hpd_short_display_id'","app/views/projects/commits/_commit.html.haml:20","app/views/projects/commits/_commits.html.haml:17","app/models/commit_collection.rb:23:in `<<'","app/models/commit_collection.rb:23:in `each'","app/models/commit_collection.rb:23:in `each'","app/views/projects/commits/_commits.html.haml:10:in `each'","app/views/projects/commits/_commits.html.haml:10:in `each'","app/views/projects/commits/_commits.html.haml:10","app/views/projects/commits/show.html.haml:36","app/controllers/application_controller.rb:125:in `render'","app/controllers/application_controller.rb:555:in `block in allow_gitaly_ref_name_caching'","lib/gitlab/gitaly_client.rb:375:in `allow_ref_name_caching'","app/controllers/application_controller.rb:554:in `allow_gitaly_ref_name_caching'","app/controllers/application_controller.rb:500:in `set_current_admin'","lib/gitlab/session.rb:11:in `with_session'","app/controllers/application_controller.rb:491:in `set_session_storage'","lib/gitlab/i18n.rb:73:in `with_locale'","lib/gitlab/i18n.rb:79:in `with_user_locale'","app/controllers/application_controller.rb:485:in `set_locale'","lib/gitlab/error_tracking.rb:52:in `with_context'","app/controllers/application_controller.rb:550:in `sentry_context'","app/controllers/application_controller.rb:478:in `block in set_current_context'","lib/gitlab/application_context.rb:56:in `block in use'","lib/gitlab/application_context.rb:56:in `use'","lib/gitlab/application_context.rb:22:in `with_context'","app/controllers/application_controller.rb:469:in `set_current_context'","lib/gitlab/metrics/elasticsearch_rack_middleware.rb:16:in `call'","lib/gitlab/middleware/rails_queue_duration.rb:33:in `call'","lib/gitlab/metrics/rack_middleware.rb:16:in `block in call'","lib/gitlab/metrics/transaction.rb:56:in `run'","lib/gitlab/metrics/rack_middleware.rb:16:in `call'","lib/gitlab/request_profiler/middleware.rb:17:in `call'","lib/gitlab/jira/middleware.rb:19:in `call'","lib/gitlab/middleware/go.rb:20:in `call'","lib/gitlab/etag_caching/middleware.rb:21:in `call'","lib/gitlab/middleware/multipart.rb:172:in `call'","lib/gitlab/middleware/read_only/controller.rb:50:in `call'","lib/gitlab/middleware/read_only.rb:18:in `call'","lib/gitlab/middleware/same_site_cookies.rb:27:in `call'","lib/gitlab/middleware/handle_malformed_strings.rb:21:in `call'","lib/gitlab/middleware/basic_health_check.rb:25:in `call'","lib/gitlab/middleware/handle_ip_spoof_attack_error.rb:25:in `call'","lib/gitlab/middleware/request_context.rb:21:in `call'","config/initializers/fix_local_cache_middleware.rb:11:in `call'","lib/gitlab/metrics/requests_rack_middleware.rb:76:in `call'","lib/gitlab/middleware/release_env.rb:12:in `call'"],"db_duration_s":0.01574,"view_duration_s":0.0,"duration_s":0.50345}
==> /var/log/gitlab/gitlab-rails/production.log <==
!n
ActionView::Template::Error (undefined method `[]' for nil:NilClass):
17:
18: - show_project_name = local_assigns.fetch(:show_project_name, false)
19:
20: %li{ class: ["commit flex-row", ("js-toggle-container" if collapsible)], id: "commit-#{commit.hpd_short_display_id}" }
21:
22: .avatar-cell.d-none.d-sm-block
23: = author_avatar(commit, size: 40, has_tooltip: false)
app/models/commit.rb:80:in `truncate_sha'
app/models/commit.rb:208:in `hpd_short_display_id'
app/views/projects/commits/_commit.html.haml:20
app/views/projects/commits/_commits.html.haml:17
app/models/commit_collection.rb:23:in `<<'
app/models/commit_collection.rb:23:in `each'
app/models/commit_collection.rb:23:in `each'
app/views/projects/commits/_commits.html.haml:10:in `each'
app/views/projects/commits/_commits.html.haml:10:in `each'
app/views/projects/commits/_commits.html.haml:10
app/views/projects/commits/show.html.haml:36
app/controllers/application_controller.rb:125:in `render'
app/controllers/application_controller.rb:555:in `block in allow_gitaly_ref_name_caching'
lib/gitlab/gitaly_client.rb:375:in `allow_ref_name_caching'
app/controllers/application_controller.rb:554:in `allow_gitaly_ref_name_caching'
app/controllers/application_controller.rb:500:in `set_current_admin'
lib/gitlab/session.rb:11:in `with_session'
app/controllers/application_controller.rb:491:in `set_session_storage'
lib/gitlab/i18n.rb:73:in `with_locale'
lib/gitlab/i18n.rb:79:in `with_user_locale'
app/controllers/application_controller.rb:485:in `set_locale'
lib/gitlab/error_tracking.rb:52:in `with_context'
app/controllers/application_controller.rb:550:in `sentry_context'
app/controllers/application_controller.rb:478:in `block in set_current_context'
lib/gitlab/application_context.rb:56:in `block in use'
lib/gitlab/application_context.rb:56:in `use'
lib/gitlab/application_context.rb:22:in `with_context'
app/controllers/application_controller.rb:469:in `set_current_context'
lib/gitlab/metrics/elasticsearch_rack_middleware.rb:16:in `call'
lib/gitlab/middleware/rails_queue_duration.rb:33:in `call'
lib/gitlab/metrics/rack_middleware.rb:16:in `block in call'
lib/gitlab/metrics/transaction.rb:56:in `run'
lib/gitlab/metrics/rack_middleware.rb:16:in `call'
lib/gitlab/request_profiler/middleware.rb:17:in `call'
lib/gitlab/jira/middleware.rb:19:in `call'
lib/gitlab/middleware/go.rb:20:in `call'
lib/gitlab/etag_caching/middleware.rb:21:in `call'
lib/gitlab/middleware/multipart.rb:172:in `call'
lib/gitlab/middleware/read_only/controller.rb:50:in `call'
lib/gitlab/middleware/read_only.rb:18:in `call'
lib/gitlab/middleware/same_site_cookies.rb:27:in `call'
lib/gitlab/middleware/handle_malformed_strings.rb:21:in `call'
lib/gitlab/middleware/basic_health_check.rb:25:in `call'
lib/gitlab/middleware/handle_ip_spoof_attack_error.rb:25:in `call'
lib/gitlab/middleware/request_context.rb:21:in `call'
config/initializers/fix_local_cache_middleware.rb:11:in `call'
lib/gitlab/metrics/requests_rack_middleware.rb:76:in `call'
lib/gitlab/middleware/release_env.rb:12:in `call'
==> /var/log/gitlab/nginx/gitlab_access.log <==
134.121.19.154 - - [24/Mar/2021:22:01:45 +0000] "GET /mforbes/forbes_group_website/-/commits/branch/default HTTP/2.0" 500 12146 "https://hg.iscimath.org/mforbes/forbes_group_website/-/tree/branch/default" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.2 Safari/605.1.15" -
==> /var/log/gitlab/gitlab-workhorse/current <==
{"content_type":"text/html; charset=utf-8","correlation_id":"01F1K4400Y16G9M0J1XE8S30VC","duration_ms":575,"host":"hg.iscimath.org","level":"info","method":"GET","msg":"access","proto":"HTTP/1.1","referrer":"https://hg.iscimath.org/mforbes/forbes_group_website/-/tree/branch/default","remote_addr":"134.121.19.154:0","remote_ip":"134.121.19.154","route":"","status":500,"system":"http","time":"2021-03-24T22:01:45Z","ttfb_ms":575,"uri":"/mforbes/forbes_group_website/-/commits/branch/default","user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.2 Safari/605.1.15","written_bytes":12146}
==> /var/log/gitlab/gitaly/gitaly_ruby_json.log <==
{"type":"gitaly-ruby","grpc.start_time":"2021-03-24T22:01:45Z","grpc.time_ms":0.148,"grpc.code":"OK","grpc.method":"Check","grpc.service":"grpc.health.v1.Health","pid":9721,"correlation_id":"c4c935dace0fb5a5d5b7c9821428cc3e","time":"2021-03-24T22:01:45.368Z"}
{"type":"gitaly-ruby","grpc.start_time":"2021-03-24T22:01:45Z","grpc.time_ms":0.284,"grpc.code":"OK","grpc.method":"Check","grpc.service":"grpc.health.v1.Health","pid":23077,"correlation_id":"5ac3fe29fc48552e20a82c2ff11200ea","time":"2021-03-24T22:01:45.369Z"}
```
</details>
</p>
#### Details about the Heptapod instance where the bug occurs
* https://hg.iscimath.org/mforbes/forbes_group_website/
Omnibus docker image octobus/heptapod:0.20.0 running on an AWS instance:
```bash
Heptapod = 0.20.0
Mercuria= l5.6.1
hg-evolve = 10.2.0.post1
hg-git = 0.9.0 (dulwich 0.20.19)
GitLab = 13.9.1
Heptapod Shell = 13.16.0
Heptapod Workhorse = 0.20.0
GitLab API = v4
Python = 3.8.8
Ruby = 2.7.2p137
Rails = 6.0.3.4
PostgreSQL = 12.5
Redis = 6.0.10
```
The following configuration changes have been applied:
```ruby
#gitlab.rb
external_url "https://hg.iscimath.org"
gitlab_rails['gitlab_shell_ssh_port'] = 11022
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp..."
gitlab_rails['smtp_port'] = 25 #465
gitlab_rails['smtp_domain'] = "smtp..."
gitlab_rails['smtp_enable_starttls_auto'] = true
nginx['redirect_http_to_https'] = true
letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ["m...@..."] # This should be an array of email addresses to add as contacts
letsencrypt['auto_renew'] = true
letsencrypt['auto_renew_hour'] = 0
letsencrypt['auto_renew_minute'] = nil # Should be a number or cron expression, if specified.
letsencrypt['auto_renew_day_of_month'] = "*/4"
```
```python
#heptapod.hgrc
[heptapod]
allow-multiple-heads = yes
[logging]
# Does not seem to produce any output... I saw this in
# https://foss.heptapod.net/heptapod/heptapod/-/issues/76#note_927
# and thought it might help me figure out what is causing a problem.
file = /var/log/gitlab/hgserve/mercurial.log
```Georges RacinetGeorges Racinethttps://foss.heptapod.net/heptapod/heptapod/-/issues/450Removing a tag from the UI gives an error2024-03-21T13:27:23ZQuentin RaynaudRemoving a tag from the UI gives an error### Summary
As discussed in issue #432, I'm opening new issues for tag related misbehaviors I found.
Opening the tags list from `Repository/Tags`, then clicking on a tag, then clicking on the trash bin, then cliking on `Delete tag` is ...### Summary
As discussed in issue #432, I'm opening new issues for tag related misbehaviors I found.
Opening the tags list from `Repository/Tags`, then clicking on a tag, then clicking on the trash bin, then cliking on `Delete tag` is showing error `Gitlab::GitAccess::NotFoundError`.
### What is the expected *correct* behavior?
The tag should be deleted properly. Or the trash bin icon should not be available in the meantime.
#### Details about the Heptapod instance where the bug occurs
- Type of deployment (source, Docker, Omnibus, Heptapod Development Kit): Docker
- Exact Heptapod version: 0.20.2
I also add that the repo I use is pretty old so it is legacy and probably don’t use HGItaly except if you made something to convert those already. I think it's not the case so I feel it’s good to mention this.Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/443UX: add a mention of mercurial/hg to the clone info2022-06-24T09:38:56ZMatti PicusUX: add a mention of mercurial/hg to the clone infoI think it would be helpful if the text of the clone button would reflect the idea that you need to use mercurial to clone the repo. Currently the clone button/dropdown gives a URL with no guidance how to use it, and also has a menu item...I think it would be helpful if the text of the clone button would reflect the idea that you need to use mercurial to clone the repo. Currently the clone button/dropdown gives a URL with no guidance how to use it, and also has a menu item for "use in an IDE" which will probably not work out-of-the-box for most users.
xref pypy/cffi#496https://foss.heptapod.net/heptapod/heptapod/-/issues/437Provide something like Git attributes2024-03-21T13:42:51ZGeorges RacinetProvide something like Git attributesThe checked-in `.gitattributes` file allows to control some aspects of the repository.
In particular, it is [interpreted by github-linguist](https://github.com/github/linguist/blob/master/docs/overrides.md), the engine taking care of pr...The checked-in `.gitattributes` file allows to control some aspects of the repository.
In particular, it is [interpreted by github-linguist](https://github.com/github/linguist/blob/master/docs/overrides.md), the engine taking care of programming language analysis, to provide exclusion for vendored libraries and direct detection rules.
As a practical example, `.t` files used for cram and Mercurial tests are detected as Perl by github-linguist.
There is even a [dedicated github-linguist issue](https://github.com/github/linguist/issues/1569) on the subject.
Projects like [Octobus' mercurial-devel](https://foss.heptapod.net/Octobus/mercurial-devel) and [evolve](https://foss.heptapod.net/mercurial/evolve) could force them to something more appropriate right now. The price to pay would be that it's called `.gitattributes` and that it probably wouldn't be forward compatible with how native Mercurial repositories will work in the not-so-far future.
There are potentially other use cases for a shared, checked-in configuration file, but we obviously should not call it`.gitattributes`. Does something similar already exist in Mercurial land that we could piggy-back on ? Should we introduce a `.heptapod-attributes`?Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/435Reschedule MR cleanups for native Mercurial projects2024-03-21T13:42:49ZGeorges RacinetReschedule MR cleanups for native Mercurial projectsA consequence of #423 is that Merge Requests special refs didn't get cleaned up as they should have, at first by failing (loudly), then by being ignored (still the case as of Heptapod 0.20.0).
We need to reschedule them in a background ...A consequence of #423 is that Merge Requests special refs didn't get cleaned up as they should have, at first by failing (loudly), then by being ignored (still the case as of Heptapod 0.20.0).
We need to reschedule them in a background migration after native Mercurial projects get proper support for special refs (#431), which should include deletion. This can be done with the `MergeRequests::CleanupRefsService.schedule` classmethod.
Normally these cleanups happen in `MergeRequests::PostMergeService` and `MergeRequests::CloseService`, hence we can perform them for all `closed` and `merged` MRs. We can expect the volume to be much lower than what this scheduling is designed for, but we can as well use it, provided we don't get failures if it fails (MR closed post #431, hence whose special refs are already cleaned up) or we just accept the failures and subsequent retries because they are low volume.Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/429Outdated error message2021-02-22T17:29:25ZGeorges RacinetOutdated error messageThis error upon `hg push`:
```
remote: GitLab update error: 'You can only use an existing protected branch ref as the basis of a new protected branch.'. Because of this, some changes won't be visible in the web interface
remote: You can...This error upon `hg push`:
```
remote: GitLab update error: 'You can only use an existing protected branch ref as the basis of a new protected branch.'. Because of this, some changes won't be visible in the web interface
remote: You can only use an existing protected branch ref as the basis of a new protected branch.
abort: push failed on remote
```
Nowadays, we're firing the pre-receive ourselves, and that is before the Mercurial transaction commit, outlined by the `abort: push failed on remote`, so "Some changes won't be visible" is outdated, it would make sense only for the post-receive send, which happens, as expected, after Mercurial transaction is complete.https://foss.heptapod.net/heptapod/heptapod/-/issues/428Group Wikis2021-02-20T19:51:53ZGeorges RacinetGroup WikisCurrent GitLab Enterprise Editions have Group Wikis, for which the `container` attribute is a `Group` instance instead of a `Project`.
If these get open sourced or if we make an Enterprise Edition of Heptapod, they won't work because th...Current GitLab Enterprise Editions have Group Wikis, for which the `container` attribute is a `Group` instance instead of a `Project`.
If these get open sourced or if we make an Enterprise Edition of Heptapod, they won't work because the
`Group` model doesn't have the `vcs_type` and `mercurial?` methods.
At this point, we'll either decide to force them to return the values expected for Git (the lazy choice) or that we should rely on the recently introduced `default_vcs_type` group setting. After all, if the default VCS type for a Group is Mercurial, its Wiki should probably also be. We'll probably have to fix routes and internal API calls for GitLab Shell and pre/post-receive notifications and deal with persistence if `default_vcs_type` is changed after the fact.
(issue filed after analysis of current repo containers, in order not to lose the information)https://foss.heptapod.net/heptapod/heptapod/-/issues/427Fix Design Management repositories for Mercurial projects2024-03-21T13:27:25ZGeorges RacinetFix Design Management repositories for Mercurial projectsDesign Management features are using inner Git repositories with LFS for storage and versionning.
Acording to code comments, these repositories are supposed not to be "user-facing",
meaning most probably that they can't be pulled or pus...Design Management features are using inner Git repositories with LFS for storage and versionning.
Acording to code comments, these repositories are supposed not to be "user-facing",
meaning most probably that they can't be pulled or pushed to directly.
As with Snippets, it is probably wise just to let them be as expected by GitLab, i.e just Git repositories, but that's not what Heptapod currently does (to be confirmed):
Extract from `app/models/design_management/repository.rb`:
```ruby
module DesignManagement
class Repository < ::Repository
extend ::Gitlab::Utils::Override
# We define static git attributes for the design repository as this
# repository is entirely GitLab-managed rather than user-facing.
#
# Enable all uploaded files to be stored in LFS.
MANAGED_GIT_ATTRIBUTES = <<~GA.freeze
/#{DesignManagement.designs_directory}/* filter=lfs diff=lfs merge=lfs -text
GA
def initialize(project)
full_path = project.full_path + Gitlab::GlRepository::DESIGN.path_suffix
disk_path = project.disk_path + Gitlab::GlRepository::DESIGN.path_suffix
super(full_path, project, shard: project.repository_storage, disk_path: disk_path, repo_type: Gitlab::GlRepository::DESIGN)
end
```
So, the `container` (second argument in `super`) is the Project, which in case of Mercurial projects (native or not) will actually create Mercurial repositories. To fix that we'd need
- a special case in `Repository#initialize_raw_repository` or in `Gitlab::VCS.repository_class`
- to implement `vcs_type` (-> `git`) and `mercurial?` (-> `false`) directly on `DesignManagement::Repository` and check that we never call `repository.container.vcs_type` directly and same with `mercurial?`Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/419CI: RSpec tests for project controllers2021-02-08T15:31:49ZGeorges RacinetCI: RSpec tests for project controllersWe should add some of the project controllers tests at least to the `extended` scope, but some fixes seem to be in order:
```
$ bin/rspec spec/controllers/projects/
(...)
Failures:
1) Projects::GroupLinksController#update when `expir...We should add some of the project controllers tests at least to the `extended` scope, but some fixes seem to be in order:
```
$ bin/rspec spec/controllers/projects/
(...)
Failures:
1) Projects::GroupLinksController#update when `expires_at` is set returns correct json response
Failure/Error: expect(json_response).to eq({ "expires_in" => "about 1 month", "expires_soon" => false })
expected: {"expires_in"=>"about 1 month", "expires_soon"=>false}
got: {"expires_in"=>"28 days", "expires_soon"=>false}
(compared using ==)
Diff:
@@ -1,3 +1,3 @@
-"expires_in" => "about 1 month",
+"expires_in" => "28 days",
"expires_soon" => false,
# ./spec/controllers/projects/group_links_controller_spec.rb:176:in `block (4 levels) in <main>'
# ./spec/spec_helper.rb:357:in `block (3 levels) in <top (required)>'
# ./spec/support/sidekiq_middleware.rb:9:in `with_sidekiq_server_middleware'
# ./spec/spec_helper.rb:348:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:344:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:344:in `block (2 levels) in <top (required)>'
2) Projects::MergeRequestsController GET pipelines with private builds on a public project from a project fork with private builds for the target project member does not respond with serialized pipelines
Failure/Error: expect(json_response['pipelines']).to be_empty
expected `[{"active"=>true, "commit"=>{"author"=>nil, "author_email"=>"job@gitlab.com", "author_gravatar_url"=>...push", "triggered"=>[], "triggered_by"=>nil, "updated_at"=>"2021-02-08T15:15:50.560Z", "user"=>nil}].empty?` to return true, got false
# ./spec/controllers/projects/merge_requests_controller_spec.rb:792:in `block (7 levels) in <main>'
# ./spec/spec_helper.rb:357:in `block (3 levels) in <top (required)>'
# ./spec/support/sidekiq_middleware.rb:9:in `with_sidekiq_server_middleware'
# ./spec/spec_helper.rb:348:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:344:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:344:in `block (2 levels) in <top (required)>'
# ./spec/support/sidekiq.rb:17:in `block (3 levels) in <main>'
# ./spec/support/sidekiq.rb:8:in `gitlab_sidekiq_inline'
# ./spec/support/sidekiq.rb:17:in `block (2 levels) in <main>'
3) Projects::ProjectMembersController PUT update expiration date when `expires_at` is set returns correct json response
Failure/Error:
expect(json_response).to eq({
"expires_in" => "about 1 month",
"expires_soon" => false,
"expires_at_formatted" => expiry_date.to_time.in_time_zone.to_s(:medium)
})
expected: {"expires_at_formatted"=>"Mar 7, 2021 11:00pm", "expires_in"=>"about 1 month", "expires_soon"=>false}
got: {"expires_at_formatted"=>"Mar 7, 2021 11:00pm", "expires_in"=>"28 days", "expires_soon"=>false}
(compared using ==)
Diff:
@@ -1,4 +1,4 @@
"expires_at_formatted" => "Mar 7, 2021 11:00pm",
-"expires_in" => "about 1 month",
+"expires_in" => "28 days",
"expires_soon" => false,
# ./spec/controllers/projects/project_members_controller_spec.rb:252:in `block (5 levels) in <main>'
# ./spec/spec_helper.rb:357:in `block (3 levels) in <top (required)>'
# ./spec/support/sidekiq_middleware.rb:9:in `with_sidekiq_server_middleware'
# ./spec/spec_helper.rb:348:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:344:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:344:in `block (2 levels) in <top (required)>'
Finished in 17 minutes 51 seconds (files took 24.37 seconds to load)
2697 examples, 3 failures, 6 pending
```
The ones about 28 days are mere annoyances, the one about the unwanted pipeline needs more attention.https://foss.heptapod.net/heptapod/heptapod/-/issues/417Some build from source file location instructions unclear2021-04-01T11:48:06ZXiao YuSome build from source file location instructions unclearIn https://foss.heptapod.net/heptapod/heptapod/blob/branch/heptapod/INSTALL_HEPTAPOD.md
a few files and locations are referenced without any prior context or explanation.
Things like:
- `/path/to/.gitlab_shell_secret`
- `http+unix://%...In https://foss.heptapod.net/heptapod/heptapod/blob/branch/heptapod/INSTALL_HEPTAPOD.md
a few files and locations are referenced without any prior context or explanation.
Things like:
- `/path/to/.gitlab_shell_secret`
- `http+unix://%2Fpath%2Fto%2Fgitlab.socket`
- `unix:///path/to/hgitaly.socket`
are brought up for the first time when they're needed in the install flow. Not clear where one would find these files.