How Triggered Updates Work
Gwenn Berry avatar
Written by Gwenn Berry
Updated over a week ago

Anatomy of a Triggered Update

  1. Miqa receives a notification of a new version of a component artifact. This includes at least the artifact location (e.g. Docker URI for Docker artifacts), and if coming from a CI/source control integration, will also include commit metadata. If using triggered tests, it will also include the trigger ID for which test to kick off.

  2. Miqa increments the corresponding pipeline(s) and links the new versions to the supplied commit metadata.

  3. If using triggered tests, Miqa kicks off the tests and performs all configured downstream checks and notifications.

  4. The new version of the pipeline is now available for ad hoc use and/or batch-analysis.

Note: Unlike manual component versioning, automatic updates (via triggers or docker feeds) require that you register your docker repository or artifact source against the component ahead of time.

FAQs

What if I pass the same artifact twice?

If the source-control-identifying information and target pipeline match a linked pipeline artifact we already have, we will not create a new version and will instead use the existing matching version to execute triggered tests.

If you pass the same artifact with different source-control-identifying information (for example, if you push a new commit but do not rebuild the docker image or reference a static tag, e.g. "latest"), we will reference the same image but link it to the new commit and increment the pipeline version.

Why do we need to pre-register docker repos if we are including the full docker URI in triggers?

Because Miqa allows multi-step pipelines (which may be fed by changes to multiple different source control repositories or docker feeds), we cannot automatically assume that the URI passed in the trigger should be applied to all pipeline steps. When we receive a trigger or build notification, the root of the URI is checked against the docker repositories linked to each step of your pipeline. If it matches, that step is correspondingly updated.

For more information on pre-registering docker repositories, see the article here.

Can I point a component to a docker URI without registering the corresponding repo against it?

Yes. Components can still point to any (accessible) docker URI, regardless of whether the repo is registered. Repo registering is only required for pipeline automation triggers.

Can I register multiple docker repos or artifact sources against a single component or pipeline?

Yes. Multiple repositories can be registered to the same pipeline, so that updates to any of them will trigger new versions in Miqa. The repositories can also be individually configured, so that

Can the same docker repo or artifact source be registered against multiple components or pipelines?

Yes. Each component/pipeline controls the automation and triggering behavior individually.

What if the same component is used twice in a pipeline?

Updates to a component that are used multiple times within a pipeline will be applied to all matching pipeline steps. At this time, we do not support separately versioning duplicate pipeline steps from triggered builds.

What if I pass an artifact that does not match to my pipeline?

If the artifact source (e.g. docker repo) is not found to match to any existing components, or a trigger is passed without an artifact, the pipeline components will not be incremented. However, you may still optionally increment the entire pipeline version (and/or kick off tests) while keeping the underlying components the same.

AS OF APRIL 6, 2022, triggers that are sent with URIs that do not match pre-registered repos will automatically fail instead of triggering a pipeline increment and/or tests. Triggers without artifacts will still trigger an increment and/or tests.

Did this answer your question?