publish-crates: avoid cleaning up the tmp folder on CI

[joao-paulo-parity]

The rm: cannot remove XXX: Directory not empty message is misleading. The error occurs not because the directory has something in it, but because some process is attached to a file within the directory, which makes it so it cannot be removed. See for instance https://stackoverflow.com/questions/64852408/cannot-remove-git-directory-not-empty.

On CI it's not necessary to clean up the temporary folder because it'll be discarded automatically once the job runner exits. The error can still happen for non-CI environments, but I'll punt on handling that for now because the script is not supposed to be run outside of CI (there's a clear warning about that in the comment at the start of the script).

closes #31

[chevdor]

Why not running pkill first and then rm -rf ... || true ?
it would have been more concise and this way we attempt a cleanup and give up if there is a non critical issue.

[joao-paulo-parity]

Why not running pkill first and then rm -rf ... || true ?

fuser is better than kill for this, as mentioned in https://stackoverflow.com/a/64860231/16833094. Or, more crudely, a rm loop up to N retries with sleeps in-between (until the process lets go of the file it's attached to) could also work.

it would have been more concise and this way we attempt a cleanup and give up if there is a non critical issue.

I thought of implementing a workaround, but I stopped myself precisely because it would not be more concise; on the contrary, more code would be added for handling the "problem" - which is actually not a problem because the directory doesn't need to be cleaned up on CI. It seemed sensible to sidestep the procedure rather than add more code for handling what's effectively a non-issue for CI environments.

Indeed, the situation is not solved for non-CI environments. To reiterate:

I'll punt on handling that for now because the script is not supposed to be run locally (there's a clear warning about that in the comment at the start of the script)

Regardless, I've created a ticket for enhancing this part of the script such that it also behaves well on non-CI environments (although I doubt it'll ever be used that way).