Forges usually have ways of listing repositories, either globally or per user/organisation. codearchiver should have a way of listing those to archive forges in their entirety or subsections of them, e.g. codearchiver https://gitea.arpa.li/ or codearchiver https://gitea.arpa.li/JustAnotherArchivist. This would emit some data from the forge listing and run each discovered repository with the appropriate module (possibly with an option to skip that).
Implementing this would likely mean separate FooInstance, FooUser/FooOrganisation, and FooRepository modules. Note that these can’t be detected from the URL alone, even if you know the forge type. For example, GitLab does not allow for distinguishing users and repositories; a URL like https://gitlab.example.org/foo/bar could be an ‘subgroup’ (subunit of an organisation) bar of foo or a ‘project’ (~ repository).
Forges usually have ways of listing repositories, either globally or per user/organisation. codearchiver should have a way of listing those to archive forges in their entirety or subsections of them, e.g. `codearchiver https://gitea.arpa.li/` or `codearchiver https://gitea.arpa.li/JustAnotherArchivist`. This would emit some data from the forge listing and run each discovered repository with the appropriate module (possibly with an option to skip that).
Software Heritage has implementations of listers for various forges: https://gitlab.softwareheritage.org/swh/devel/swh-lister
Implementing this would likely mean separate `FooInstance`, `FooUser`/`FooOrganisation`, and `FooRepository` modules. Note that these can't be detected from the URL alone, even if you know the forge type. For example, GitLab does not allow for distinguishing users and repositories; a URL like `https://gitlab.example.org/foo/bar` could be an 'subgroup' (subunit of an organisation) `bar` of `foo` or a 'project' (~ repository).
Forges usually have ways of listing repositories, either globally or per user/organisation. codearchiver should have a way of listing those to archive forges in their entirety or subsections of them, e.g.
codearchiver https://gitea.arpa.li/orcodearchiver https://gitea.arpa.li/JustAnotherArchivist. This would emit some data from the forge listing and run each discovered repository with the appropriate module (possibly with an option to skip that).Software Heritage has implementations of listers for various forges: https://gitlab.softwareheritage.org/swh/devel/swh-lister
Implementing this would likely mean separate
FooInstance,FooUser/FooOrganisation, andFooRepositorymodules. Note that these can’t be detected from the URL alone, even if you know the forge type. For example, GitLab does not allow for distinguishing users and repositories; a URL likehttps://gitlab.example.org/foo/barcould be an ‘subgroup’ (subunit of an organisation)baroffooor a ‘project’ (~ repository).