CI workflow ensures directories are writable before environment cleanup.

[eap]

A change in #1270 uncovered a behavior where go mod derived package install modules cannot be removed from our scratch directory due to undesirable folder permissions. This has been observed before and golang maintainers marked the behavior as WAI suggesting that people maintain these directory trees with go-language tools. In our case this is not highly feasible due to spack's intervention in the project structure meaning we must find a workaround.

The workaround here uses find to update directory permissions to ensure that write/execute is set on all directories in the tree. This has been tested locally but due to environment carryover we cannot ensure it has the desired effect for go packages in our CI system until it is submitted. (Ie; testing would require re-running an affected workflow and all other pull requests would still be subject to the issue and would break).

Testing

CI tests here will exercise the code and ensure it doesn't break our existing environment.

Issues addressed.

Bugfix for regression noted in #1270

[climbfuji]

Not just directories, but also files. Can you add

find ./* -type f -exec chmod u+w {} \;

please?

[eap]

@climbfuji - In testing, fixing the directory permission was adequate to allow the files to be deleted even with the read-only 444 permission on files. I also tested the full approach using a local go mod build tree and was able to clear the contents.

Works in osX and linux.

# Create directory and file both with `-r--r--r--` permission.
$ cd /tmp
$ mkdir not_deletable
$ echo "deletethis" > ./not_deletable/deleteme
$ chmod 444 not_deletable/deleteme
$ chmod 444 ./not_deletable

# Cannot delete this directory or contents.
$ rm -rf ./not_deletable
rm: cannot remove './not_deletable/deleteme': Permission denied

# Change directory only, it can be deleted.
$ chmod u+wx ./not_deletable
$ rm -rf ./not_deletable

[climbfuji]

Alright, if that's the case then let's go ahead and merge w/o further CI testing. We can always come back if we need to.