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

GitHub provider env var namespace conflict #331

Open
pchinjr opened this issue Oct 24, 2024 · 4 comments
Open

GitHub provider env var namespace conflict #331

pchinjr opened this issue Oct 24, 2024 · 4 comments

Comments

@pchinjr
Copy link

pchinjr commented Oct 24, 2024

yolo, GITHUB_ is a reserved namespace in GitHub and is required by kv-oauth, my current work around is using Deno Deploy and setting the environment variable in the Deploy web console. The result is that every time GH Actions run, it will fail, but Deno Deploy is able to build and deploy successfully. This limits extending the Actions pipeline and splits the CI/CD management. Could the default env var be changed to GH_ to avoid this conflict?

clientId: getRequiredEnv("GITHUB_CLIENT_ID"),

@iuioiua
Copy link
Contributor

iuioiua commented Oct 31, 2024

SGTM. This would be a breaking change though.

@honmanyau
Copy link

honmanyau commented Nov 15, 2024

@pchinjr, out of curiosity, where did you have your GITHUB_* environment variables set before you added them through the Deno Deploy web UI? I didn't exactly see a conflict with GitHub Actions but it seems like what I encountered may be related.

I started out having them already set through the web UI but GitHub Actions were failing and just completely blocked the pipeline. For context, mine is a Deno 2/Fresh project using deno-kv-oauth 0.11.0, deployment was set up automatically by Deno Deploy.

I'm new to this and may be missing something, but after testing a bit, as well as with the workaround above, it looks like:

  • The environment variables set through the web UI are only available during run time but not at build time.
  • CLI environment variables set through the build task are only available during build time but not at run time.

My current setup for a Deno Deploy project:

  1. Include GITHUB_CLIENT_ID and GITHUB_CLIENT_SECRET as empty strings in my build task (in deno.json).

    {
        "tasks": {
            "build": "GITHUB_CLIENT_ID='' GITHUB_CLIENT_SECRET='' deno run -A --unstable-kv dev.ts build"
        }
    }
  2. Add the environment variables to the project's settings in Deno Deploy.

For the reasons above, I'm inclined to think that we don't really need them during build time if there is a way to detect that.

@pchinjr
Copy link
Author

pchinjr commented Nov 15, 2024

@honmanyau I used a local .env file during development. You are correct that the build process will compile with an empty string, but will throw for undefined. The issue is that Deno Deploy uses GitHub Actions, and the namespace collision is an unfortunate side effect of each platform requiring a naming convention at the global scope of the application environment. As scale and complexity grows, this O-Auth utility will need to handle multiple environments for testing, staging, and production. In production, I would use an authenticated secrets manager that is called by the build service to dynamically set environment variables. Currently, kv-oauth causes a separate pipeline and passing empty strings to GitHub Actions just to compile is not optimal.

@iuioiua I know you're not maintaining this anymore, but do you have advice for these solutions:

  1. Allow GH Actions to pass with empty strings set by the Deno CLI, while adding the real values to the Deno Deploy Web UI
  2. Change the underlying clientId check to a new convention
  3. Introduce userland environment variable declaration at runtime

1 feels kind of hacky to pass the clientId check
2 is a breaking change, and moves the naming convention to the library
3 adds complexity to the setup but could be implemented as a new map for all current and future provider paths

Thanks everyone, appreciate the discussion and collaboration. Cheers & Peace 🖖

@honmanyau
Copy link

@pchinjr Thank you so much for taking the time to respond and give additional details + suggestions!

I'd thought that I hadn't seen the namespace collision because my setup was different (I only saw undefined error), but I see what you mean after trying to add the same environment variables to GitHub Actions through the browser UI now.

  1. Allow GH Actions to pass with empty strings set by the Deno CLI, while adding the real values to the Deno Deploy Web UI.

Just wanted to quickly note that GitHub Actions are currently passing for me with that workaround. I absolutely agree that the it's super hacky far from ideal.

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

No branches or pull requests

3 participants