GitHub Actions Configuration

[scottyhq]

The GitHub Actions in the repository are fairly complex, mainly stemming from the fact that we want to add environment lock files from any PR. But PRs coming from forks only have read access by default, which is why we use our pangeo-bot user access token and /slash commands to have write access.

I recently learned a lot from this blog post https://securitylab.github.com/research/github-actions-preventing-pwn-requests/ on best practices for structuring this style of CI. Likely could make some modifications and improvements to how things are currently structured.

[scottyhq]

Could also utilize some newer github actions, such as:

1. Docker images with Buildx
   https://github.com/docker/build-push-action

2. Or as a Docker alternative build and push with podman to quay.io
   https://github.com/redhat-actions/push-to-registry

[scottyhq]

copying some discussion from #282

The miniforge version is currently specified in a couple places, because of how we generate a lockfile for every PR via github actions.

pangeo-docker-images/.github/workflows/CondaLock.yml

Lines 37 to 44 in 9b282f5

	- name: Setup Conda Environment with Miniforge
	uses: conda-incubator/setup-miniconda@v2
	with:
	# Match base-image/Dockerfile version
	miniforge-version: 4.10.3-7
	environment-file: environment-condalock.yml
	activate-environment: condalock
	use-only-tar-bz2: true # IMPORTANT: This needs to be set for caching to work properly!

I think a better strategy going forward might be to install conda-lock in the base image Dockerfile and then actually run conda-lock via that Docker image. That way, conda, mamba, and conda-lock versions will be consistent throughout this repository...