Add an environment variable to .env.example for an Alchemy API key and use it hardhat config

[danceratopz]

Allow the user to configure an API key for an Alchemy endpoint (ALCHEMY_POLYGON_API_KEY) in .env.example and use it in the project's hardhat configuration when forking Polygon for test.

Currently the key is hard-coded in hardhat.config.ts.

[danceratopz]

I think I've understood the problem: The API is hard-coded to allow correct execution of a Github Action workflow in this repo that was triggered by a push to branch with PR in a forked repo?

1. If a user has forked the main repo and enabled the original repo's Github actions for the fork (not enabled by default), they don't have access to the Github secrets from the main repo when Github actions on their forked repo? This makes sense and I'm guessing this is not your issue.

2. Same situation, but now the user has created a PR in the original repo for the branch in their fork. Now if a user pushes to their branch in their fork, this triggers a Github action workflow on the branch in the fork in the original repo (i.e., this runs in the context of the original repo and its settings). Here, the problem is, that the Workflow still does not use the Github secrets from the main repo.

I guess 2. is the issue you're having?

The question is, if the user creates their own secrets in the settings of their forked repo, will the Workflow triggered in the original repo run with these settings? This is slightly inconvenient, but at least allow the secrets to be maintained correctly. And most importantly allow the workflow to execute. If not, then I don't see any way to do it cleanly; secrets will need to be declared explicitly, but it seems to make more sense do this CI yml instead of other config files?

Also, if this works, if the user that forks adds their own secrets, they can run the workflow locally before creating the PR - it just needs some documentation what they require.

[mauricedesaxe]

if the user creates their own secrets in the settings of their forked repo, will the Workflow triggered in the original repo run with these settings?

I had this thought too & I remember testing this and it not working, but I may be remembering wrong. I should be trying it again.

[danceratopz]

I was just about to test but then I realized, on second thoughts, this doesn't make sense from a security point of view either. So I really think we're stuck with hardcoded values.

But I think they'd be better off in the CI yml than in hardhat config to stop the key getting clobbered too much. When a user clones, they have to add their own in their .env.

[0xmichalis]

I guess 2. is the issue you're having?

Yes, this is the issue. Fine with hardcoding the API key as part of the CI workflow instead of the hardhat config.

[mauricedesaxe]

So I really think we're stuck with hardcoded values

We are for now.

But I think they'd be better off in the CI yml than in hardhat config to stop the key getting clobbered too much.

I'm not sure it'd help much. Hardcoded still means it's scrapable.