Do not fail cache key computation in case of no 'pip-dependency-file'

[zigarn]

It was not failing the build but failing the use of cache.

Before this patch: https://app.circleci.com/pipelines/github/CircleCI-Public/python-orb/339/workflows/fa79d98d-a100-4955-885a-47f70dfd5cb0/jobs/1434

[dsayling]

LGTM - @KyleTryon should be a patch release

[clementlecorre]

@KyleTryon @zigarn I have exactly the same problem. Can we merge the fix?

[zigarn]

@clementlecorre Looks like this is not relevant anymore with latest version 2.0.0 released yesterday.

[clementlecorre]

I'm in version 2.0.0, but I have a similar bug....

error computing cache key: template: cacheKey:1:32: executing "cacheKey" at <checksum "/tmp/cci_pycache/lockfile">: error calling checksum: open /tmp/cci_pycache/lockfile: no such file or directory

I use the same command as the example, maybe it's also a configuration problem on my side

[zigarn]

You got a new bug from new code...

What's the output of previous step "Link lockfile"?

[clementlecorre]

Step "Link lockfile" ✅

INFO: Linking ./Pipfile.lock to /tmp/cci_pycache/lockfile
CircleCI received exit code 0

To be more precise I have the error on the cache (step: "Restoring cache" ❌ ) (I quoted above), it is not blocking for the continuation.

Then I have an error on the step "Copy to cache directory" ❌

ln: failed to create hard link '/tmp/cci_pycache/lockfile': File exists

Exited with code exit status 1
CircleCI received exit code 1

[zigarn]

It's clearly a bug with the new code, better to fill an issue about this. (a quick and dirty fix would be to add -f in

python-orb/src/scripts/cache-link-lockfile.sh

Line 29 in 349f0de

ln -s "${LOCK_FILE}" "${LOCKFILE_PATH}"

But would be better to investigate as it's weird to try to create this lock link multiple times. Unless you use this job multiple time?

[clementlecorre]

I use the step only once.

🎉 I think the bug comes from the "Copy to cache directory" step. I think the unlink is not working properly.

python-orb/src/scripts/cache-save.sh

Lines 66 to 68 in 349f0de

	if [ -f "${LOCKFILE_PATH}" ]; then
	unlink "${LOCKFILE_PATH}"
	fi

circleci@ID:~/project$ ls -lah /tmp/cci_pycache/lockfile
lrwxrwxrwx 1 circleci circleci 14 Feb  9 14:23 /tmp/cci_pycache/lockfile -> ./Pipfile.lock
circleci@ID:~/project$ if [ -f "/tmp/cci_pycache/lockfile" ]; then echo "do unlink"; fi
circleci@ID:~/project$ ls -lah /tmp/cci_pycache/lockfile
lrwxrwxrwx 1 circleci circleci 14 Feb  9 14:23 /tmp/cci_pycache/lockfile -> ./Pipfile.lock
circleci@ID:~/project$ if [ -L "/tmp/cci_pycache/lockfile" ]; then echo "do unlink"; fi
do unlink

Helpers:

-f FILE
FILE exists and is a regular file
-L FILE
FILE exists and is a symbolic link (same as -h)

[Jaryt]

@clementlecorre Looks like this is not relevant anymore with latest version 2.0.0 released yesterday.

I was hoping to address this PR with these changes, but to my dismay this issue has cropped up. Will track this on the open PR #89