Unreachable pyup.io leads to failing `pipenv check`

I’m working on a project which has been running a lot of pipenv checks (possibly on the order of hundreds of requests per day). I think we’ve been throttled at the network level, because this command now results in messages like this:

Connection to pyup.io timed out. (connect timeout=5)

curl pyup.io can’t reach the site, but torify curl pyup.io (that is, via a proxy) works, and dig pyup.io returns the same IP as SSL Labs detects, so it’s definitely restricted to somewhere between this network and that site.

I’ve changed our process to run pipenv check much less often, but would it be possible to detect or avoid this issue in pipenv? Ideas:

• Configuring our own API key so we can reliably stay below any limits.
• Suggesting solutions when the connection times out.
• Configurable caching of the security issues database. I realize this is probably a very risky move since security issues may have to be fixed within hours, but it could be useful for people who for process reasons end up running a lot of checks.

PS: The recommended forum for these requests returns HTTP 404.

[leotrubach]

Hmm… I couldn’t really figure out what’s wrong. But when running pipenv check it fails but safety check succeeds

[mcallaghan-bsm]

As a workaround this one could be used:

pipenv check || if [ $(curl --write-out %{http_code} --silent --output /dev/null pyup.io) -eq 500 ]; then echo "Site unreachable. Skipping check"; else false; fi

Is this really a good workaround? You don’t want your pipeline security checks “false passing”.

(of note, our workaround is that we have our CI jobs “allow fail = true” which converts the gitlab job into a WARNING instead, therefore not blocking the entirety of the pipeline – this way the TRUTH is reported still, but does not block development during outages)