Add coin gecko pro API usage for the governor

[mdulin2]

In case the Guardians want to use API keys for Coin Gecko, support for the API keys has been added. This changes code in the Guardian and adds a command line flag.

Testing this is difficult because we don't want to include a key in here. Prior to this, I don't think we had tests for the query success from CoinGecko anyway. So, I added tests that make requests to coin gecko using the standard and pro APIs. If the API key isn't specified in the test file, the test is just skipped. If there's a better way to do this or relying on external APIs for builds to succeed is bad practice, then please say something and I'm happy to make changes accordingly.

[mdulin2]

Failing tests have been fixed. I'm unsure why tilt is failing though.

[mdulin2]

Once John's changes for cancel flow are approved at #4016 I'll have to fix a few locations since it touches similar code.

[djb15]

Not sure if this is the best way to do it, but for the Pro API test we could load a string from an environment variable? That way we could add a key as a secret in GitHub and load it in the Action

[mdulin2]

Not sure if this is the best way to do it, but for the Pro API test we could load a string from an environment variable? That way we could add a key as a secret in GitHub and load it in the Action

Good thought! I wasn't sure if testing this small feature was worth the pain of doing something like that. What do you think?

Also, it depends on whether we can even connect to the Internet during our tests.

[evan-gray]

Not sure if this is the best way to do it, but for the Pro API test we could load a string from an environment variable? That way we could add a key as a secret in GitHub and load it in the Action

@djb15 - I saw this comment and wanted to note that I don’t believe secrets for this repo would be available to PRs from forks, so I would not rely on that approach. https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow

It may be better to simply give reviewers a “hack” script or the like to prove the updated fetching logic does indeed work with and without an API key and have the unit tests ensure that URL is formatted appropriately.

[djb15]

@djb15 - I saw this comment and wanted to note that I don’t believe secrets for this repo would be available to PRs from forks, so I would not rely on that approach. https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow

It may be better to simply give reviewers a “hack” script or the like to prove the updated fetching logic does indeed work with and without an API key and have the unit tests ensure that URL is formatted appropriately.

Ah thanks, yeah that's not an option then. Anyhow I think the approach we're going for with this now is to avoid adding an internet dependency here in these unit tests: #4025 (comment)

[evan-gray]

converting to draft while this has conflicts

[mdulin2]

I accidentally added a test CoinGecko API key in the last commit. I deleted the key from the PR and revoked the key from my coin gecko account.

[SEJeff]

Nice