Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for private git servers / self-hosting. #84

Open
baoyachi opened this issue Dec 1, 2020 · 6 comments
Open

Support for private git servers / self-hosting. #84

baoyachi opened this issue Dec 1, 2020 · 6 comments
Labels

Comments

@baoyachi
Copy link

baoyachi commented Dec 1, 2020

I want to add svg image in my private repository? Support?

@baoyachi baoyachi changed the title this repository support private gitlab or private git with svg this repository support private gitlab or private git with used svg? Dec 1, 2020
@baoyachi baoyachi changed the title this repository support private gitlab or private git with used svg? this repository support private gitlab or private git? Dec 1, 2020
@sezna
Copy link

sezna commented Dec 12, 2020

I'd also like to know -- it's a great crate and I'd love to use it in my company's READMEs, but they are internal.

@robjtede
Copy link
Member

Some ideas have come up recently about enabling self hosting of a deps.rs instance with configuration for internal code hosting URLs and authentication.

@robjtede robjtede changed the title this repository support private gitlab or private git? Support for private git servers / self-hosting. Dec 12, 2020
@Feliix42
Copy link
Member

The interesting question would be: How do we fetch the Cargo.toml file? For the hosters currently implemented we use their raw-file URLs to avoid ending up cloning lots of data. I just looked at how Gitea and Gogs do this and they both have different URLs, with Gogs being similar to Gitlab. We could in principle implement the this for the most common self-hosted solutions, but I don't know if we want to maintain this long-term. Also, linking to a self-hosted repo would then always require to specify the software hosting the repo.

@lcmgh
Copy link

lcmgh commented Mar 17, 2022

Maybe a bit cumbersome but how about a Cargo.toml reading API that is utilized through a GitHub Action which creates the actual badge file. For the latter and commiting it into a badge branch https://github.com/marketplace/actions/badge-action can be used

@Feliix42
Copy link
Member

Thanks for your suggestion! 🚀
I just want to make sure I understand this correctly: So you mean that the repository in question would trigger a Github Action flow that calls deps.rs via an API that somehow submits the Cargo.toml file as parameter and then creates the badge?

Theoretically The general concept sounds like a cool idea!
But a potential problem there is that the information displayed on the badge itself would be outdated at some point. If the project is no longer updated, the badge will in a few months still say "up to date", which is not true and will therefore somehow miss the purpose of the project.

Also, that solution would only work for private Github repositories, but not for your own git servers. So that approach might still require a step or two to become a workable solution 🤔

@gitmalong
Copy link

gitmalong commented Apr 24, 2022

How about that:

  1. Provide a deps.rs executable via Docker that takes Cargo.toml files as input and then generates a deps.rs page. By including a tiny bit of javascript the site can tell if the overall report is up to date.
  2. GitHub action to feed the Docker container with Cargo.toml files and to commit the generated website to the repo. Ideally only the json report is being commited in case the page is already there.
  3. The generated website is published via GitHub pages.

That way end users can run the action once a day to get accurate reports. If the website is not being refreshed there should be a overall warning next to the outdated projects.

nitn3lav added a commit to nitn3lav/deps.rs that referenced this issue Aug 17, 2022
deps.rs is now available for self-hosted Gitea at
`/repo/gitea/<DOMAIN>/owner/repo`, e. g.
`/repo/gitea/git.example.org/deps-rs/deps.rs`,
`/repo/gitea/git.example.org:1234/deps-rs/deps.rs`,
`/repo/gitea/http://unsafe-gitea.org/deps-rs/deps.rs`.

This _should_ also include support for Gitea hosted in subdirectories,
e. g. `www.example.org/gitea`, though I haven't tested this yet.

If no protocol (`https://`/`http://`) is specified, `https://` is
automatically added to the beginning of the gitea server's URL.
However I could also change this to only accept https. Another
option might be the use of URL-encoding.
I am open for feedback, feel free to suggest changes.

Implementation notes:

- The Router now matches `/repo/*site/:qual/:name` instead of
  `/repo/:site/:qual/:name` to allow for an arbitrary number of
  `/`s before qual and name.
- `RepoSite` now has a new variant `Gitea(GiteaDomain)`.
- `RepoSite` no longer implements `Copy`. However this should not
  be problematic because `Copy`ing was only used for `to_base_uri`,
  `to_usercontent_base_uri` and `to_usercontent_repo_suffix` which
  now accept `&self` references.
- `RepoSite` no longer implements `AsRef` and now uses `Display`
  instead.

- updated test `correct_raw_url_generation`
- updated readme

Related to deps-rs#84, deps-rs#141
Feliix42 pushed a commit that referenced this issue Aug 21, 2022
deps.rs is now available for self-hosted Gitea at
`/repo/gitea/<DOMAIN>/owner/repo`, e. g.
`/repo/gitea/git.example.org/deps-rs/deps.rs`,
`/repo/gitea/git.example.org:1234/deps-rs/deps.rs`,
`/repo/gitea/http://unsafe-gitea.org/deps-rs/deps.rs`.

This _should_ also include support for Gitea hosted in subdirectories,
e. g. `www.example.org/gitea`, though I haven't tested this yet.

If no protocol (`https://`/`http://`) is specified, `https://` is
automatically added to the beginning of the gitea server's URL.
However I could also change this to only accept https. Another
option might be the use of URL-encoding.
I am open for feedback, feel free to suggest changes.

Implementation notes:

- The Router now matches `/repo/*site/:qual/:name` instead of
  `/repo/:site/:qual/:name` to allow for an arbitrary number of
  `/`s before qual and name.
- `RepoSite` now has a new variant `Gitea(GiteaDomain)`.
- `RepoSite` no longer implements `Copy`. However this should not
  be problematic because `Copy`ing was only used for `to_base_uri`,
  `to_usercontent_base_uri` and `to_usercontent_repo_suffix` which
  now accept `&self` references.
- `RepoSite` no longer implements `AsRef` and now uses `Display`
  instead.

- updated test `correct_raw_url_generation`
- updated readme

Related to #84, #141
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants