heptapod issueshttps://foss.heptapod.net/groups/heptapod/-/issues2022-01-26T15:18:34Zhttps://foss.heptapod.net/heptapod/hgitaly/-/issues/81RepositoryService: implement GetInfoAttributes2022-01-26T15:18:34ZGeorges RacinetRepositoryService: implement GetInfoAttributesAfter a quick look into Gitaly reference implementation, it looks like it returns the non checked-in version of [Git Attributes](https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes), i.e. the content of `info/attributes`.
See ...After a quick look into Gitaly reference implementation, it looks like it returns the non checked-in version of [Git Attributes](https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes), i.e. the content of `info/attributes`.
See heptapod#437 for more perspective
Used notably in the `BlobLanguageFromGitAttributes` Model concern on the Rails side, which makes this RPC method necessary for operation without a Git repository.https://foss.heptapod.net/heptapod/hgitaly/-/issues/82RepositoryService: implement ApplyGitattributes2022-01-26T15:18:34ZGeorges RacinetRepositoryService: implement ApplyGitattributesOn the Rails side, the corresponding method on the `Git::Repository` class is `copy_gitattributes` and is needed for fully native repositories without any Git repo (see heptapod!290).
See also [official doc of Git Attributes](https://gi...On the Rails side, the corresponding method on the `Git::Repository` class is `copy_gitattributes` and is needed for fully native repositories without any Git repo (see heptapod!290).
See also [official doc of Git Attributes](https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes)
Apparently, what the reference Gitaly implementation does is to copy the checked-in `.gitattributes` file at a given revision into the non checked-in (global) `info/attributes`.
I suppose this makes for a much faster access than querying the blob content over and over.
This makes it more directly related to heptapod#437 than hgitaly#81
Here we could decide to fallback to or merge with `.heptapod-attributes` or `.hgattributes` files if they exist (and if we want to introduce those files).https://foss.heptapod.net/heptapod/heptapod/-/issues/550native Migration: project full path2024-03-21T13:27:24ZGeorges Racinetnative Migration: project full pathThis data will have to be carried over in migration to native from the Git repo to the way HGitaly will store it once hgitaly#83 and hgitaly#84 are done.This data will have to be carried over in migration to native from the Git repo to the way HGitaly will store it once hgitaly#83 and hgitaly#84 are done.Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/551GitalyClient::RepositoryService: Plugging in HGitaly Git config and full path...2021-10-13T13:40:13ZGeorges RacinetGitalyClient::RepositoryService: Plugging in HGitaly Git config and full path supportThis is the Rails side of hgitaly#83 and hgitaly#84.
It also requires an immediate migration of existing native repositories (not to be confused with migration of hg-git based repositories to native ones, which is covered by heptapod#550).This is the Rails side of hgitaly#83 and hgitaly#84.
It also requires an immediate migration of existing native repositories (not to be confused with migration of hg-git based repositories to native ones, which is covered by heptapod#550).https://foss.heptapod.net/heptapod/hgitaly/-/issues/85RepositoryService: implement Cleanup2022-01-26T15:18:34ZGeorges RacinetRepositoryService: implement CleanupThis is not a rewrapping of `git clean`. Rather, this relies on `git worktree remove` and `git worktree prune`.
These are similar to the temporary working directories we're using on the server side with `hg share`. See `man git-worktree...This is not a rewrapping of `git clean`. Rather, this relies on `git worktree remove` and `git worktree prune`.
These are similar to the temporary working directories we're using on the server side with `hg share`. See `man git-worktree` for more information.
This method is low priority because:
- our Mercurial shares are automatically removed after use (but we could later on reuse them with a pool for performance reasons on large repositories). Also their creation is currently entirely managed from the Rails app, so it would be consistent to perform any cleanup of them from the same place, namely `HgGitRepository`.
- `Git::Repository` rescues the call if it failsHGitaly3: fully in chargehttps://foss.heptapod.net/heptapod/heptapod-tests/-/issues/20Adapt to Selenium 4.0.02022-10-12T11:51:52ZGeorges RacinetAdapt to Selenium 4.0.0With the `selenium/standalone-chrome` image with id `sha256:201110c834d393a2919c2ac0250dea2e05b79b7259c39262e3a383f08a53f3dd` that was built today (2021-10-13T15:33:05.339520033Z), our tests all fail, see for instance job [#253322](https...With the `selenium/standalone-chrome` image with id `sha256:201110c834d393a2919c2ac0250dea2e05b79b7259c39262e3a383f08a53f3dd` that was built today (2021-10-13T15:33:05.339520033Z), our tests all fail, see for instance job [#253322](https://foss.heptapod.net/heptapod/heptapod-tests/-/jobs/253322).
The error log diplays a `4.0.0` version that was indeed [released today](https://github.com/SeleniumHQ/selenium/releases/tag/selenium-4.0.0).
I did retry an older passing job that also failed to double check that the failure is not due to heptapod-tests nor Heptapod itself.https://foss.heptapod.net/heptapod/foss.heptapod.net/-/issues/112Hosting for Oxford Oberon Compiler2021-10-14T08:17:09ZMike SpiveyHosting for Oxford Oberon Compiler## Description of the projects to be hosted
- Project Name: Oxford Oberon Compiler OBC
- Project URL: https://spivey.oriel.ox.ac.uk/corner/Oxford_Oberon-2_compiler
- Existing Github repo: https://github.com/Spivoxity/obc-3
- Project Mai...## Description of the projects to be hosted
- Project Name: Oxford Oberon Compiler OBC
- Project URL: https://spivey.oriel.ox.ac.uk/corner/Oxford_Oberon-2_compiler
- Existing Github repo: https://github.com/Spivoxity/obc-3
- Project Maintainers: Mike Spivey
- Project License: MIT
Please explain here how they meet our current criteria.
### Main criteria
- [X] Free / Open Source
- [X] main development repositories
- [X] you are an official maintainer of the project
- [X] agreement to acknowledge where appropriate the help provided by Octobus
and Clever Cloud by hosting on foss.heptapod.net
### Additional information
Knowing this can help in case there are constraints on resources and/or
administrators availability at the time of the request. It can also help us
suggest the right solution for the needs of the project.
- is the project officially released? In downstream distributions or
packaging systems?
-- The project is fairly mature and has had a dozen releases.
- estimation of the user base if possible, or number of downloads,
reverse dependencies…
-- Users are in the hundreds -- Oberon is admittedly a niche language.
- number of maintainers and regular contributors
-- I am the only maintainer and committer.
- where is the project currently hosted? Are there issue trackers,
review systems, CI/CD to hook to or to replace somehow?
-- Following the demise of Mercurial hosting at Bitbucket, I'm using Github. But I much prefer Mercurial for all my stuff.
### Hosting type
What would you like to have?
- [ ] a top-level group
- [ ] a project in an existing group
- [X] just a project in your personal namespace
## Post approval maintainer task list
See [README](README.md#maintainer-task-list-for-the-import-to-happen)
for explanations.
- [ ] Reviewing [Heptapod workflow](https://heptapod.net/pages/faq.html#workflow)
## Post import maintainer task list
- [ ] Add the Octobus and Clever cloud acknowledgement at the selected place.
- [ ] Communicate about the migration to help others to aware of the options
(for example on mastodon, twitter, bitbucket thread, mailing list, …)https://foss.heptapod.net/heptapod/foss.heptapod.net/-/issues/113Login with GitLab2021-10-15T00:55:01ZAnatoli BabeniaLogin with GitLabhttps://foss.heptapod.net/ doesn't have GitLab among single button login options. Why?
![image](/uploads/214de82460a83080b4f4c21f31c2b423/image.png)https://foss.heptapod.net/ doesn't have GitLab among single button login options. Why?
![image](/uploads/214de82460a83080b4f4c21f31c2b423/image.png)https://foss.heptapod.net/heptapod/heptapod/-/issues/552Run `hg debug-repair-issue6528` server-side2024-03-21T13:27:26ZGeorges RacinetRun `hg debug-repair-issue6528` server-sideSee Mercurial [bug6528](https://bz.mercurial-scm.org/show_bug.cgi?id=6528)
Even though Heptapod has never and never will ship Mercurial 5.8, there is a possibility that a corrupted filelog could have been pushed by a 5.8 client.
It cou...See Mercurial [bug6528](https://bz.mercurial-scm.org/show_bug.cgi?id=6528)
Even though Heptapod has never and never will ship Mercurial 5.8, there is a possibility that a corrupted filelog could have been pushed by a 5.8 client.
It could be part of the housekeeping task, or perhaps a separate Rake task, I'm open to suggestions.
Depends on #541 (5.7.1 does not have this debug/repair command, obviously)Heptapod 1.3.2Georges RacinetGeorges Racinethttps://foss.heptapod.net/heptapod/heptapod/-/issues/553Changeset signature support2021-10-20T08:14:21ZGeorges RacinetChangeset signature supportChangeset signature should be eventually supported in Heptapod, as this is a native GitLab feature.
There are at least two existing systems:
- the `gpg` extension that ships with Mercurial core
- the [commitsigs](https://foss.heptapod....Changeset signature should be eventually supported in Heptapod, as this is a native GitLab feature.
There are at least two existing systems:
- the `gpg` extension that ships with Mercurial core
- the [commitsigs](https://foss.heptapod.net/mercurial/commitsigs) third party extensionhttps://foss.heptapod.net/heptapod/heptapod-tests/-/issues/21Adapt for Mercurial 5.9 on the client side2021-10-23T17:26:42ZGeorges RacinetAdapt for Mercurial 5.9 on the client sideLots of error messages that were dumped to stdout by Mercurial 5.7 are written to stderr with 5.9. This is purely a client-side issue, independently of the version on the server.
Job [#256798](https://foss.heptapod.net/heptapod/heptapod...Lots of error messages that were dumped to stdout by Mercurial 5.7 are written to stderr with 5.9. This is purely a client-side issue, independently of the version on the server.
Job [#256798](https://foss.heptapod.net/heptapod/heptapod-tests/-/jobs/256798) is an example of that.https://foss.heptapod.net/heptapod/heptapod/-/issues/557Wiki "clone repository" help page still mentions git2021-10-25T12:40:49ZPacien TRAN-GIRARDWiki "clone repository" help page still mentions gitThe instructions on the help page at `[instance]/[group]/[project]/-/wikis/git_access` all mention the `git` command instead of `hg`.The instructions on the help page at `[instance]/[group]/[project]/-/wikis/git_access` all mention the `git` command instead of `hg`.https://foss.heptapod.net/heptapod/foss.heptapod.net/-/issues/114test2021-10-26T11:36:01ZPyNtestabcabchttps://foss.heptapod.net/heptapod/hgitaly/-/issues/86Follow-up from "Switching Gitaly Comparison test_ref and test_commit to new s...2022-01-26T15:18:35ZSushil KhanchiFollow-up from "Switching Gitaly Comparison test_ref and test_commit to new style"The following discussion from !80 should be addressed:
- [ ] @khanchi97 started a [discussion](https://foss.heptapod.net/heptapod/hgitaly/-/merge_requests/80#note_164924): (+1 comment)
> It would be better if `chunked` helper hand...The following discussion from !80 should be addressed:
- [ ] @khanchi97 started a [discussion](https://foss.heptapod.net/heptapod/hgitaly/-/merge_requests/80#note_164924): (+1 comment)
> It would be better if `chunked` helper handle this (as commit desc says). This is not looking very good, tbh. If you want, it can be done after this series.
>
> Btw, I am wondering what exactly the discrepancy is?https://foss.heptapod.net/heptapod/heptapod/-/issues/563500 error on imported from "GitLab Cluster Management" template2021-11-04T16:45:12ZArthur Lutz500 error on imported from "GitLab Cluster Management" templateWe're trying to migrate from "Gitlab Managed Apps" as described in https://forge.extranet.logilab.fr/help/user/clusters/migrating_from_gma_to_project_template.md but we're getting a 500 error when creating the repo from the template.
...We're trying to migrate from "Gitlab Managed Apps" as described in https://forge.extranet.logilab.fr/help/user/clusters/migrating_from_gma_to_project_template.md but we're getting a 500 error when creating the repo from the template.
```
Started GET "/cubicweb/scaleway-cluster-management" for 82.65.202.15 at 2021-11-04 13:13:24 +0000
Started GET "/api/v4/projects/cubicweb%2Fcubes%2Ftreeview/pipelines?page=1&per_page=1&ref=cubicweb-treeview-version-0.1
.0" for 92.154.88.244 at 2021-11-04 13:13:24 +0000
Processing by ProjectsController#show as HTML
Parameters: {"namespace_id"=>"cubicweb", "id"=>"scaleway-cluster-management"}
Started GET "/logilab/infra/sysadmin/noteable/issue/6127/notes" for 89.0.49.110 at 2021-11-04 13:13:25 +0000
Completed 304 Not Modified in 0ms (Allocations: 5)
Rendered layout layouts/project.html.haml (Duration: 528.0ms | Allocations: 21644)
Completed 500 Internal Server Error in 644ms (ActiveRecord: 23.1ms | Elasticsearch: 0.0ms | Allocations: 37118)
ActionView::Template::Error (No route matches {:action=>"show", :controller=>"projects/tree", :id=>nil, :namespace_id=>
#<Group id:23 @cubicweb>, :project_id=>#<Project id:727 cubicweb/scaleway-cluster-management>>}, possible unmatched con
straints: [:id]
Did you mean? namespace_project_tree_url):
51: - if @project.empty_repo?
52: = render 'stat_anchor_list', anchors: @project.empty_repo_statistics_anchors
53: - else
54: = render 'stat_anchor_list', anchors: @project.statistics_anchors(show_auto_devops_callout: show_au
to_devops_callout)
55:
56: .home-panel-home-desc.mt-1
57: - if @project.description.present?
app/helpers/routing/projects_helper.rb:6:in `project_tree_path'
app/presenters/project_presenter.rb:183:in `files_anchor_data'
app/presenters/project_presenter.rb:29:in `statistics_anchors'
app/views/projects/_home_panel.html.haml:54
app/views/projects/_home_panel.html.haml:48
app/views/projects/show.html.haml:14
app/controllers/application_controller.rb:124:in `render'
app/controllers/application_controller.rb:552:in `block in allow_gitaly_ref_name_caching'
lib/gitlab/gitaly_client.rb:377:in `allow_ref_name_caching'
app/controllers/application_controller.rb:551:in `allow_gitaly_ref_name_caching'
app/controllers/application_controller.rb:501:in `set_current_admin'
lib/gitlab/session.rb:11:in `with_session'
app/controllers/application_controller.rb:492:in `set_session_storage'
lib/gitlab/i18n.rb:99:in `with_locale'
lib/gitlab/i18n.rb:105:in `with_user_locale'
app/controllers/application_controller.rb:486:in `set_locale'
app/controllers/application_controller.rb:480: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/web_transaction.rb:21:in `run'
lib/gitlab/metrics/rack_middleware.rb:16:in `call'
lib/gitlab/middleware/speedscope.rb:13: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/middleware/rack_multipart_tempfile_factory.rb:19:in `call'
lib/gitlab/metrics/requests_rack_middleware.rb:74:in `call'
lib/gitlab/middleware/release_env.rb:12:in `call'
```
Creating the repo as a personnal project seems to work, but we then can't transfer it to the group.https://foss.heptapod.net/heptapod/upstream-conversion/-/issues/3fetch-watch-tags: GitLab Shell version analysis2021-11-05T09:57:40ZGeorges Racinetfetch-watch-tags: GitLab Shell version analysisThe script should be able to check if the new upstream version comes with a new GitLab Shell version and display the corresponding task or not accordinglyThe script should be able to check if the new upstream version comes with a new GitLab Shell version and display the corresponding task or not accordinglyhttps://foss.heptapod.net/heptapod/heptapod/-/issues/564UI for Mercurial pull mirrors2024-03-21T13:42:50ZGeorges RacinetUI for Mercurial pull mirrorsThe pull mirrors introduced for #306 can only be created through the REST API.The pull mirrors introduced for #306 can only be created through the REST API.Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/565Mercurial divergence in Pull Mirrors2021-11-05T15:53:07ZGeorges RacinetMercurial divergence in Pull Mirrors(extracted from #306)
Specify what should happen if pull brings divergence (in the sense of changeset obsolescence, not in the sense used by upstream GitLab). The only actual protection we have is against multiple heads conditions (whic...(extracted from #306)
Specify what should happen if pull brings divergence (in the sense of changeset obsolescence, not in the sense used by upstream GitLab). The only actual protection we have is against multiple heads conditions (which some divergences can create), but that will make the pull completely fail. Do we want to do something smarter here?https://foss.heptapod.net/heptapod/heptapod/-/issues/566Mercurial Pull Mirror cron job2022-06-06T23:05:52ZGeorges RacinetMercurial Pull Mirror cron jobCurrently, Mercurial pull mirrors have to be triggered by an API call. It would be nice to have a regular background task.
It should be optional for those users that want only to trigger (e.g, by a hook in the remote repo)Currently, Mercurial pull mirrors have to be triggered by an API call. It would be nice to have a regular background task.
It should be optional for those users that want only to trigger (e.g, by a hook in the remote repo)https://foss.heptapod.net/heptapod/heptapod/-/issues/567Mercurial Pull Mirror: option to pull only public changesets2021-11-05T15:53:07ZGeorges RacinetMercurial Pull Mirror: option to pull only public changesetsAnother nice-to-have.Another nice-to-have.