Ignore empty GitHub API keys

[drkrillo]

Description

When COLLECTOSS_GITHUB_API_KEY env variable was set to one or more whitespaces or left empty, that counted as set config_key, causing httpx.LocalProtocolError: Illegal header value b'token '.

Now, in GithubApiKeyHandler.get_api_keys():

• If the key is set to one or more whitespaces or left empty, a warning is logged and the code doesn't add it to the keys list (new cases).
• If its None, the warning is not logged and doesn't add the key (already covered before the fix).

Added tests/test_classes/test_github_api_keys.py covering the config key cases:
empty and whitespaces with and without database keys, None, and a valid key. Each one
asserts the key list, if the key is probed, and the warning.

docker compose up --build logs after the fix:

core-1      | 2026-09-16 23:41:45 097a6abde2c1 collectoss[33] WARNING GitHub API key is an empty string. Please, add a valid one.
core-1      | 2026-09-16 23:41:45 097a6abde2c1 collectoss[33] INFO Retrieved 0 github api keys for use

This PR fixes part of #378

Notes for Reviewers

• The same issue is present in GitlabApiKeyHandler.get_api_keys(). I didn't add that fix here, just GitHub's. Let me know if I can open up a follow-up PR, open an issue (or both) or add the code and tests in this same PR.

Signed commits

• Yes, I signed my commits.

Generative AI disclosure

Please select one option:

• This contribution was NOT assisted or created by Generative AI tools.
• This contribution was assisted or created by Generative AI tools.

If AI tools were used, please provide details below:
- What tools were used? Claude
- How were these tools used? Code review and tests guidance (not writing, suggested new ones covering cases I didn't consider)
- Did you review these outputs before submitting this PR? Yes, all the code was written by me, trying different approaches and Claude was used to review the changes.

[MoralCode]

Thanks for the contribution and welcome to CHAOSS (i see this is your first contribution)! Had some questions about the code

[MoralCode]

hmm i wonder if we could shorten this to

if self.config_key:
(and keep the else block)

AFAIK (needs testing) i think python treats empty strings as falsy

[drkrillo]

I tried this approach before the actual nested implementation. The three cases are pinned in the test file ("", " ", None)

The problem is that if self.config_key: would catch None and "", but " " is not falsy, so it gets added . With a flat else, None logs the warning, which test_none_config_key_with_no_db_keys asserts it shouldn't: None just means the variable was never set.

Also tried if self.config_key.strip(). Catches de whitespace but raises an AttributeError on None.

[MoralCode]

do you think it would it be better to throw a self.config_key = self.config_key.strip() earlier in the process? then it would collapse the whitespace case into the "" case that is already handled with if self.config_key?

[drkrillo]

Yes, probably the besst approach.

I'll add

if self.config_key:
   self.config_key = self.config_key.strip()

right after the key is read with self.config_key = self.get_config_key(). Then, this part can end up as:

if self.config_key:
    keys += [self.config_key]
elif self.config_key is not None: # None just means it was never set
    self.logger.warning("GitHub API key is an empty string. Please, add a valid one.")

That elif for None needs to be there so we don't log a warning for a missing token.

Note: self.config_key is also read to filter the config key out of the database keys, so that comparison now will see the normalized value. I think that's an improvement

[drkrillo]

Done!

[MoralCode]

right after the key is read with self.config_key = self.get_config_key()

would it help to log a warning that we handled unnecessary whitespace in a key in case the admin wants to remove it?

[MoralCode]

The same issue is present in GitlabApiKeyHandler.get_api_keys(). I didn't add that fix here, just GitHub's. Let me know if I can open up a follow-up PR, open an issue (or both) or add the code and tests in this same PR.

id say for this if you update your pr description to say "fixes part of" the referenced issue (break the automatic closure that will otherwise happen when this merges) and then we can have the gitlab version in another PR.