We are thoroughly enjoying using Dopper, so thank you!
The docs already cover using the Doppler CLI in CI jobs, but sometimes this is not possible. It would be perfect if Doppler could sync with GitLab’s built-in CI/CD variable section. (GitLab CI/CD variables | GitLab).
They have an API for this; Project-level CI/CD variables API | GitLab
Less important, but there are also group level variables that would be handy to sync.
I envisage this working exactly like the GitHub Actions sync, but for gitlab dot com and self-hosted instances.
@bert We don’t currently have any firm plans for supporting self-managed instances, although the idea has been discussed internally. In cases like that, is the only difference the API hostname being hit? Or are there any other differences in how the API works with the self-hosted installations?
Regarding the Ultimate Plan, that used to be a requirement to use API personal access tokens. It looks like they changed that since we initially implemented this:
Actually, it looks like that was specific to the personal access token management API endpoints. I talked with our engineering team some more and I think that doc requirement was noted due to requirements around project access tokens. That said, with our integration, you likely wouldn’t be using a project access token since it would limit the integration connection to a single project (preventing you from choosing from a list of your projects when creating syncs). Either way, it’s not a requirement, so we’ll keep it out of the docs!
Also, as a follow-up to the self-hosted ask – one of our assumptions when not adding support for it was that most likely people setting up self-hosted installations would have those installations behind a VPN, Cloudflare Access, Google IAP, or similar, which would prevent us from sending API requests to it. Maybe that assumption is wrong here? How do you typically handle inbound requests from third parties like this?
