You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 25, 2024. It is now read-only.
One of the original goals of the project was to allow every repository that uses pitgull to have a customizable config for it. Dhall was picked as the format, one of the reasons being that it supports remote imports.
With that in mind, the approximate setup could look like this: one would have a single repository with a shared config, and multiple other repositories could import from that, like in example.dhall:
let pg =
https://raw.githubusercontent.com/pitgull/pitgull/v0.0.2/dhall/pitgull.dhall sha256:65a46e78c2d4aac7cd3afeb1fa209ed244dc60644634a9cfc61800ea3417ea9b
let wms =
https://gitlab.com/kubukoz/demo/-/raw/db4686f29bab1bc056ec96307a39aa3dd6337173/wms.dhall sha256:4b9218b9a1a83262550b9bdfa7d7250f4aa365b8d8c2131f65517ef5f3eeb68c
in pg.projectToJson { rules = [ wms.scalaSteward ] }
Here, we have an import of the pitgull "standard library" and a shared config.
One obstacle here is authentication - to resolve the shared import, we might need to authenticate to the GitLab instance being used.
While we do have a token that should allow doing this, it is not clear whether we can make the dhall resolver (dhall-json in our case, until #116 is possible - in dhallj we could have a custom http4s client that will attach the header in the worst case) forward it in the appropriate header.
Note that we will need to fetch the base config file using the GitLab API - so we don't need to do anything more complex than the existing implementations of API calls do.
One of the original goals of the project was to allow every repository that uses pitgull to have a customizable config for it. Dhall was picked as the format, one of the reasons being that it supports remote imports.
With that in mind, the approximate setup could look like this: one would have a single repository with a shared config, and multiple other repositories could import from that, like in
example.dhall
:Here, we have an import of the pitgull "standard library" and a shared config.
One obstacle here is authentication - to resolve the shared import, we might need to authenticate to the GitLab instance being used.
While we do have a token that should allow doing this, it is not clear whether we can make the dhall resolver (
dhall-json
in our case, until #116 is possible - in dhallj we could have a custom http4s client that will attach the header in the worst case) forward it in the appropriate header.Note that we will need to fetch the base config file using the GitLab API - so we don't need to do anything more complex than the existing implementations of API calls do.
Hopefully, once we have that fetched (as a byte stream should be enough), we can pass it as input to
dhall-json
executed with the appropriate environment variable, which can then be forwarded with theusing
clause of an import: https://docs.dhall-lang.org/references/Built-in-types.html?highlight=headers#keyword-usingThe text was updated successfully, but these errors were encountered: