Kyle Brown suggested I open this Jira based on:  https://access.redhat.com/support/cases/#/case/02680171

We have three projects, skopeo, buildah, and podman on GitHub.com and have set up  4 repos for each on quay.io:  quay.io/containers/{project}, quay.io/{project}/stable, quay.io/{project}/upstream, and quay.io/{project}/testing.

The {project}/stable and the containers/{project} repos are essentially the same.  It is a container image of the project using the latest Fedora and the latest shipping stable version of the project that is in bohdi.  They use the same Dockerfile to build from within the projects GitHub repository.

The upstream container image uses the latest Fedora and includes the latest bits from the upstream project on GitHub.  The testing container image uses the latest Fedora and has the latest version of the project that is in testing status in bohdi.  These two repos each have their own distinct Dockerfile.

We've set up build triggers in the quay.io console for each of these repos such that each one rebuilds the image whenever a PR is merged into the master branch.  The thinking was we would then have the most up to date version of the image when ever something merged.

We just created the repos for Skopeo recently and created its stable image.  When pulled with this command:  'podman run quay.io/skopeo/stable:latest -v' it showed a value of 'v0.1.42-dev'.  Even more recently we created a new version of Skopeo bumping the version to 'v1.0.0'.  When we pulled the image, we expected to see 'v1.0.0', but instead got the older version.  I verified that the build triggers had run and then also ran them manually.  Still the same version.

After digging through the build logs, I discovered that the builds were using the caches from the older image entirely.  In fact, the date stamp for the image was the same as it was prior.  Other than having gone through a build process, there was no difference in the image.  For the skopeo/stable image, I removed the latest and master tags and ran the build trigger again for the image.  This time the cache was not used and the Skopeo version within the container image was indeed 'v1.0.0' and we had a new image.

Kyle suggested that we edit our Dockerfile when we want to rebuild completely.  As our Dockerfiles are part of our GitHub repo for each project, training our contributors to make a small edit in each of the three Dockerfiles with each PR is not practical.  Nor do I want to create a PR everyday for the three projects to touch up the Dockerfiles to force a build.

What we're requesting is a way to trigger a build that doesn't use the cache.  I understand the caching keeps the loads down, so perhaps that could be a paid option.   Without that option, the build trigger functionality is not practical for us.

In addition, it would also be nice if the build trigger functionality allowed you to schedule a build for a certain time a day.  If you wanted to restrict the "no-cache" builds to only these scheduled triggers and allow only one build a day,  that would suit our purposes.