heptapod issueshttps://foss.heptapod.net/heptapod/heptapod/-/issues2024-03-27T09:04:41Zhttps://foss.heptapod.net/heptapod/heptapod/-/issues/1461Failing batched migration BackfillProjectStatisticsStorageSizeWithRecentSize2024-03-27T09:04:41ZGeorges RacinetFailing batched migration BackfillProjectStatisticsStorageSizeWithRecentSizeIn GitLab 16.7 (Heptapod 1.1), the repository size statistics are now being computed upstream with the `recent_objects_size` method, whose distinction with the `size` method does not translate well in Mercurial.
This causes problems, th...In GitLab 16.7 (Heptapod 1.1), the repository size statistics are now being computed upstream with the `recent_objects_size` method, whose distinction with the `size` method does not translate well in Mercurial.
This causes problems, the most visible one being that the `BackfillProjectStatisticsStorageSizeWithRecentSize` fails, bringing undue concern to operators.
It is also possible that update of statistics is stalled because of that.
We don't feel like implementing the full underlying [HGitaly method](hgitaly#170) in the now EOL Heptapod 1.1 series, but we can at least simply make `#recent_objects_size` return the same thing as `#size`: it is after all not really wrong and it will at least provide a proper migration landmark version Heptapod 1.1.3. We can then at least consider implementing the HGitaly method in the Heptapod 1.3 timeframe, probably starting with the same equation.Heptapod 1.1.3Georges RacinetGeorges Racinethttps://foss.heptapod.net/heptapod/heptapod/-/issues/1459Inspect changes in Gitaly 7b48d9ea13c367c97518e8055053a79b978dc0072024-03-20T13:22:51ZGitLab Release Watcher BotInspect changes in Gitaly 7b48d9ea13c367c97518e8055053a79b978dc007
Upstream merge commit dce7033ecc69ea03f7808c7c937dc7e82f77a9a6 changes Gitaly server version from
f4254cd79ac0366860c6f699fcdbe61829166ac8 to 7b48d9ea13c367c97518e8055053a79b978dc007, with changes in protocol or one of the
source subtre...
Upstream merge commit dce7033ecc69ea03f7808c7c937dc7e82f77a9a6 changes Gitaly server version from
f4254cd79ac0366860c6f699fcdbe61829166ac8 to 7b48d9ea13c367c97518e8055053a79b978dc007, with changes in protocol or one of the
source subtrees currently under watch.
The topic `upstream-merge` is at 357 non-merge commits.
To further inspect, go to an up to date Gitaly source clone and run:
```shell
git diff f4254cd79ac0366860c6f699fcdbe61829166ac8..7b48d9ea13c367c97518e8055053a79b978dc007 -- proto/*.proto internal/backup
```
Here is a preview, truncated at 500 lines:
```diff
diff --git a/proto/blob.proto b/proto/blob.proto
index ddbf1182a..f81ec91c6 100644
--- a/proto/blob.proto
+++ b/proto/blob.proto
@@ -243,6 +243,10 @@ message LFSPointer {
bytes data = 2;
// oid is the object ID of the blob.
string oid = 3;
+ // file_size is the size given when parsing the LFS pointer spec.
+ int64 file_size = 4;
+ // file_oid is the object id given when parsing the LFS pointer spec.
+ bytes file_oid = 5;
}
// GetLFSPointersRequest is a request for the GetLFSPointers RPC.
```
A merge request may have already been submitted, check that on
the [merge commit](dce7033ecc69ea03f7808c7c937dc7e82f77a9a6),
as usually changes in Gitaly are not breaking, compliance becoming
mandatory in the following development cycles.https://foss.heptapod.net/heptapod/heptapod/-/issues/1452Cannot push git commit as it is not present locally2024-03-18T00:06:15ZMaxim MozgovoyCannot push git commit as it is not present locally### Summary
I have a large Mercurial repo hosted by Heptapod 0.38.1.
A couple of days ago I merged a large number of old branches (>100) into a single branch. If it matters, the name of this branch begins with a dot, the rest of the nam...### Summary
I have a large Mercurial repo hosted by Heptapod 0.38.1.
A couple of days ago I merged a large number of old branches (>100) into a single branch. If it matters, the name of this branch begins with a dot, the rest of the name is letter-only.
The repo works fine locally, but when I attempt pushing it, I get the following message:
```
remote: cannot push git commit 479ab0d3537d as it is not present locally
remote: (please try pulling first, or as a fallback run git-cleanup to re-export the missing commits)
abort: push failed on remote
```
I am at loss. There is no git involved (apart from Heptapod-side internal git). There is no commit "479ab0d3537d" in the Hg history. Any hints would be greatly appreciated.
I'd attach the log, but not sure which one is relevant here.https://foss.heptapod.net/heptapod/heptapod/-/issues/1448Make 1.3 the stable Heptapod series2024-03-26T22:14:42ZGeorges RacinetMake 1.3 the stable Heptapod series<!-- This is a task list for when an Heptapod version changes status.
Usually needed after an older version dropped out of support and we need
the current development branch to move to the next release, hence current
version has to beco...<!-- This is a task list for when an Heptapod version changes status.
Usually needed after an older version dropped out of support and we need
the current development branch to move to the next release, hence current
version has to become `stable` and older version has to become `oldstable`.
This task list applies to a single one of these two shifts.
-->
### Description
Part of #1445
Bumped series: stable
Shifted series: default
### Merging
Most tasks The goal is to merge the shifted branch into the bumped branch.
Unless explicitely stated, the branch names coincide with the series name as
defined above, hence for example a simple merge/commit with the bumped series
being `oldstable` (and the shifted series being `stable`) would be done with:
```
hg update oldstable
hg merge stable
hg commit
```
### CI Images
- [heptapod-gitaly](https://foss.heptapod.net/heptapod/ci-images/heptapod-gitaly)
+ [x] merge, commit
+ [x] push skipping CI (will be triggered by `heptapod-base`)
- [heptapod-base](https://foss.heptapod.net/heptapod/ci-images/heptapod-base/-/pipelines)
+ [x] merge, check/fix `assets/install_pythonlibs`
+ [x] commit, push
+ [x] pipeline ok
- [hgitaly-rust](https://foss.heptapod.net/heptapod/ci-images/hgitaly-rust/-/pipelines)
+ [x] merge, commit, push
+ [x] pipeline ok
- [mercurial/hg-current](https://foss.heptapod.net/heptapod/ci-images/mercurial/-/pipelines)
No change
### Components that are forked from upstream GitLab
For these ones, the mapping from series to branch names is:
```
default: heptapod
stable: heptapod-stable
oldstable: heptapod-oldstable
```
- [Heptapod Shell](https://foss.heptapod.net/heptapod/heptapod-shell/-/pipelines)
+ [x] merge, commit in a topic
+ [x] push and create a Merge Request so that a pipeline runs
+ [x] pipeline ok
- [Heptapod Rails]:
+ [x] merge, don't commit
+ [x] **Important** check `HEPTAPOD_SERIES` in `heptapod-ci.yml`, it should
match the bumped series. Release scripts will read this to know for which
series they are working. A wrong value here gives rise to wildly
inconsistent binary builds (Omnibus etc.).
+ [x] commit without topic, push (usually the diff is
too big to open a MR).
### Python components
- [HGitaly](https://foss.heptapod.net/heptapod/hgitaly/-/pipelines)
+ [x] merge, commit, push skipping pipeline
- [py-heptapod](https://foss.heptapod.net/heptapod/py-heptapod/-/pipelines)
+ [x] merge, commit if needed, push
+ [x] pipeline ok (trigger manually if no merge changeset, so that it
also triggers the dependent HGitaly pipeline)
### Development, build and release tooling
- [heptapod-tests](https://foss.heptapod.net/heptapod/heptapod-tests/-/pipelines):
- [x] merge and check the base image name in `.gitlab-ci.yml`:
it should be the target Heptapod version, e.g, `0-21-testing`.
- [x] commit in a topic, push, open MR.
- [x] check that the pipeline uses the appropriate image.
- [x] pipeline ok
- [Omnibus Heptapod]
(branch naming is like all forks, `heptapod`, `heptapod-stable` etc.)
+ [x] merge the shifted branch, do not commit yet
+ [x] if changes in `lib/` or `files/` are non-trivial: commit them in a
topic, start a MR to get a pipeline (it won't perform package builds).
Otherwise, just push as draft without topic.
+ [x] pipeline ok if there was one
+ [x] merge the bumped branch into the release branch (e.g.,
`heptapod-0-41`, `heptapod-1.0`, etc). The diff should be empty or
almost. Commit, push.
- [x] [HDK](https://foss.heptapod.net/heptapod/py-heptapod): update the
`release-stable` or `release-oldstable` entry in `lib/gdk/config.rb`
on the `heptapod` branch (we have one single branch to rule all
series as of this writing but that can change in face of big future
structural changes).
- [Heptapod Rails]:
+ [x] merge the bumped branch into the release branch (e.g.,
'heptapod-0-21', 'heptapod-0-22' etc). The diff should be almost empty,
especially if the shifted branch was fully merged in the release branch.
+ [x] check that the `HEPTAPOD_SERIES` is correct in `heptapod-ci.yml` (it
is not if it was done in the same changeset as the merge of
`heptapod` into `heptapod-stable`).
+ [x] commit in a topic, manually create MR with the `Upstream merge` label,
set to auto-merge. This will create the full pipeline with Omnibus and
dependent Heptapod Tests pipeline
+ [x] Check that the Omnibus pipeline runs on the correct branch
+ [ ] pipelines ok. Congratulations, both Rails merges are published and
releases from the bumped series will be smooth.
- [HDK Workspaces](https://foss.heptapod.net/heptapod/hdk-workspaces):
+ [x] update the `gdk-*.yml` files for the affected series (commit/push)
+ [x] signal other developers that they must run
`./heptapod-switch-new-stable` in their workspaces.
[Heptapod Rails]: https://foss.heptapod.net/heptapod/heptapod/-/pipelines
[Omnibus Heptapod]: https://foss.heptapod.net/heptapod/omnibus-heptapod/-/pipelineshttps://foss.heptapod.net/heptapod/heptapod/-/issues/1417Reconsider rules to set iid and timestamps on issues done for Heptapod API Im...2024-03-21T13:42:51ZGeorges RacinetReconsider rules to set iid and timestamps on issues done for Heptapod API ImportThe conflict solved in #1416 shows that much has changed upstream. In particular setting `iid` seems to be possible with enough user rights… It would be great if we could let go of our custom code there.The conflict solved in #1416 shows that much has changed upstream. In particular setting `iid` seems to be possible with enough user rights… It would be great if we could let go of our custom code there.Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/1399Error 500 when creating a tag2024-02-12T18:43:10ZGraham ClinchError 500 when creating a tag### Summary
Creating a new tag on a hg repository results in a 500 error page
### Steps to reproduce
- Create a blank Mercurial project.
- Press the '+' drop down and select 'This Repository -> New tag'.
- Be directed to the 'New Tag...### Summary
Creating a new tag on a hg repository results in a 500 error page
### Steps to reproduce
- Create a blank Mercurial project.
- Press the '+' drop down and select 'This Repository -> New tag'.
- Be directed to the 'New Tag' page (<project path>/-/tags/new).
- Complete the form (for example, with a tag name of 'tag1') and press 'Create tag'.
- Receive an error 500.
### What is the current *bug* behavior?
Attempting to create a tag results in an error 500 page and no signs of the tag being created.
### What is the expected *correct* behavior?
The tag should be created, or the UI to create tags hidden/
### Relevant logs and/or screenshots
```
2024-02-12T18:31:38.478730Z INFO find_commit{correlation_id=Some("01HPF9DJ64V8QN13120M2NJK84") request=FindCommitRequest { repository: Some(Repository { storage_name: "default", relative_path: "@hashed/85/27/8527a891e224136950ff32ca212b45bc93f69fbb801c3b1ebedac52775f99e61.git", git_object_directory: "", git_alternate_object_directories: [], gl_repository: "project-14", gl_project_path: "XXX/tag-test" }), revision: "branch/default" }}: rhgitaly::service::commit: Processing
2024-02-12T18:31:38.479033Z INFO find_commit{correlation_id=Some("01HPF9DJ64V8QN13120M2NJK84") request=FindCommitRequest { repository: Some(Repository { storage_name: "default", relative_path: "@hashed/85/27/8527a891e224136950ff32ca212b45bc93f69fbb801c3b1ebedac52775f99e61.git", git_object_directory: "", git_alternate_object_directories: [], gl_repository: "project-14", gl_project_path: "XXX/tag-test" }), revision: "branch/default" }}: rhgitaly::service::commit: Revision resolved as da559fb589d9f7be587fa212bb228b1cfc37722a
{"component":"gitaly.UnaryServerInterceptor","correlation_id":"01HPF9DJ64V8QN13120M2NJK84","diskcache":"a4376cec-5d6b-488e-833d-28ab378e180e","grpc.meta.auth_version":"v2","grpc.meta.client_name":"gitlab-web","grpc.meta.deadline_type":"regular","grpc.meta.method_operation":"mutator","grpc.meta.method_scope":"repository","grpc.meta.method_type":"unary","grpc.method":"UserCreateTag","grpc.request.deadline":"2024-02-12T18:32:33.285","grpc.request.fullMethod":"/gitaly.OperationService/UserCreateTag","grpc.request.glProjectPath":"XXX/tag-test","grpc.request.glRepository":"project-14","grpc.request.repoPath":"@hashed/85/27/8527a891e224136950ff32ca212b45bc93f69fbb801c3b1ebedac52775f99e61.git","grpc.request.repoStorage":"default","grpc.service":"gitaly.OperationService","grpc.start_time":"2024-02-12T18:31:38.485","level":"info","msg":"diskcache state change","pid":319,"remote_ip":"XXX","span.kind":"server","system":"grpc","time":"2024-02-12T18:31:38.492Z","user_id":"3","username":"XXX"}
{"component":"gitaly.UnaryServerInterceptor","correlation_id":"01HPF9DJ64V8QN13120M2NJK84","error":"repository not found","error_metadata":{"relative_path":"@hashed/85/27/8527a891e224136950ff32ca212b45bc93f69fbb801c3b1ebedac52775f99e61.git","storage_name":"default"},"grpc.code":"NotFound","grpc.meta.auth_version":"v2","grpc.meta.client_name":"gitlab-web","grpc.meta.deadline_type":"regular","grpc.meta.method_operation":"mutator","grpc.meta.method_scope":"repository","grpc.meta.method_type":"unary","grpc.method":"UserCreateTag","grpc.request.deadline":"2024-02-12T18:32:33.285","grpc.request.fullMethod":"/gitaly.OperationService/UserCreateTag","grpc.request.glProjectPath":"XXX/tag-test","grpc.request.glRepository":"project-14","grpc.request.payload_bytes":222,"grpc.request.repoPath":"@hashed/85/27/8527a891e224136950ff32ca212b45bc93f69fbb801c3b1ebedac52775f99e61.git","grpc.request.repoStorage":"default","grpc.response.payload_bytes":0,"grpc.service":"gitaly.OperationService","grpc.start_time":"2024-02-12T18:31:38.485","grpc.time_ms":6.545,"level":"info","msg":"finished unary call with code NotFound","pid":319,"remote_ip":"XXX","span.kind":"server","system":"grpc","time":"2024-02-12T18:31:38.492Z","user_id":"3","username":"XXX"}
Gitlab::Git::Repository::NoRepository (5:repository not found.):
lib/gitlab/git/wraps_gitaly_errors.rb:16:in `rescue in wrapped_gitaly_errors'
lib/gitlab/git/wraps_gitaly_errors.rb:6:in `wrapped_gitaly_errors'
lib/gitlab/git/repository.rb:687:in `add_tag'
app/models/repository.rb:297:in `add_tag'
app/services/tags/create_service.rb:17:in `execute'
app/controllers/projects/tags_controller.rb:66:in `create'
app/controllers/application_controller.rb:514:in `set_current_admin'
lib/gitlab/session.rb:11:in `with_session'
app/controllers/application_controller.rb:505:in `set_session_storage'
lib/gitlab/i18n.rb:114:in `with_locale'
lib/gitlab/i18n.rb:120:in `with_user_locale'
app/controllers/application_controller.rb:496:in `set_locale'
app/controllers/application_controller.rb:489:in `set_current_context'
lib/gitlab/metrics/elasticsearch_rack_middleware.rb:16:in `call'
lib/gitlab/middleware/memory_report.rb:13:in `call'
lib/gitlab/middleware/speedscope.rb:13:in `call'
lib/gitlab/database/load_balancing/rack_middleware.rb:23:in `call'
lib/gitlab/middleware/rails_queue_duration.rb:33:in `call'
lib/gitlab/etag_caching/middleware.rb:21:in `call'
lib/gitlab/metrics/rack_middleware.rb:16:in `block in call'
lib/gitlab/metrics/web_transaction.rb:46:in `run'
lib/gitlab/metrics/rack_middleware.rb:16:in `call'
lib/gitlab/middleware/go.rb:20:in `call'
lib/gitlab/middleware/query_analyzer.rb:11:in `block in call'
lib/gitlab/database/query_analyzer.rb:37:in `within'
lib/gitlab/middleware/query_analyzer.rb:11:in `call'
lib/gitlab/middleware/multipart.rb:173: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/path_traversal_check.rb:48: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:15:in `call'
lib/gitlab/middleware/webhook_recursion_detection.rb:15:in `call'
config/initializers/fix_local_cache_middleware.rb:11:in `call'
lib/gitlab/middleware/compressed_json.rb:44:in `call'
lib/gitlab/middleware/rack_multipart_tempfile_factory.rb:19:in `call'
lib/gitlab/middleware/sidekiq_web_static.rb:20:in `call'
lib/gitlab/metrics/requests_rack_middleware.rb:79:in `call'
lib/gitlab/middleware/release_env.rb:13:in `call'
```
#### Details about the Heptapod instance where the bug occurs
Docker container installation:
```
Heptapod 1.0.1 (GitLab CE 16.6.7)
Mercurial 6.6.2 / Python 3.9.17 / hg-evolve 11.1.1
```https://foss.heptapod.net/heptapod/heptapod/-/issues/1393Support for documentation sites?2024-02-09T09:45:40ZCharlieCSupport for documentation sites?Excuses if this is the wrong place to ask but, with ReadTheDocs announcing EOL for Mercurial, I need to look for an alternative way to publish documentation. Generating the docs via CI shouldn't be a problem, I guess this is more about c...Excuses if this is the wrong place to ask but, with ReadTheDocs announcing EOL for Mercurial, I need to look for an alternative way to publish documentation. Generating the docs via CI shouldn't be a problem, I guess this is more about configuring what happens with the results.
Sad to see Python's community providing less choice for developers. Makes me all the more grateful that you do the work to provide Heptapod.https://foss.heptapod.net/heptapod/heptapod/-/issues/1367Automate releases triggered by upstream GitLab patch versions2024-01-25T17:20:56ZGeorges RacinetAutomate releases triggered by upstream GitLab patch versionsAs #1366 can testify, the release watcher process is still in working order.
Since the last time it has been actually useful, lots of progress has been made, and we now have an automatic merge system running regularly (both are actually...As #1366 can testify, the release watcher process is still in working order.
Since the last time it has been actually useful, lots of progress has been made, and we now have an automatic merge system running regularly (both are actually tied, so that the release watcher does not miss a tag because the auto-merge would have been the one to pull it).
By reusing logic done for the auto-merge, it should be possible to fully automate creating an Heptapod release from an upstream patch release.
Some ideas:
- abort and file an issue if there is a bump of GitLab Shell version, or a significant Gitaly change (protocol, backups)
- resolve conflicts as in auto-merge (for now just trivial ones such as in issue templates, most unlikely in upstream stable branches, but it could become smarter)
- merge Omnibus (not yet handled by upstream auto-merge process), filing issues upon problems.
- perform MR, monitor it and set the appropriate tag
- ultimately, perform Docker image tagging and pushing
All of this will take some time, because it is very hard to test separately, but it would give us eventually:
- less latency in producing security releases (down to a couple of hours)
- more developer time available for other endeavors.https://foss.heptapod.net/heptapod/heptapod/-/issues/1366GitLab 16.6.62024-01-25T17:15:07ZGitLab Release Watcher BotGitLab 16.6.6
A new release tag v16.6.6 appeared in upstream GitLab.
It should be considered for a new Heptapod release.
## Conversion task list
Each code block starts at the top of the clone of the
[upstream-conversion](https://foss.heptapod.net/...
A new release tag v16.6.6 appeared in upstream GitLab.
It should be considered for a new Heptapod release.
## Conversion task list
Each code block starts at the top of the clone of the
[upstream-conversion](https://foss.heptapod.net/heptapod/upstream-conversion)
project used for the conversion.
(if a script is not found, add `$HOME/.local/bin` to $PATH)
- [x] Main repository:
```
fetch-stable-branches && \
convert-pull-local --branch-prefix 16-6-stable --push && \
convert-git-tags-push -R heptapod-rails
```
- [ ] Omnibus:
```
fetch-stable-branches --gitlab-repo omnibus-gitlab && \
convert-pull-local --gitlab-repo omnibus-gitlab \
--heptapod-repo omnibus-heptapod \
--branch-prefix 16-6-stable \
--push && \
convert-git-tags-push -R omnibus-heptapod
```
- [ ] Heptapod Shell, if `GITLAB_SHELL_VERSION` changed in main repository
(see the
[README](https:/foss.heptapod.net/heptapod/upstream-conversion/README)
of the upstream-conversion project for instructions)
Pinging @gracinet @raphael.gomes @franckbret, ding ding dinghttps://foss.heptapod.net/heptapod/heptapod/-/issues/1325Prevent creation of tags in topics?2024-01-08T13:31:30ZPierre AugierPrevent creation of tags in topics?Happy new year George and others working around Heptapod!
I was wondering if there would be a way to prevent pushing tags in topics?Happy new year George and others working around Heptapod!
I was wondering if there would be a way to prevent pushing tags in topics?https://foss.heptapod.net/heptapod/heptapod/-/issues/1296Move to start of the list in board fails2024-01-26T17:51:11ZCédric Kriercedric.krier@b2ck.comMove to start of the list in board failsWhen using the action on an issue from the board view: "Move to start of the list".
The error "An error occurred while moving the issue. Please try again." is raised.When using the action on an issue from the board view: "Move to start of the list".
The error "An error occurred while moving the issue. Please try again." is raised.https://foss.heptapod.net/heptapod/heptapod/-/issues/1254Web UI for VCS Type stats2024-03-21T13:42:48ZGeorges RacinetWeb UI for VCS Type statsThis is a follow-up to #471, after which we have an API endpoint, but no direct display in the admin dashboard.This is a follow-up to #471, after which we have an API endpoint, but no direct display in the admin dashboard.Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/1224Heptapod 0.38.0rc3 Web UI fails with largefiles2024-02-07T17:24:52ZMaxim MozgovoyHeptapod 0.38.0rc3 Web UI fails with largefilesI am trying to create a merge request from Web UI. I can choose source and target branches from the dropdown lists, but then the following error message appears:
```
The form contains the following errors:
Source branch "branch/master" ...I am trying to create a merge request from Web UI. I can choose source and target branches from the dropdown lists, but then the following error message appears:
```
The form contains the following errors:
Source branch "branch/master" does not exist
Target branch "branch/default" does not exist
```
This happens for any pair of branches. The `production.log` file contains this:
```
GRPC::Internal (13:Error loading repository: Other(UnsupportedFeature("repository requires feature unknown to this Mercurial: largefiles")). debug_error_string:{"created":"@1698994287.948491304","description":"Error received from peer unix:/var/opt/gitlab/rhgitaly/rhgitaly.socket","file":"src/core/lib/surface/call.cc","file_line":1063,"grpc_message":"Error loading repository: Other(UnsupportedFeature("repository requires feature unknown to this Mercurial: largefiles"))","grpc_status":13}):
config/initializers/enumerator_next_patch.rb:9:in `block (2 levels) in <module:EnumeratorNextPatch>'
lib/gitlab/gitaly_client/call.rb:43:in `block (3 levels) in instrument_stream'
...
```
Largefiles is globally enabled in `heptapod.hgrc`. I also noticed that the Files view (`/-/tree/branch/default` url) shows 404 error.
I think this is quite important because it makes doing merge requests impossible.
**UPDATE**
I upgraded the server to 0.38.1, and it's even worse. Now even the main page cannot be opened if a single repo has largefiles enabled. The error is visible in `production.log` as
```
ActionView::Template::Error (13:Error loading repository: Other(UnsupportedFeature("repository requires feature unknown to this Mercurial: largefiles")).):
24: - if project.creator && use_creator_avatar
25: = render Pajamas::AvatarComponent.new(project.creator, size: 48, alt: '', class: 'gl-mr-5')
26: - else
27: = render Pajamas::AvatarComponent.new(project, size: 48, alt: '', class: 'gl-mr-5')
28: .project-cell{ class: css_class }
29: .project-details.gl-pr-9.gl-sm-pr-0.gl-w-full.gl-display-flex.gl-flex-direction-column{ data: { qa_selector: 'project_content', qa_project_name: project.name } }
30: .gl-display-flex.gl-align-items-center.gl-flex-wrap
lib/gitlab/git/wraps_gitaly_errors.rb:15:in `rescue in wrapped_gitaly_errors'
lib/gitlab/git/wraps_gitaly_errors.rb:6:in `wrapped_gitaly_errors'
lib/gitlab/git/tree.rb:25:in `tree_entries'
lib/gitlab/git/rugged_impl/tree.rb:30:in `tree_entries'
lib/gitlab/git/tree.rb:21:in `where'
app/models/tree.rb:16:in `initialize'
app/models/repository.rb:717:in `new'
app/models/repository.rb:717:in `head_tree'
...
```https://foss.heptapod.net/heptapod/heptapod/-/issues/1223Unblock projects with a single GitLab branch being a topic2024-03-21T13:27:25ZGeorges RacinetUnblock projects with a single GitLab branch being a topic## The problem
When a project starts its life as empty and the first pushed changeset is a topic, the following happens:
1. The GitLab branch corresponding to the topic (what is seen as "branch" in the Heptapod UI) being the only GitLa...## The problem
When a project starts its life as empty and the first pushed changeset is a topic, the following happens:
1. The GitLab branch corresponding to the topic (what is seen as "branch" in the Heptapod UI) being the only GitLab branch of the project becomes automatically the default GitLab branch of the project. This is unavoidable: in GitLab, a non-empty project must have a default branch.
2. The default GitLab branch being always protected, it cannot be deleted. On the other hand, pushing the publication of the topic would look as a GitLab branch deletion from the GitLab side (together with creation of its non-topical counterpart, usually `branch/default`), hence it is refused by the application.
3. Since there is no other GitLab branch at this point, there is no way to solve the problem by changing the default GitLab branch to something else.
## Possible mitigations
None of this is surprising to people much accustomed to topics and Heptapod, and there are ways to get out of this double bind.
Here's for instance one:
1. Push a second changeset with the same topic
2. Publish the first changeset of the topic. This creates `branch/default` but does not delete the topic's GitLab branch. Moreover, Heptapod in this case automatically switches the default GitLab branch to `branch/default`.
3. Now that the GitLab branch for the topic is not the default GitLab branch, unprotect it (the stickiness of its protection is possibly something recent). We are finally in the normal situation, the topic can be fully published right away or through a MR etc.
BUT this is very confusing to new users of Heptapod or Mercurial with topics.
## Human context
One may wonder why someone would have the weird idea of starting a project with a topic, especially when not used to them.
It happens when users have configuration that require all new changesets to have a topic (or enforce it by setting a random topic). The settings are truly useful to avoid involuntary publications in well established projects, and are therefore often set as part of new worker onboarding, or just shared by friendly colleagues. But they make quite of an impedance mismatch in this case.
The end effect to the user is that nothing works, while colleagues keep on repeating that everything is simple. In other words, it can be catastrophic in terms of user perception.
## Solution
As mentioned above, Heptapod is already able to automatically switch the default GitLab branch away from a topic. The problem is just that the topic cannot be deleted in the same push. Actually what happens here is that branch protection has been tightened since the automatic switch was introduced.
Heptapod should in this case just bypass the branch protection. The precise criteria should be that the protected branch is for a topic that is undergoing publication, while still checking for publication rights. Both `pre-receive` and `post-receive` hooks should already carry the needed information about this.Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/1215Problem with a merge commit2023-10-17T15:18:27ZGeorges RacinetProblem with a merge commitAuto-merge of !574 failed with this (end of) traceback that occurred in the heptapod/py-heptapod> part:
```
/home/hg/venv/lib/python3.9/site-packages/hgext3rd/heptapod/state_maintainer.py", line 1080, in heptapod_apply_changes
self....Auto-merge of !574 failed with this (end of) traceback that occurred in the heptapod/py-heptapod> part:
```
/home/hg/venv/lib/python3.9/site-packages/hgext3rd/heptapod/state_maintainer.py", line 1080, in heptapod_apply_changes
self.update_default_gitlab_branch(changes)
File "/home/hg/venv/lib/python3.9/site-packages/hgext3rd/heptapod/state_maintainer.py", line 1141, in update_default_gitlab_branch
self.set_default_gitlab_ref(new_default_ref)
File "/home/hg/venv/lib/python3.9/site-packages/hgext3rd/heptapod/no_git.py", line 99, in set_default_gitlab_ref
b"Setting GitLab branch to %s" % new_gl_branch)
TypeError: %b requires a bytes-like object, or an object that implements __bytes__, not 'NoneType'
' command was: ["/home/hg/venv/bin/hg", "commit", "--config", "ui.username=GitLab Release Watcher Bot <gitlab-release-watcher.bot@heptapod.net>", "-m", "Merge branch 'topic/heptapod/upstream-merge' into 'branch/heptapod'\n\nMerge upstream GitLab into Heptapod\n\nSee merge request heptapod/heptapod!574"
```
I didn't expect this MR to require a merge commit, but that one is on my side.
On the other hand, it is very worrying that this `hg commit` actually tried to change the default branch, I'm actually glad it failed. And one wonders what the argument was, it should have been `bytes` (name of the new default branch). This could be the one and same bug, or two bugs in cascade.https://foss.heptapod.net/heptapod/heptapod/-/issues/1190Git projects have Mercurial Publisher in protected branches and tags roles2024-03-21T13:27:26ZGeorges RacinetGit projects have Mercurial Publisher in protected branches and tags rolesBecause GitLab 16.0 comes with refactorings related to the adding of the Instance Admins case to the roles selectable in protected branches and tags project settings, I have reason to believe the Mercurial specific role could be displaye...Because GitLab 16.0 comes with refactorings related to the adding of the Instance Admins case to the roles selectable in protected branches and tags project settings, I have reason to believe the Mercurial specific role could be displayed even on Git repositories.
This is ~~worth checking before finalization of a Heptapod version based on GitLab 16.x~~ confirmed on Heptapod 0.40.0, hence a minor UI bug.Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/870Error displayed on Merge Request if anonymous2024-03-21T13:27:24ZGeorges RacinetError displayed on Merge Request if anonymousSpotted by @av6 on mercurial/mercurial-devel>, which is quite public.
The red banner says : "An error occurred while retrieving approval data for this merge request."
There is no HTTP error in XHRs, but a GraphQL request (with HTTP cod...Spotted by @av6 on mercurial/mercurial-devel>, which is quite public.
The red banner says : "An error occurred while retrieving approval data for this merge request."
There is no HTTP error in XHRs, but a GraphQL request (with HTTP code 200) bears an error that seems related
Query:
```json
[{"operationName":"approvedBy","variables":{"projectPath":"mercurial/mercurial-devel","iid":"651"},"query":"query approvedBy($projectPath: ID!, $iid: String!) {\n project(fullPath: $projectPath) {\n id\n mergeRequest(iid: $iid) {\n id\n approvedBy {\n nodes {\n ...User\n __typename\n }\n __typename\n }\n userPermissions {\n canApprove\n __typename\n }\n __typename\n }\n __typename\n }\n}\n\nfragment User on User {\n id\n avatarUrl\n name\n username\n webUrl\n __typename\n}\n"},{"operationName":"rebaseQuery","variables":{"projectPath":"mercurial/mercurial-devel","iid":"651"},"query":"query rebaseQuery($projectPath: ID!, $iid: String!) {\n project(fullPath: $projectPath) {\n id\n mergeRequest(iid: $iid) {\n id\n rebaseInProgress\n targetBranch\n userPermissions {\n pushToSourceBranch\n __typename\n }\n pipelines {\n nodes {\n id\n project {\n id\n fullPath\n __typename\n }\n __typename\n }\n __typename\n }\n __typename\n }\n __typename\n }\n}\n"},{"operationName":"readyToMerge","variables":{"projectPath":"mercurial/mercurial-devel","iid":"651"},"query":"query readyToMerge($projectPath: ID!, $iid: String!) {\n project(fullPath: $projectPath) {\n id\n ...ReadyToMerge\n __typename\n }\n}\n\nfragment ReadyToMerge on Project {\n id\n onlyAllowMergeIfPipelineSucceeds\n mergeRequestsFfOnlyEnabled\n squashReadOnly\n mergeRequest(iid: $iid) {\n ...ReadyToMergeMergeRequest\n __typename\n }\n __typename\n}\n\nfragment ReadyToMergeMergeRequest on MergeRequest {\n id\n detailedMergeStatus\n autoMergeEnabled\n shouldRemoveSourceBranch\n forceRemoveSourceBranch\n defaultMergeCommitMessage\n defaultSquashCommitMessage\n squash\n squashOnMerge\n availableAutoMergeStrategies\n hasCi\n mergeable\n mergeWhenPipelineSucceeds\n commitCount\n diffHeadSha\n userPermissions {\n canMerge\n removeSourceBranch\n updateMergeRequest\n __typename\n }\n targetBranch\n mergeError\n commitsWithoutMergeCommits {\n nodes {\n id\n sha\n shortId\n title\n message\n __typename\n }\n __typename\n }\n headPipeline {\n id\n status\n path\n active\n __typename\n }\n __typename\n}\n"}]
```
Response:
```json
[
{"data":{"project":{"id":"gid://gitlab/Project/22","mergeRequest":null,"__typename":"Project"}},
"errors":[{"message":"Cannot return null for non-nullable field MergeRequestPermissions.canApprove"}]},
{"data":{"project":{"id":"gid://gitlab/Project/22","mergeRequest":{"id":"gid://gitlab/MergeRequest/11329","rebaseInProgress":false,"targetBranch":"branch/default","userPermissions":{"pushToSourceBranch":false,"__typename":"MergeRequestPermissions"},"pipelines":{"nodes":[{"id":"gid://gitlab/Ci::Pipeline/70041","project":{"id":"gid://gitlab/Project/22","fullPath":"mercurial/mercurial-devel","__typename":"Project"},"__typename":"Pipeline"}],"__typename":"PipelineConnection"},"__typename":"MergeRequest"},"__typename":"Project"}}},
{"data":{"project":{"id":"gid://gitlab/Project/22","onlyAllowMergeIfPipelineSucceeds":true,"mergeRequestsFfOnlyEnabled":true,"squashReadOnly":true,"mergeRequest":{"id":"gid://gitlab/MergeRequest/11329","detailedMergeStatus":"MERGEABLE","autoMergeEnabled":false,"shouldRemoveSourceBranch":false,"forceRemoveSourceBranch":false,"defaultMergeCommitMessage":"Merge branch 'topic/stable/hgweb-baseurl' into 'branch/default'\n\nhgweb: use web.baseurl config in hgweb\n\nSee merge request mercurial/mercurial-devel!651","defaultSquashCommitMessage":"hgweb: use web.baseurl config in hgweb","squash":false,"squashOnMerge":false,"availableAutoMergeStrategies":[],"hasCi":true,"mergeable":false,"mergeWhenPipelineSucceeds":false,"commitCount":1,"diffHeadSha":"f396b7eac2987431888121372058d748dabfcb21","userPermissions":{"canMerge":false,"removeSourceBranch":false,"updateMergeRequest":false,"__typename":"MergeRequestPermissions"},"targetBranch":"branch/default","mergeError":null,"commitsWithoutMergeCommits":{"nodes":[{"id":"gid://gitlab/CommitPresenter/f396b7eac2987431888121372058d748dabfcb21","sha":"f396b7eac2987431888121372058d748dabfcb21","shortId":"f396b7ea","title":"hgweb: use web.baseurl config in hgweb","message":"hgweb: use web.baseurl config in hgweb\n\nThe config was already used by hgwebdir, but not hgweb. It seems like this was\nan oversight, so this changeset makes hgweb use it as well.\n\nThe WSGI handler itself uses an independent copy of the repository. It seems\nexcessive to do that just for fetching a config, so the code fishes the ui\nobject from an existing repository.","__typename":"Commit"}],"__typename":"CommitConnection"},"headPipeline":{"id":"gid://gitlab/Ci::Pipeline/70041","status":"SUCCESS","path":"/mercurial/mercurial-devel/-/pipelines/70041","active":false,"__typename":"Pipeline"},"__typename":"MergeRequest"},"__typename":"Project"}}}]
```Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/832HGitaly (?) causes Internal server error2023-11-03T07:59:48ZMaxim MozgovoyHGitaly (?) causes Internal server errorI have a bunch of repositories hosted by Heptapod. Some of them are in Git format, but mostly Mercurial. The biggest pain so far are constant "500" errors after anything being pushed to a server. In a nutshell, this is what I see:
- Ever...I have a bunch of repositories hosted by Heptapod. Some of them are in Git format, but mostly Mercurial. The biggest pain so far are constant "500" errors after anything being pushed to a server. In a nutshell, this is what I see:
- Everything works fine until someone pushes an update to any of the Mercurial repositories.
- The web interface becomes inaccessible for all Mercurial repos (but seems to be OK for git).
- Any repo can be pulled using a Mercurial client, but an attempt to push fails with the "API is not acessible" error.
- Usually the server remains inaccessible for quite a while (up to few hours), but then comes back.
- Sometimes it does not come back, so I have to restart Heptapod.
I tried reading the server's "production" log, and all I see there is
```
GRPC::DeadlineExceeded (4:Deadline Exceeded. debug_error_string:{"created":"@1691078759.000722367","description":"Error received from peer unix:/var/opt/gitlab/hgitaly/hgitaly.socket","file":"src/core/lib/surface/call.cc","file_line":1063,"grpc_message":"Deadline Exceeded","grpc_status":4}):
lib/gitlab/gitaly_client.rb:192:in `execute'
...
```
The machine serving Heptapod isn't stellar (A hi-end Synology NAS), but when it works, it works fine. Some of the repos are very large and have large binary files, so I guess the internal git conversion might take time for them. HGitaly doesn't seem to write its own logs, so I have no idea where else to look and what can be done. So I would appreciate any help (Heptapod 0.32.1)
UPD: I checked `mercurial.log`, and the only errors I see are something like
```
repo:/var/opt/gitlab/git-data/repositories/@hashed/2c/62/2c624232cdd221771294dfbb310aca000a0df6ac8b66b696d90ef06fdefb64a3.hg [hg] Got code 1 while sending GitLab 'GitLab 'pre-receive' hook' hook details=API is not accessible
```
So I guess it is git mirroring after all, but it blocks everything, and it seems that even small changes might trigger a long process.https://foss.heptapod.net/heptapod/heptapod/-/issues/765Backups: accomodate remove-all at restoration2023-07-21T23:57:48ZGeorges RacinetBackups: accomodate remove-all at restorationThe `-remove-all-repositories` of `gitaly-backup` is finally put to use in 76b74f63c8bf (see also hgitaly#139).
However, we cannot use it in Heptapod right away, because it will also remove the namespaces hierarchy that we are using for...The `-remove-all-repositories` of `gitaly-backup` is finally put to use in 76b74f63c8bf (see also hgitaly#139).
However, we cannot use it in Heptapod right away, because it will also remove the namespaces hierarchy that we are using for group-level Mercurial configuration (caught by our functional tests). Hence in Heptapod 0.38, we will have to filter out those storages that have a HGitaly address. Upstream concern is about the race in repositories created between the restoration trigger and actual restoration, probably not so much a concert for us (for the time being).
To get back to upstream we will need either:
- to find another storage solution for group-level configuration
- to make HGitaly servers completely separate from Gitaly servers, but that is very far away and cannot accomodate any legacy (hg-git based) project.https://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.2