Base._ls(): may always return an empty list

[frankenjoe]

So far the docstring of Base._ls() was saying:

        If ``path`` is ``'/'`` and no files exist on the repository,
        an empty list should be returned
        Otherwise,
        if ``path`` does not exist or no files are found under ``path``,
        an error should be raised.

This might be overlooked by a developer, so here we simplify _ls() by not demanding to raise an error message or treat / as a special case. Instead it is sufficient to return an empty list, even in the case that the path does not exist. The docstring now says:

        If ``path`` does not exist
        an empty list can be returned.

To avoid a breaking change, raising a file-not-found-error is now handled by Base, in the same way we already do it for the case that path is not a sub-path.

[frankenjoe]

@hagenw locally tests with Artifactory are passing, but here it seems that it can no longer access the server. Any idea?

[hagenw]

There is a different when running locally or here in the CI as the CI uses the audeering-unittest user, whereas we locally use our user names. But all of those users have exactly the same rights in the Artifactory server.

The error message of the failing test was:

E           dohq_artifactory.exception.ArtifactoryException: This request is blocked due to recurrent login failures, please try again in 7 seconds

My suspicision is that every time we try to access a file that does not exist it will be counted as a login failure. And as we have several CI jobs running in parallel, it might be that we reach the blocking threshold too early. To me it does not sound like a good design on the Artifactory side that a user gets block even she/he has a correct username/password login.

I guess we need to check if there is a setting on the Artifactory server to change the behavior. If not, we might have to reduce the number of pipelines. Or group tests for error messages on missing data in a separate file and run this file only in a single CI job.

[hagenw]

Maybe there is also an error with the stored secret on Github. I will try to replace it with a new one.

[frankenjoe]

But isn't it strange we only encounter this problem now?

[frankenjoe]

Maybe there is also an error with the stored secret on Github. I will try to replace it with a new one.

Ok, thanks.

[hagenw]

But isn't it strange we only encounter this problem now?

I also encountered the problem when I tried to add tests for non-existing and private repositories in audeering/audb#339

[hagenw]

I replaced the secret on Github and re-started the CI jobs, but unfortunately the error stays the same.

[hagenw]

It seems to be common that secrets are replaced by "***" in the output of CI jobs. Here is the output of an older passing one:

[hagenw]

I tested a few more things and the username and API key seem still to be correctly set, but the error remains in the end:

E           dohq_artifactory.exception.ArtifactoryException: This request is blocked due to recurrent login failures, please try again in 13 seconds

Maybe we wait until next week to see if the error remains?

[frankenjoe]

Maybe we wait until next week to see if the error remains?

ok

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (65c6844) 100.0% compared to head (fa10a86) 100.0%.

❗ Current head fa10a86 differs from pull request most recent head 22ab9e4. Consider uploading reports for the commit 22ab9e4 to get more accurate results

Additional details and impacted files

Files	Coverage Δ
audbackend/core/backend/artifactory.py	100.0% <100.0%> (ø)
audbackend/core/backend/base.py	100.0% <100.0%> (ø)
audbackend/core/backend/filesystem.py	100.0% <100.0%> (ø)

[hagenw]

As usual, waiting a few days helps to solve login issues.