From c7173294bf5d2e72247ed7ca970c12b892a856f8 Mon Sep 17 00:00:00 2001 From: arewm Date: Fri, 12 Apr 2024 08:15:42 -0400 Subject: [PATCH] Change architecture goal from recording in git to provenance Semantic reproducibility should still be an architecture goal, but not all parameters will be reasonable to commit to the git repository. Instead of making this the goal, we should change the goal slightly to require the information to be represented in the provenance and then present in git where possible. This enables some workflows that leverage tekton but not PAC as still within-goal. Signed-off-by: arewm --- architecture/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/architecture/index.md b/architecture/index.md index 4b2401e7..dab2dd1e 100644 --- a/architecture/index.md +++ b/architecture/index.md @@ -19,7 +19,7 @@ AppStudio is a platform for building integrated software that streamlines, conso - Build artifacts once with enough data to determine suitability for releasing. - Build artifacts once that can be released to multiple locations, multiple use cases. - Specify builds and their dependencies entirely from git and not from transient state of the build system. Employ tools like [renovate](https://docs.renovatebot.com/) to manage dependency updates. -- Build semantic reproducible artifacts. Any configuration which has the potential to affect the semantic functionality of a build should be source controlled and associated with the produced artifact (via the provenance, for example). +- Build semantically reproducible artifacts. Any configuration which has the potential to affect the semantic functionality of a build should be recorded in the provenance and source controlled whenever possible. - Be extensible. Provide opinionated [build pipelines](https://github.com/redhat-appstudio/build-definitions/) and [release pipelines](https://github.com/redhat-appstudio/release-service-catalog), but let users extend those and create their own. - "Shift left" the decisions for releasing into PRs; you should be able to release artifacts from a PR as soon as it is merged. - Just in time scaling: In contrast to “just in case” scaling. The system should be able to scale without capacity reserved ahead of time.