Add add workflow hook examples for build-and-push workflow#32
Merged
Conversation
grahamalama
commented
Oct 16, 2025
dlactin
reviewed
Oct 16, 2025
Co-authored-by: Dustin Lactin <dlactin@mozilla.com>
b729efe to
857a150
Compare
9902eac to
92e9c4d
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In this PR, we're starting to experiment with what kinds of patterns we want to suggest or standardize as a part of the paved path for building and publishing Docker containers. These are the aspects that we'll want to highlight and provide documentation for in Confluence:
adding a
HEALTHCHECKinstruction to the Dockerfileadding a
Makefilewith these targets that we expect thebuild-and-pushworkflow to call:make mozcloud-prebuildmake mozcloud-postbuildthe kinds of checks and tasks to run in these
{pre,post}buildcommandsprebuildwill look pretty similar in most services, and that's something we can provide as a sensible defaultpostbuildwill most likely be more unique to each service. We can highlight important aspects of what to run in this step, thoughThis PR uses
docker composeas the way we build containers and run tests. This is because many teams use both Make and Docker Compose to orchestrate local development tasks like building and running tests. Though we'll still want teams to eventually use our actions since they'll offer an easy way to build containers the right way (proper tagging, build attestations, etc), we still want to offer suggestions on how to make local workflows the most compatible with our actions and reusable CI workflows.