Owner: Architect:

Martin Mulholland

Story (Required)

As an Primaza user I want primazactl to use released manifest from primaza.

Background (Required)

primazactl consumes manifest file created by primaza

Glossary

<List of new terms and definition used in this story>

Out of scope

<Defines what is not included in this story>

In Scope

Primazactl and primaza release processes

Approach(Required)

A few changes needed:

• primazactl, when the -version flag is used it should consume manifest from a primaza release. 
• when a primazactl release is created:

• •  the tests should use the manifest from primaza of the same version.
  •  primazactl binary should, by default, uses the manifest from the same primaza version. 
• a primaza nightly release is created using the release name "dev"
• a primazactl nightly build should consume the manifest of a primaza nightly build 
• the primazactl make system should be modified to download manifest from the primaza nightly release and not clone the primaza repo to create the manifests. 
• The primaza release should, after the release is created, trigger a build in primazactl which creates a matching primazactl release.
  • see: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#repository_dispatch 

Demo requirements(Required)

_<Description of demo which would show the value of this story. Any demo
should also be included as part of the acceptance criteria.>_

Dependencies

_<Describes what this story depends on. Dependent Stories and EPICs should
be linked to the story.>_

Edge Case

_<Describe edge cases to consider when implementing the story and defining
tests>_

Acceptance Criteria

_<Provides a required and minimum list of acceptance tests for this story.
More is expected as the engineer implements this story>_

Development:

Nightly releases available in primaza and primazactl repository

Primazactl release for 0.1.0

QE:
Documentation: Yes/No (needs-docs|upstream-docs / no-doc)

Upstream: <Inputs/Requirement details: Concept/Procedure>/ Not
Applicable

Downstream: <Inputs/Requirement details: Concept/Procedure>/ Not
Applicable

Release Notes Type: <New Feature/Enhancement/Known Issue/Bug
fix/Breaking change/Deprecated Functionality/Technology Preview>

INVEST Checklist

Dependencies identified

Blockers noted and expected delivery timelines set

Design is implementable

Acceptance criteria agreed upon

Story estimated

v

Legend

Unknown

Verified

Unsatisfied