Dependabot environment variables #4660
Comments
|
I would like this feature as well. The local paths in our dependency files are relative to the top level folder and not the project folder. Dependabot assumes the paths are relative to the project folder so it cannot follow dependencies. We can solve this issue because Python pip |
|
As another point: we're hitting an issue where Dependabot can't correctly handle a Rust dependency via Cargo's Git implementation. We need to be able to set this: https://doc.rust-lang.org/cargo/reference/config.html#netgit-fetch-with-cli , but can't due to missing environment variables for Dependabot. |
|
In my case, I'd like to grant access to some of our ENV variables that are already set in the GitHub repo, that would be even better than duplicating those for Dependabot specifically. |
|
I found this article: https://danielabaron.me/blog/dependabot-secrets/#dependabot-secrets And on my repo, I can set Dependabot secrets at https://github.com/UnlyEd/github-action-deploy-on-vercel/settings/secrets/dependabot @trent-abc I believe this might solve your issue. |
|
Related: Although that one could also be solved by allowing passing in composer-specific config, or changing how we clone. |
This removes explicitly catching errors about missing env vars. This is likely a bit controversial, so here's my thinking: 1. Dependabot at GitHub doesn't support injecting custom env vars. And for security reasons is unlikey to anytime soon: #4660 2. The primary use case was for `ACF Pro`, but that is no longer relevant since they now support private `composer` auth natively: #2001 (comment) 3. In general we've told users that if they need custom env vars for authentication reasons, they should instead ask their upstream providers to use the standard `composer` tooling, rather than a workaround. We aren't going to go out of our way to support non-standard tooling practices. 4. Setting env vars is still relevant for anyone who runs Dependabot standalone, but those are typically power users who are very comfortable debugging / reading the logs to realize the error is the lack of an env var. 5. Technically this could cause more internal alerts because removing this error changes those updates from being seen as "well-known user errors" to "unknown service errors" (which we internally alert on). However, I strongly suspect that very few users actually hit this problem... so if just a couple of repos are hitting it, that shouldn't be unduly affecting our metrics. 6. Currently unknown `composer` errors are hidden, but we should resolve that with a systemic solution rather than one-off-solutions for specific packages, which turns into a game of whack-a-mole: #6290 7. Composer error handling is a big mess in our code... it's copy/pasted several places, with `TODO` notes saying we should refactor/cleanup our error handling code. And we don't even know what's still relevant once we drop `composer` `1` as the error messages changed a bit. So any cleanup / simplification we can do of the error handling code makes our future refactoring easier. If we needed this generic error for other ecosystems, that'd make sense, but so far it's `composer` specific so until we need that, let's just remove it.
|
Any status on this? Currently we are limited in our usage of Dependabot as it doesn't support |
I would like to specify an environment variable during dependabot runs.
I'm attempting to authenticate against a private cloudsmith python repository. I arrived at a working configuration here. However, this working configuration means my Pipfile looks like so:
While this works for dependabot given the yml in the aforementioned ticket, it doesn't work for local development. For local development our pipfile looks like so:
So if I'm just able to set the environment variable ${CLOUDSMITH_KEY} to "basic" my problem is solved.
Unfortunately it's unsupported:
Is there another way around this, or am I missing something? I would have thought setting some environment variables was a common use-case.
The text was updated successfully, but these errors were encountered: