Merge pull request #189 from zregvart/pr/adr-layout

ADR Layouts for Hugo

content/decisions/0000-adr-template.md

@@ -1,6 +1,9 @@
-# 0. Record architecture decisions
-
-Date: 2022-06-17
+---
+date: 2022-06-17T00:00:00Z
+title: Record architecture decisions
+number: 0
+---
+# Record architecture decisions
 
 ## Status
 

content/decisions/0001-pipeline-service-phase-1.md

@@ -1,6 +1,9 @@
-# 1. Pipeline Service Phase 1
-
-Created: 2022-10-13
+---
+date: 2022-10-13T00:00:00Z
+title: Pipeline Service Phase 1
+number: 1
+---
+# Pipeline Service Phase 1
 Last Updated: 2023-09-29
 
 ## Status

content/decisions/0002-feature-flags.md

@@ -1,6 +1,9 @@
-# 2. Feature Flags
-
-Date: 2022-06-01
+---
+date: 2022-06-01T00:00:00Z
+title: Feature Flags
+number: 2
+---
+# Feature Flags
 
 ## Status
 

content/decisions/0003-interacting-with-internal-services.md

@@ -1,6 +1,9 @@
-# 3. Interacting with Internal Services
-
-Date: 2022-10-20
+---
+date: 2022-10-20T00:00:00Z
+title: Interacting with Internal Services
+number: 3
+---
+# Interacting with Internal Services
 
 ## Status
 
@@ -81,4 +84,3 @@ A proof of concept for the **Internal Services Controller** can be found [here](
 
 [KCP]: ../ref/kcp.md
 [release-service]: ../architecture/release-service.md
-

content/decisions/0004-component-image-location.md

@@ -1,6 +1,9 @@
-# 4. Out-of-the-box image repository for StoneSoup users 
-
-Date: Oct 29, 2022 
+---
+date: Oct 29, 2022T00:00:00Z
+title: Out-of-the-box image repository for StoneSoup users
+number: 4
+---
+# Out-of-the-box image repository for StoneSoup users
 
 ## Status
 
@@ -28,13 +31,13 @@ As an application centric experience, StoneSoup should not make it mandatory for
 to be pushed to.
 
 
-**Goals**: 
+**Goals**:
 * Provide an out-of-the-box location for users’ images to be pushed after being built from source.
 
 
-**Non-Goals**: 
+**Non-Goals**:
 * Define the user experience for users bringing existing images from other image registry services.
-* Provide users an option to choose what the out-of-the-box location for images would be. 
+* Provide users an option to choose what the out-of-the-box location for images would be.
 * Define the user experience for users who are willing to configure additional credentials for pushing to an image registry of their choice.
 
 **Design Goals**
@@ -53,7 +56,7 @@ to be pushed to.
 
 * Per workspace called "david", setup a new org “quay.io/unique-org-david/…”
 * Per component, setup a new new repo “quay.io/unique-org-david/unique-component-repo”
-* Use User’s Quay.io API token to manage the org/repo. Short-term, we'll use a pre-configured Quay.io API token associated with StoneSoup to create the org/repo till we 
+* Use User’s Quay.io API token to manage the org/repo. Short-term, we'll use a pre-configured Quay.io API token associated with StoneSoup to create the org/repo till we
  figure out how to determinstically map a user in StoneSoup to a user in Quay.io.
 * Generate a robot account token scoped to the relevant repository and persist it in the user's workspace for the image build and push process to consume.
 
@@ -62,9 +65,9 @@ to be pushed to.
 
 #### Quay.io API token Configuration
 
-1. Setup a Quay.io organization to host the OAuth app. 
+1. Setup a Quay.io organization to host the OAuth app.
 2. Create an OAuth Application in the Quay.io organization.
-3. Geneate a token for the OAuth Application. This token would act as the 'service account' using which Quay.io resources would be created. Important to note, the token acts on behalf of the user who is requesting it - but uses the explicit scopes specified at the time of token generation. 
+3. Geneate a token for the OAuth Application. This token would act as the 'service account' using which Quay.io resources would be created. Important to note, the token acts on behalf of the user who is requesting it - but uses the explicit scopes specified at the time of token generation.
 4. Allowlist user 'shbose' to be create organizations using non-user-tokens using the Quay.io API.
 
 | Syntax      | Description |
@@ -79,12 +82,12 @@ to be pushed to.
 
 #### Organization and Image Repository creation
 
-When a user creates a Component, a StoneSoup service would need to generate the image repository for consumption by the 
+When a user creates a Component, a StoneSoup service would need to generate the image repository for consumption by the
 build, test and deployment services.
 
 * For each user, create a new Quay.io org “quay.io/unique-org-david”
 * For each `Component` 'foo', create a new image repo “quay.io/unique-org-david/appname/componentname”
-* Configure the robot account “redhat-<resource-uuid>” in “quay.io/unique-org-david” to be able to push to “quay.io/unique-org-david/appname-foo” 
+* Configure the robot account “redhat-<resource-uuid>” in “quay.io/unique-org-david” to be able to push to “quay.io/unique-org-david/appname-foo”
 * Configure a `Secret` in the user's namespace with the robot account token.
 * Annotate the `Component` with the name of the image repository and the name of the `Secret` containing the robot account token.
 
@@ -99,19 +102,19 @@ Until the capability to determine the associated user/tenant/Space a Component i
 
 #### Lifecycle of the Quay.io resources
 
-* Token generation: 
+* Token generation:
     * Robot account token: At the moment, the controller responsible for generating the Quay.io resources would be responsible for rotating the tokens https://docs.quay.io/api/swagger/#!/robot/regenerateUserRobotToken
-    * Quay.io API token: No programmatic way to regenerate this token is known at this point of time. This would be a manual activity to begin with. 
+    * Quay.io API token: No programmatic way to regenerate this token is known at this point of time. This would be a manual activity to begin with.
 
-* Upon deletion of an `Application`/`Component` from StoneSoup, 
+* Upon deletion of an `Application`/`Component` from StoneSoup,
     * The controller/finalizer would delete the the relevant Quay.io resources namely, the image repository and the robot account.
     * The controller/finalizer would delete the linked `Secret` from the user's namespace. Most likely, this should be a mere `ownerReference`-based garbage collection.
 
 * Upon removal of a user from Stonesoup,
     * The empty Quay.io organization associated with the user or the user's Space may not be deleted instantly, but would be scheduled for a delayed cleanup.
 * PR-based tags are to be deleted on a regular basis. Image tags associated with `main` may remain un-pruned for now.
-    
-    
+
+
 ### How - Implementation
 
 The implementation of the above design will be improved overtime with the possible introduction of new CRDs/APIs. At the moment, no new API is being planned till the need for it arises.
@@ -133,7 +136,7 @@ spec:
   componentName: billing
 ```
 
-The `Image controller` creates the necessary resources on Quay.io and writes out the details of the same into the `Component` resource as an annotation, namely: 
+The `Image controller` creates the necessary resources on Quay.io and writes out the details of the same into the `Component` resource as an annotation, namely:
 
 * The image repository URL.
 * The name of the Kubernets `Secret` in which the robot account token was written out to.
@@ -162,16 +165,16 @@ spec:
   application: city-transit
   componentName: billing
 ```
-    
-    
+
+
 
 
 ## Open Questions
 
 - What would be a progammatic way to regenerate the main Quay.io API token ?
-- Since the long-term goal is to have the Quay.io organizations owned by the user, how do we build a frictionless experience to map the user's 
+- Since the long-term goal is to have the Quay.io organizations owned by the user, how do we build a frictionless experience to map the user's
   account with the user's Quay.io account ?
-- Considering the above is figured out, we would need to add existing users as members of the relevant organizations. This is a backend job that 
+- Considering the above is figured out, we would need to add existing users as members of the relevant organizations. This is a backend job that
   would need to be designed and executed at an appropriate time.
 
 

content/decisions/0006-log-conventions.md

@@ -1,4 +1,8 @@
-# 6. Log Conventions
+---
+title: Log Conventions
+number: 6
+---
+# Log Conventions
 
 * Date started: 2022-11-11
 * Date revised: 2023-03-08

content/decisions/0007-change-management.md

@@ -1,6 +1,9 @@
-# 7. Change Management Process
-
-Date: 2022-11-22
+---
+date: 2022-11-22T00:00:00Z
+title: Change Management Process
+number: 7
+---
+# Change Management Process
 
 ## Status
 
@@ -25,7 +28,7 @@ Because Stone Soup is using a continuous delivery model, we need to ensure that
 
 ## Decision
 
-Incremental code changes that are fully tested by automated tests, which will not cause an outage or a significant change to functionality, will follow the normal code review process in their respective code repositories. 
+Incremental code changes that are fully tested by automated tests, which will not cause an outage or a significant change to functionality, will follow the normal code review process in their respective code repositories.
 
 To deploy an infrastructure change or a new version of software to staging and production, a developer will make the required change to the infra-deployments repo or the App Interface repo.  Then the change must follow our normal code review process.
 
@@ -34,7 +37,7 @@ To deploy an infrastructure change or a new version of software to staging and p
 A developer will make their code changes and write automated tests in a Git feature branch.  The developer will raise a Github Pull Request (PR) when they need other team members to review their work. This review could be for work in progress or when the developer feels the work is completed. If the developer wants a code review but feels that their work is not ready to be deployed yet, they will add the "do-not-merge/work-in-progress" label to the PR. We also recommend adding "WIP" to the pull request title.
 
 At least one developer who is not the PR author must review and approve the code change. The reviewers will provide comments in Github for suggested changes. The reviewer has a responsibility to verify that the code follows our established best practices and "definition of done". From a change management perspective, the reviewer ensures that:
-* We continue to meet our security and privacy requirements. 
+* We continue to meet our security and privacy requirements.
 * Code is fully exercised by passing unit tests.
 * Proper error and audit logging is in place.
 * There are no obvious implementation holes or incorrect logic.
@@ -43,7 +46,7 @@ At least one developer who is not the PR author must review and approve the code
 
 We also require that all of our repositories be instrumented with CI test automation that runs when a PR is raised, and after each new commit. The CI checks will install the software and run a suite of automated tests.  The CI checks will also run security scans.  All CI checks must pass before performing a Merge to the main branch, as this updates the staging environment and makes the code available for deployment into production.
 
-When the review is completed and CI checks have passed, the approver should Approve the PR in GitHub and the PR author will then Merge the code. 
+When the review is completed and CI checks have passed, the approver should Approve the PR in GitHub and the PR author will then Merge the code.
 
 For changes to the infra-deployments repo, the PR author may add the "lgtm" (looks good to me) label to the PR rather than clicking on the Merge button. This will trigger the Prow/Tide deployment automation to create a batch of approved changes and test and deploy them together, usually within an hour. Batching changes avoids merge race conditions.
 
@@ -58,14 +61,14 @@ There are a few cases where we need to use Red Hat's formal Change Enablement pr
 * If you are releasing new software, or a new major version of existing software.
 * If you are updating firmware or applying patches to existing infrastructure.
 
-This is not meant to be a complete list.  Most activities that impact production environments require a change request to be filed.  
+This is not meant to be a complete list.  Most activities that impact production environments require a change request to be filed.
 
 A good rule of thumb: consider whether external stakeholders (customers, other service owners, our business owners) would expect advance notice of the change or planned outage. If so, this is the process to notify them.
 
 ### Change Sensitivity or EOQ Sensitivity
-Change Sensitivity is a period of time where specific applications or services need to remain stable. Sometimes this could be due to major public events (such as Red Hat Summit), and other times it's related to financial close and reporting, such as End of Quarter Sensitivity (EOQ Sensitivity). 
+Change Sensitivity is a period of time where specific applications or services need to remain stable. Sometimes this could be due to major public events (such as Red Hat Summit), and other times it's related to financial close and reporting, such as End of Quarter Sensitivity (EOQ Sensitivity).
 
-During these periods, if a change will impact production infrastructure, sales, financial close, analysis, and financial reporting, the change will need to be approved by additional reviewers as described in the Change Enablement docs. 
+During these periods, if a change will impact production infrastructure, sales, financial close, analysis, and financial reporting, the change will need to be approved by additional reviewers as described in the Change Enablement docs.
 
 These dates are tracked in the Developer Tools Pipeline Temperature document and our weekly Program Calls.
 

content/decisions/0008-environment-provisioning.md

@@ -1,6 +1,9 @@
-# 8. Environment Provisioning
-
-Date: 2022-12-14
+---
+date: 2022-12-14T00:00:00Z
+title: Environment Provisioning
+number: 8
+---
+# Environment Provisioning
 
 ## Status
 

content/decisions/0009-pipeline-service-via-operator.md

@@ -1,6 +1,10 @@
-# 9. Pipeline Service via Operator
+---
+date: 2023-09-29T00:00:00Z
+title: Pipeline Service via Operator
+number: 9
+---
+# Pipeline Service via Operator
 
-Created: 2023-09-29
 Last Updated: 2023-09-29
 
 ## Status

content/decisions/0010-namespace-metadata.md

@@ -1,6 +1,9 @@
-# 10. Namespace Metadata
-
-Date: 2022-12-09
+---
+date: 2022-12-09T00:00:00Z
+title: Namespace Metadata
+number: 10
+---
+# Namespace Metadata
 
 ## Status
 

content/decisions/0011-roles-and-permissions.md

@@ -1,6 +1,9 @@
-# 11. Roles and Permissions for Konflux
-
-Date: 2023-01-10
+---
+date: 2023-01-10T00:00:00Z
+title: Roles and Permissions for Konflux
+number: 11
+---
+# Roles and Permissions for Konflux
 
 ## Status
 
@@ -93,4 +96,3 @@ We will use the built-in Kubernetes RBAC system for Konflux's role and permissio
 * It will also allow us to assign the appropriate level of permissions to each role, based on the responsibilities and privileges associated with each role in our project.
 * The use of the built-in Kubernetes RBAC system will improve the testability of our system, as we can use the well-documented and widely-used Kubernetes APIs for testing and validation.
 * Using the built-in Kubernetes RBAC system may require some initial configuration and setup. However, it will likely require less ongoing maintenance and support compared to using a custom solution.
-

content/decisions/0012-namespace-name-format.md

@@ -1,6 +1,9 @@
-# 12. Namespace Name Format
-
-Date: 2023-01-23
+---
+date: 2023-01-23T00:00:00Z
+title: Namespace Name Format
+number: 12
+---
+# Namespace Name Format
 
 ## Status
 

content/decisions/0013-integration-service-api-contracts.md

@@ -1,6 +1,9 @@
-# 13. Konflux Test Stream - API contracts
-
-Date: 2023-01-30
+---
+date: 2023-01-30T00:00:00Z
+title: Konflux Test Stream - API contracts
+number: 13
+---
+# Konflux Test Stream - API contracts
 
 ## Status
 

content/decisions/0014-let-pipelines-proceed.md

@@ -1,4 +1,8 @@
-# 14. Let Pipelines Proceed
+---
+title: Let Pipelines Proceed
+number: 14
+---
+# Let Pipelines Proceed
 
 * Date Decided: 2022-05-??
 * Date Documented: 2023-01-31

content/decisions/0015-integration-service-two-phase-architecture.md

@@ -1,4 +1,8 @@
-# 15. The Two-phase Architecture of the Integration Service
+---
+title: The Two-phase Architecture of the Integration Service
+number: 15
+---
+# The Two-phase Architecture of the Integration Service
 
 Date Documented: 2023-02-09
 Date Accepted: 2023-02-14
@@ -106,4 +110,3 @@ However, we realized (through conversations like
 [this slack conversation](https://redhat-internal.slack.com/archives/C02CTEB3MMF/p1669961732100869))
 that it is not obvious without documentation.
 We are documenting it here as an ADR for posterity, visibility.
-

content/decisions/0016-integration-service-promotion-logic.md

@@ -1,4 +1,8 @@
-# 16. Promotion logic in the Integration Service
+---
+title: Promotion logic in the Integration Service
+number: 16
+---
+# Promotion logic in the Integration Service
 
 * Date Documented: 2023-02-08
 * Date Accepted: 2023-02-27

content/decisions/0017-use-our-pipelines.md

@@ -1,4 +1,8 @@
-# 17. Use our own pipelines
+---
+title: Use our own pipelines
+number: 17
+---
+# Use our own pipelines
 
 * Date 2023-02-10
 

content/decisions/0018-apps-continuous-perf-testing.md

@@ -1,6 +1,9 @@
-# 18. Continuous Performance Testing (CPT) of Apps in Konflux
-
-Date: 2023-03-10
+---
+date: 2023-03-10T00:00:00Z
+title: Continuous Performance Testing (CPT) of Apps in Konflux
+number: 18
+---
+# Continuous Performance Testing (CPT) of Apps in Konflux
 
 ## Status