build cache for staging

[jimmykarily]

The buildpack tekton task supports the CACHE_IMAGE and "cache workspace" settings to cache builds artifacts so that subsequent pushes are faster. Right now, pushing Rails or Wordpress on Epinio is equally slow every time because we don't use that. We should try to use one of the settings to speed things up.

Acceptance Criteria

• a second push of the same app, uses some caching mechanism from the tekton pipeline
• [optional] there is a way to push without caches and maybe delete the cache altogether
• the cache should be deleted at least when the application is deleted.

[jimmykarily]

I got a branch that proves that CACHE_IMAGE is working: https://github.com/epinio/epinio/tree/688-cache-image

Managing the generated image though, may be tricky: https://betterprogramming.pub/cleanup-your-docker-registry-ef0527673e3a

The various cache images may start taking up too much space in the registry and there is no easy way to inspect what is going on or do some cleanup. It is probably easier to create and use a persistent volume claim as described here:

https://github.com/tektoncd/pipeline/blob/main/docs/workspaces.md#persistentvolumeclaim

We can delete that PVC when the application gets deleted.

[jimmykarily]

I updated the branch to use a PVC as a Tekton workspace for cache instead of CACHE_IMAGE. We already have a Tekton workspace for source and the was a PersistentVolumeTemplate which means a PVC was created automatically by Tekton and was removed when the PipelineRun was deleted. I tried to add an existing PersistentVolumeClaim for the cache (https://github.com/tektoncd/pipeline/blob/main/docs/workspaces.md#using-persistentvolumeclaims-as-volumesource) but this resulted in an error similar to this: tektoncd/pipeline#3480

Then I tried to use the same PVC, both for the source and the cache but that results in another error during staging:

remote origin already exists

I guess that's because it finds the sources already in place (since the existing PVC is not automatically deleted). Not sure what the right solution is yet.

[jimmykarily]

I created a draft PR (#701) but I want to read more on what the limitation is that doesn't allow us to have 2 different PVCs, one for the "source" tekton workspace and one for the "cache". Being different PVCs means we would have the option to create a different PVC for each "upload" when we get to #699 while still using the same "cache" PVC on every build of the same app. Otherwise we would have to handle the various "uploads" as directories on that PVC. That's only if we we want to have more versions of the code around (e.g. keep the old code until the new code successfully stages).