heptapod issueshttps://foss.heptapod.net/groups/heptapod/-/issues2022-01-26T15:18:32Zhttps://foss.heptapod.net/heptapod/hgitaly/-/issues/8Tests: bring coverage up to 100% and enforce it2022-01-26T15:18:32ZGeorges RacinetTests: bring coverage up to 100% and enforce itThis kind of thing is waaaay easier to do when the project is young.This kind of thing is waaaay easier to do when the project is young.Heptapod 0.17.0Georges RacinetGeorges Racinethttps://foss.heptapod.net/heptapod/py-heptapod/-/issues/8Make sure the GitLab branches state file is present2022-01-18T13:18:35ZGeorges RacinetMake sure the GitLab branches state file is presentThe GitLab branches state file was introduced in heptapod#373. Any push to current Mercurial repos (native ones are still based on hg-git) will create it if needed, but that still leaves the case of projects with no recent pushes.
Some ...The GitLab branches state file was introduced in heptapod#373. Any push to current Mercurial repos (native ones are still based on hg-git) will create it if needed, but that still leaves the case of projects with no recent pushes.
Some [HGitaly RPC methods](heptapod#9) can only be properly implemented using that state file, so we'd need to be able to rely on its presence.
The bad case would be a Mercurial native project created before introduction of the state file and left to rest since then. Being already native, ensuring the state file presence in a migration task would not be enough for these. Usually these should be testing projects that no one really cares about, but still we don't want to create hard errors that could break more general pages. Also, some project might be accidentally be flagged as Mercurial native because of some bug in a migration task or of human error.
In case the state file is missing, we should initialize it from the auxiliary Git repository, whose state is to be considered good enough.
It's hard to imagine realistic scenarios where the Git repository would become out of sync without a push, but it's possible that the Git repository vanishes entirely (assume hg-git not used any more for native projects, wrongly flag a project as native, backup and restore, assume the backup task has not been written with that in mind).
In the worst case, starting afresh with an empty file will at worst trigger too many GitLab notifications on next push.
- [ ] provide a method easy to import from HGitaly
- [ ] provide a command that Rails can call (for backup logic in the %"HGitaly2: fully native" times)Heptapod 0.19.1https://foss.heptapod.net/heptapod/heptapod/-/issues/9Merge-request changes tab crash with forking2023-08-29T04:51:14ZGeorges RacinetMerge-request changes tab crash with forkingPhilippe forked my bighgperf repo https://heptapod.octobus.net/octobus-public/bighgperf and create a MR https://heptapod.octobus.net/octobus-public/bighgperf/merge_requests/2/commits
The changes tab on the MR crash https://heptapod.octo...Philippe forked my bighgperf repo https://heptapod.octobus.net/octobus-public/bighgperf and create a MR https://heptapod.octobus.net/octobus-public/bighgperf/merge_requests/2/commits
The changes tab on the MR crash https://heptapod.octobus.net/octobus-public/bighgperf/merge_requests/2/diffs
The relevant traceback in log seems to be:
```
Processing by Projects::MergeRequests::DiffsController#show as JSON
Parameters: {"namespace_id"=>"octobus-public", "project_id"=>"bighgperf", "id"=>"2"}
Completed 500 Internal Server Error in 82ms (ActiveRecord: 3.9ms)
ActionView::Template::Error (undefined method `[]' for nil:NilClass):
19: - if image_diff && image_replaced
20: = view_file_button(diff_file.old_content_sha, diff_file.old_path, project, replaced: true)
21:
22: = view_file_button(diff_file.content_sha, diff_file.file_path, project)
23: = view_on_environment_button(diff_file.content_sha, diff_file.file_path, environment) if environment
24:
25: = render 'projects/fork_suggestion'
app/models/commit.rb:56:in `truncate_sha'
app/helpers/commits_helper.rb:205:in `truncate_sha'
app/helpers/commits_helper.rb:188:in `block in view_file_button'
app/helpers/commits_helper.rb:182:in `view_file_button'
app/views/projects/diffs/_file.html.haml:22:in `_app_views_projects_diffs__file_html_haml___3643828193321276867_69910592937540'
app/views/projects/diffs/_diffs.html.haml:28:in `_app_views_projects_diffs__diffs_html_haml__2670589013129813169_69910588255680'
app/views/projects/merge_requests/diffs/_diffs.html.haml:3:in `_app_views_projects_merge_requests_diffs__diffs_html_haml__1483594632090195770_69910590608900'
app/controllers/application_controller.rb:268:in `view_to_html_string'
app/controllers/projects/merge_requests/diffs_controller.rb:15:in `block in show'
lib/gitlab/gitaly_client.rb:193:in `allow_n_plus_1_calls'
app/controllers/projects/merge_requests/diffs_controller.rb:14:in `show'
lib/gitlab/i18n.rb:47:in `with_locale'
lib/gitlab/i18n.rb:53:in `with_user_locale'
app/controllers/application_controller.rb:346:in `set_locale'
lib/gitlab/middleware/multipart.rb:93:in `call'
lib/gitlab/request_profiler/middleware.rb:14:in `call'
lib/gitlab/middleware/go.rb:17:in `call'
lib/gitlab/etag_caching/middleware.rb:11:in `call'
lib/gitlab/middleware/read_only.rb:30:in `call'
lib/gitlab/request_context.rb:18:in `call'
lib/gitlab/metrics/requests_rack_middleware.rb:27:in `call'
```Smoother Web UIGeorges RacinetGeorges Racinethttps://foss.heptapod.net/heptapod/foss.heptapod.net/-/issues/9Heptapod 0.8.0 or rc42020-01-16T21:42:28ZGeorges RacinetHeptapod 0.8.0 or rc4## Details about the upgrade
We don't know yet whether it'll be 0.8.0 final or a new release candidate.
## Imports
- [x] #4 attempt 1## Details about the upgrade
We don't know yet whether it'll be 0.8.0 final or a new release candidate.
## Imports
- [x] #4 attempt 1Georges RacinetGeorges Racinet2020-01-14https://foss.heptapod.net/heptapod/heptapod-runner/-/issues/9"unrelated" repository requires force pull2022-01-18T13:54:04ZPierre-Yves David"unrelated" repository requires force pullIn some case (eg: the root have been rewritten), the previous clone will be considered unrelated to the new clone. We should ignore that and always use `hg pull --force`In some case (eg: the root have been rewritten), the previous clone will be considered unrelated to the new clone. We should ignore that and always use `hg pull --force`Heptapod 0.12.0https://foss.heptapod.net/heptapod/heptapod-docker/-/issues/9Reduce the size of the layer for the Rails application2020-09-24T09:02:02ZGeorges RacinetReduce the size of the layer for the Rails applicationWith the work done in !12 and a few follow-ups, the size of our main image is about 300MB on top of the base GitLab image.
The bulk of that improvement is #5: loading the [Rails application](https://foss.heptapod.net/heptapod/heptapod) ...With the work done in !12 and a few follow-ups, the size of our main image is about 300MB on top of the base GitLab image.
The bulk of that improvement is #5: loading the [Rails application](https://foss.heptapod.net/heptapod/heptapod) from a pre-generated tarball instead of making it a full repository. But the corresponding layer (for Dockerfile `ADD` command) weighs 137MB whereas our diff from GitLab 12.3.9 to Heptapod 0.13.0rc1 is about 300K only. That means it should be possible to gain another 130MB with little effort.
Some ideas:
1. Have the Dockerfile `ADD` be smarter and not touch unchanged files (could be just a matter of metadata)
2. Instead of a full tarball, generate a diff and apply it with `patch` during the build
3. Pre-generate a "delta tarball", with only those files that actually differ between GitLab upstream and Heptapod
Note that at some point in the future, we'll rebuild everything from the base OS image (currently Ubuntu 16.04) or from new "cloud native" GitLab images. This could happen in a few months, and that will make current optimization efforts obsolete,
Gaining 130MB with at most a few hours of work seems right in that perspective.Heptapod 0.16.0https://foss.heptapod.net/heptapod/website/-/issues/9FAQ: how to launch `hg` in the Docker container2020-07-13T09:50:35ZGeorges RacinetFAQ: how to launch `hg` in the Docker containerIt's a recurring question, should be added as a FAQ item.
It's crucial to have the proper user and configuration, with
something like (from memory, untested):
```
su git -s /bin/bash
HGRCPATH=/etc/gitlab/heptapod.hgrc:/opt/gitlab/etc/d...It's a recurring question, should be added as a FAQ item.
It's crucial to have the proper user and configuration, with
something like (from memory, untested):
```
su git -s /bin/bash
HGRCPATH=/etc/gitlab/heptapod.hgrc:/opt/gitlab/etc/docker.hgrc hg …
```https://foss.heptapod.net/heptapod/heptapod-tests/-/issues/9Assertions for removal of Git auxiliary repository2020-06-02T11:22:23ZGeorges RacinetAssertions for removal of Git auxiliary repositoryWe need more assertions in project removal tests.
Original false alarm:
On the current heptapod-0-13 branches, I'm seeing cases of auxiliary Git repositories not being properly removed upon project removal.
Not clear at this point whe...We need more assertions in project removal tests.
Original false alarm:
On the current heptapod-0-13 branches, I'm seeing cases of auxiliary Git repositories not being properly removed upon project removal.
Not clear at this point when this regression happened, but I don't want it in Heptapod 0.13.0Heptapod 0.13.1https://foss.heptapod.net/heptapod/hgitaly/-/issues/9RefService: implement FindRefName2022-01-26T15:18:34ZGeorges RacinetRefService: implement FindRefNameThe method is already declared in [hgitaly.service.ref](hgitaly/service/ref.py).
There is a detailed explanation of what has to be done its docstring, but it is debatable.The method is already declared in [hgitaly.service.ref](hgitaly/service/ref.py).
There is a detailed explanation of what has to be done its docstring, but it is debatable.HGitaly1: Hg SHAsGeorges RacinetGeorges Racinethttps://foss.heptapod.net/heptapod/heptapod/-/issues/10Disable forking2020-04-15T10:57:28ZGeorges RacinetDisable forkingFor now, let us make our life easier and disabled repository forking and crosse repository pull request.
**Problem**
Forking a project results in a 500 error whenever the project new is accessed.
**Task description**
For now,...For now, let us make our life easier and disabled repository forking and crosse repository pull request.
**Problem**
Forking a project results in a 500 error whenever the project new is accessed.
**Task description**
For now, disable:
- [ ] forking ability
- [ ] cross-repository merge requests.
These abilities will be restored by #24.Smoother Web UIGeorges RacinetGeorges Racinethttps://foss.heptapod.net/heptapod/foss.heptapod.net/-/issues/10Migration to foss.heptapod.net2020-02-11T17:34:21ZGeorges RacinetMigration to foss.heptapod.netThis instance will become the starting point for the upcoming [public Heptapod hosting of FOSS projects](https://www.clever-cloud.com/en/heptapod), under the new foss.heptapod.net address.
Preparation task list:
- [x] DNS entry for fos...This instance will become the starting point for the upcoming [public Heptapod hosting of FOSS projects](https://www.clever-cloud.com/en/heptapod), under the new foss.heptapod.net address.
Preparation task list:
- [x] DNS entry for foss.heptapod.net
- [x] SMTP/IMAP accounts for foss@dev.heptapod.net
- [x] OAuth2 Bitbucket application for SSO
- [x] OAuth2 Bitbucket application for imports
- [x] GitHub application for SSO
- [x] Review of existing configuration (out of database)
- [x] switch over test
- [x] functional testing of new instance
- [x] switch over date decision
- [x] switch over announcement
- [x] redirection: set up a virtual host ready to redirect dev.heptapod.net to foss.heptapod.net
- [x] waiting page for dev.heptapod.net during transition
- [x] waiting page for foss.heptapod.net for time between official annoucement to actual launch
- [x] Bitbucket import timeout
- [ ] review / prepare communication elements on sign-in page, help page etc.
- [x] clean up old, broken, test projects on dev.h.n, leading to warnings upon backup restoration on target system
- [x] Configuring foss.h.n to use mattermost.h.n (out of database)
- [x] Create reCAPTCHA credentials for foss.h.n
Switch-over task list:
- [x] Activate waiting page for dev.h.n
- [x] Shut down dev.h.n services
- [x] Produce final backup, make it available to Clever
- [x] Restore on foss.h.n
- [x] Remove waiting page for foss.h.n
After switch-over task list:
- [x] Reconfigure landing page redirection (must *not* be to https://dev.heptapod.net/). Admin Settings > Home page URL / After sign out path
- [x] Recreate group-level HGRCs (see heptapod#174)
- [x] backups configuration
- [x] Using foss.h.n for SSO login on mattermost.h.n
- [x] Activate redirection from dev.h.n to foss.h.n
- [ ] Update communication elements for sign-in and help pages
- [x] Reconfigure / reregister CI runners
- [x] Review of Mattermost configuration for heptapod projects (through the web / in database)
Before decommission deadline (2020-02-12):
- [x] Move redirection virtual host alongside the one for foss.h.n
- [x] Move Mattermost to a new server
- [x] Move GitLab upstream conversion Git and Mercurial repos elsewhere
Misc:
- [x] update configuration of Octobus mirrors (should work with redirection in the meantime)
These lists are probably not comprehensive, new items will be added if needed.https://foss.heptapod.net/heptapod/heptapod-runner/-/issues/10Take clonebundles into account2023-01-05T14:29:05ZGeorges RacinetTake clonebundles into accountCurrently, runner versions 0.2.x always perform a `hg pull -r`, even if the local repo has just been created.
This has the severe drawback of not leveraging clonebundles if there are any, making the first pull
much slower and much more ...Currently, runner versions 0.2.x always perform a `hg pull -r`, even if the local repo has just been created.
This has the severe drawback of not leveraging clonebundles if there are any, making the first pull
much slower and much more stressful for the server.
It's not hard, using `hg debugcapabilities REMOTE_URL` to detect that the remote repo has a clonebundle.Heptapod 0.12.0https://foss.heptapod.net/heptapod/website/-/issues/10Mattermost login process is unclear2020-07-10T12:33:39ZAndi McClureMattermost login process is unclearLet's say I am a new user to Heptapod (as I was this morning) and I wanted to find something like a support forum. There is a big "Contact" button on the front page of Heptapod so I click that. I get [this page](https://heptapod.net/page...Let's say I am a new user to Heptapod (as I was this morning) and I wanted to find something like a support forum. There is a big "Contact" button on the front page of Heptapod so I click that. I get [this page](https://heptapod.net/pages/contact-us.html#contact-us):
![Screen_Shot_2020-06-03_at_3.27.07_PM](/uploads/e2e2fa0cc39d62d14390b1f3f03bc0ea/Screen_Shot_2020-06-03_at_3.27.07_PM.png)
**These instructions are misleading.** If I click "User Support Mattermost Channel", I get this login page:
![Screen_Shot_2020-06-03_at_3.27.20_PM](/uploads/02710a4525b8e74fc7bee140a4b11522/Screen_Shot_2020-06-03_at_3.27.20_PM.png)
The correct thing to do here is ignore the user/password login and click "Sign in with Gitlab". However, as a new user, I could not figure this out. I assumed "Sign in with Gitlab" meant signing in with a Gitlab.com account. I wasted some time looking at other pages and wound up creating a Gitlab.com account just to log in (unnecessarily it turns out).
Georges Racinet told me on your Mattermost that right now you cannot alter the "Sign in with Gitlab" page. So I think my **expected behavior** is, you should change the "Contact" page so that users do not get confused by the instructions. My suggested text is:
* register on our own Heptapod instance, then start the conversation on the User Support Mattermost channel by clicking the "sign in with GitLab" buttonhttps://foss.heptapod.net/heptapod/heptapod-tests/-/issues/10test_snippets fails on CI2020-08-22T15:17:41ZGeorges Racinettest_snippets fails on CIBut it doesn't on my Docker testing rig.
Job [#88407](https://foss.heptapod.net/heptapod/heptapod-tests/-/jobs/88407) failed for 116569cb424c35636ec803832373e641d3a0bcd7:But it doesn't on my Docker testing rig.
Job [#88407](https://foss.heptapod.net/heptapod/heptapod-tests/-/jobs/88407) failed for 116569cb424c35636ec803832373e641d3a0bcd7:https://foss.heptapod.net/heptapod/heptapod-docker/-/issues/10Use the base image produced by omnibus-heptapod2020-09-24T11:28:13ZGeorges RacinetUse the base image produced by omnibus-heptapodOnce omnibus-heptapod#2 is ready, we can use the new base image instead of `gitlab/gitlab-ce`.
Potentially, `heptapod_revisions.json` would already be sitting in the filesystem, and obviously we wouldn't need to take care of the Rails a...Once omnibus-heptapod#2 is ready, we can use the new base image instead of `gitlab/gitlab-ce`.
Potentially, `heptapod_revisions.json` would already be sitting in the filesystem, and obviously we wouldn't need to take care of the Rails application, since it's included already, hence automatically closing #9.Heptapod 0.16.0https://foss.heptapod.net/heptapod/omnibus-heptapod/-/issues/10Internal Mercurial HTTP service2020-10-07T13:27:53ZGeorges RacinetInternal Mercurial HTTP serviceKnown as `hgserve` in the current Docker image, it would be much more consistent to manage it directly with Omnibus.
This is a good opportunity to give it a better name, taking into account that it'll be alongside `hgitaly`, same for th...Known as `hgserve` in the current Docker image, it would be much more consistent to manage it directly with Omnibus.
This is a good opportunity to give it a better name, taking into account that it'll be alongside `hgitaly`, same for the logs directory name.
The service should probably called `hg-inner-http`, to tell readily that it's for HTTP only, and not directly exposed (that's the job of Heptapod Workhorse).
Those are mild breaking changes for people managing installations, and a new Heptapod series is a good occasion to do that.
We can also probably take that opportunity to make various Gunicorn params (workers…) modifiable from the standard config instead of the ad-hoc environment variable.Heptapod 0.17.0https://foss.heptapod.net/heptapod/hgitaly/-/issues/10CommitService: implement FindCommits2022-01-26T15:18:32ZGeorges RacinetCommitService: implement FindCommitsWe have the `FindCommit` method, but not the `FindCommits` (plural)We have the `FindCommit` method, but not the `FindCommits` (plural)HGitaly1: Hg SHAsSushil KhanchiSushil Khanchihttps://foss.heptapod.net/heptapod/py-heptapod/-/issues/10Transaction identifier2024-02-09T15:56:41ZGeorges RacinetTransaction identifierFor [repository caches invalidation in HGitaly](hgitaly#57), we'll need a transaction identifier. This could be something as simple as a random UUID.
At some point, Mercurial will grow up something like this, and we'll then be able to r...For [repository caches invalidation in HGitaly](hgitaly#57), we'll need a transaction identifier. This could be something as simple as a random UUID.
At some point, Mercurial will grow up something like this, and we'll then be able to reuse it. Meanwhile, it's fairly simple to do it ourselves.Heptapod 1.0https://foss.heptapod.net/heptapod/foss.heptapod.net/-/issues/56Hosting Request for commitsigs (signing of Mercurial commits)2020-05-04T21:31:52ZassarbadHosting Request for commitsigs (signing of Mercurial commits)Hi,
I am seeking refuge for a single Mercurial-related project off of Bitbucket.
## Description of the projects to be hosted
- Project Name: commitsigs
- Project URL: https://bitbucket.org/aragost/commitsigs
- Project Maintainers: [me...Hi,
I am seeking refuge for a single Mercurial-related project off of Bitbucket.
## Description of the projects to be hosted
- Project Name: commitsigs
- Project URL: https://bitbucket.org/aragost/commitsigs
- Project Maintainers: [me](https://foss.heptapod.net/assarbad) (I haven't heard from [Martin](https://bitbucket.org/{9d06909e-8680-4a7e-ae4a-07afcfbded7e}/) in ages, despite attempts to contact him)
- Project License: GPLv2
### Main criteria
- [X] Free / Open Source
- [X] main development repositories
- [X] agreement to acknowledge where appropriate the help provided by Octobus
and Clever Cloud by hosting on foss.heptapod.net
* there is no dedicated website for this right now ... the only other place where `commitsigs` is mentioned is in the Mercurial Wiki, so I understand this may be a dealbreaker
### Priority Criteria
- [X] currently hosted on Bitbucket
- [X] officially released
## Post approval maintainer task list:
See [README](README.md#maintainer-task-list-for-the-import-to-happen)
for explanations.
- [X] Hosting Request assignee has repository membership on Bitbucket
- [X] Heptapod / Bitbucket accounts link ([assarbad](https://foss.heptapod.net/assarbad) <-> [assarbad](https://bitbucket.org/assarbad/))
- [X] Reviewing Heptapod workflow (just read [through this](https://octobus.net/blog/2019-09-04-heptapod-workflow.html))
## Post import maintainer task list:
- [X] Clone the project afresh from foss.heptapod.net.
- [X] Check that the repository looks good: branches are as expected in the
clone and the web interface, with no `wild` branches unless
there are known multiple heads.
- [X] Check that issues are imported, and notably that all open issues are
there. Watch for attachments etc.
- [X] Check that Pull Requests are imported, and in particular take a close
look at the resulting open Merge Requests - they should be backed by a
topic. Make sure you can navigate these in the fresh clone.
- [X] Check that against foss.heptapod.net, `hg outgoing` and `hg incoming`
from a prior clone are as expected
- [X] Add the Octobus and Clever cloud acknowledgement at the selected place.Georges RacinetGeorges Racinethttps://foss.heptapod.net/heptapod/foss.heptapod.net/-/issues/58Hosting request for Passlib (python password hashing library) & Cloud_SpTheme...2020-05-06T18:52:03ZEli CollinsHosting request for Passlib (python password hashing library) & Cloud_SpTheme (Sphinx Theme)Hi,
I'm looking to move two open source python projects off of Bitbucket; and would love to stick with Mercurial.
I've entered details of both projects here, but can definitely file the 2nd one as a separate issue if that's helpful!
-...Hi,
I'm looking to move two open source python projects off of Bitbucket; and would love to stick with Mercurial.
I've entered details of both projects here, but can definitely file the 2nd one as a separate issue if that's helpful!
- Eli
## Description of the projects to be hosted
### Project 1
- Project Name: Passlib
- Project URL: https://bitbucket.org/ecollins/passlib (docs at https://passlib.readthedocs.io)
- Project Maintainers: Eli Collins <elic@assurancetechnologies.com>
- Project License: BSD
### Project 2 (used by Passlib and others)
- Project Name: Cloud Sphinx Theme
- Project URL: https://bitbucket.org/ecollins/cloud_sptheme (docs at https://cloud_sptheme.readthedocs.io)
- Project Maintainers: Eli Collins <elic@assurancetechnologies.com>
- Project License: BSD
### Main criteria
- [x] Free / Open Source
- [x] main development repositories
- [x] agreement to acknowledge where appropriate the help provided by Octobus
and Clever Cloud by hosting on foss.heptapod.net
### Priority Criteria
- [x] currently hosted on Bitbucket
- [x] officially released
## Post approval maintainer task list:
See [README](README.md#maintainer-task-list-for-the-import-to-happen)
for explanations.
- [x] Hosting Request assignee has repository membership on Bitbucket
- [x] Heptapod / Bitbucket accounts link
- [x] Reviewing Heptapod workflow
## Post import maintainer task list:
- [x] Clone the project afresh from foss.heptapod.net.
- [x] Check that the repository looks good: branches are as expected in the
clone and the web interface, with no `wild` branches unless
there are known multiple heads.
- [x] Check that issues are imported, and notably that all open issues are
there. Watch for attachments etc.
- [x] Check that Pull Requests are imported, and in particular take a close
look at the resulting open Merge Requests - they should be backed by a
topic. Make sure you can navigate these in the fresh clone.
- [x] Check that against foss.heptapod.net, `hg outgoing` and `hg incoming`
from a prior clone are as expected
- [x] Add the Octobus and Clever cloud acknowledgement at the selected place.Pierre AugierPierre Augier