Merge branch 'dev-docs-refresh' into 'master'

Developer documentation updates & refresh

See merge request !4114

docs/developer/ci-workflow.md

@@ -52,6 +52,10 @@ This stage runs a `helm conftest` which is a plugin for testing helm charts with
 
 This stage also validates the oscal-component.yaml and checks for api deprecations within the package.
 
+### Validate MR
+
+This stage checks the MR description to ensure the `## Upgrade Notices` section contains information that is not the default `(Include any relevant notes about upgrades here or write "N/A" if there are none)`. This section is required to be filled out as if an upgrade notice is present, r2d2 will pull it into the Release Notes for the corresponding milestone. These Notices should be seen and written as customer facing when a template/secret/value name is updated that may require users to alter their configuration, this is not meant for internal or CI facing notes.
+
 ### Package Tests
 
 This stage verifies several easy to check assumptions such as:
@@ -74,6 +78,10 @@ This stage is triggered when a protected tag is created. It is responsible for p
 
 Upon successful completion of the package stage this release stage will use those artifacts and run the gitlab release-cli utility to publish the release.
 
+### Creating Big Bang Merge Request
+
+Post merge to the default branch and tag creation above, the last step of the package release stage will perform `Creating Big Bang Merge Request` which will pull down information from the package MR and auto increment the package's `git/helmRepo.tag` value along with pulling in the CHANGELOG and linking the package merge request. This stage can be skipped by adding `skip-bb-mr` label to the package MR pre-tag/release pipeline if a BigBang MR is already opened that will be manually updated to include the new tag.
+
 ## BigBang Pipeline Stages
 
 This pipeline is triggered by the following for bigbang:

docs/developer/development-environment.md

@@ -22,4 +22,5 @@ There is a script that automates the creation and teardown of a remote k3d devel
 - [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
 - [AWS cli](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
 - [jq](https://stedolan.github.io/jq/download/)
+- [KPT pre v1](https://github.com/kptdev/kpt/releases/tag/v0.39.2)
 - optional: [kustomize](https://kubectl.docs.kubernetes.io/installation/kustomize/)

docs/developer/renovate-maintenance.md

+# Renovate Package Maintenance
+
+The Bread and butter of Big Bang is updating and providing timely releases for the Big Bang maintained helm charts. Most of these helm charts are based off of upstream vendor charts and repositories. This can be confirmed via seeing if a `chart/Kptfile` exists in our repository.
+
+1. All Big Bang packages should contain a `docs/DEVELOPMENT_MAINTENANCE.md` file which should be reviewed and understood by codeowners and those working the package updates. It has all of the necessary changes to begin working a Renovate update for any given package. Repository CODEOWNERS should also be using this document when reviewing the updates for a Merge Request that is in `status::review` to ensure all items are being performed, or updating the documentation if a portion is no longer relevant or needed. This document is where all of our local changes and caveats should be documented when creating changes which deviate from upstream templates or values according to the [Develop Package](./develop-package.md) steps when onboarding a new package.
+
+1. Once the package has been updated, tested and verified according to the DEVELOPMENT_MAINTENANCE.md guide it should then have the following steps taken:
+
+   1. Review pipeline and ensure all items are passing or if warnings are found, they are notated in the Merge Request comments or description. If an item mentioned in the [CI Workflow Document](./ci-workflow.md) is added `SKIP UPGRADE/skip-bb-mr` ensure this is notated why so we have justification as to why this was needed.
+   1. The `## Upgrade Notices` section is accurately filled out in the MR description. This notice should be treated as customer public facing and should not include any internal team or CI specific notes for the package. Good examples of relevant upgrade notices are when a template or value moves or is renamed like a ENV var or value for an admin password for example, some change that will require downstream consumers of Big Bang to read and perform a change for their environment.
+   1. Ensure `SKIP UPDATE CHECK` is removed from the MR title and a pipeline has ran with a `chart update check` stage.
+   1. Add `status::review` label to issue and Merge Request.
+
+1. Once merged into `main`, ensure post-MR pipelines for `main` and tag creation fully pass. Reach out to CODEOWNERS or anchors if issues arise.
+
+1. After all MR, main, and tag pipelines pass and are successful, bigbang-bot will open a BigBang Merge Request. Link your issue your assigned in the description after the `Closes` eg: `Closes https://repo1.dso.mil/ISSUE`. Ensure pipeline is passing and package/change related issues are not present in pipeline. Once pipeline is passing and is linked take MR out of draft status. Assign anchors and BigBang codeowners as reviewers.
+
+## General Renovate Issue Workflow
+
+```mermaid
+flowchart TD
+    Initial((Issue)) -.-> |Assign Yourself\n label status::Doing\n Weight Issue| Initial
+    Initial --> |If MR exists\n Open MR| MR{{Merge Request}}
+    MR -.-> |Assign Yourself\n label status::Doing| MR
+    MR --> WorkIssue>Work Issue]
+    WorkIssue -.-> |If Renovate Issue,\n Follow dev maintenance doc| WorkIssue
+    WorkIssue -.-> |Bump Chart version: bb.x \n Update CHANGELOG \n Regenerate readme| WorkIssue
+    WorkIssue --> |Push to Repo1| Repo1[(Repo1 MR)]
+    Repo1 --> |Pipeline Fails| WorkIssue
+    Repo1 --> |Pipeline Passes| Test>Test Work]
+    Test -.-> |Deploy Big Bang \n Test branch changes\n For Install/Upgrade| Test
+    Test --> |Testing Fails| WorkIssue
+    Test --> |Testing Passes| Review{{Merge Request}}
+    Review -.-> |Add status::Review label to MR and Issue \n Take MR out of Draft\n Assign CODEOWNERS as Reviewers| Review
+    Review --> Codeowners>Review]
+    Codeowners -.-> |Reviewer checks changes and pipeline status \n Reviewer Deploys Big Bang \n Testing branch changes\n For Install/Upgrade| Codeowners
+    Codeowners --> |Testing Fails \n Relabels to status::Doing \n Notify Assignee| WorkIssue
+    Codeowners --> |Testing Passes \n Approve and Merge| Pipelines
+    Pipelines -.-> |Pipelines run \n Changes Merged \n New Release Tag is made| Pipelines
+    Pipelines --> |New MR opens in Big Bang| BigBang((Big Bang))
+    BigBang -.-> |Add links if needed \n Make sure pipeline passes \n Take MR out of Draft \n Add status::Review label\n Assign CODEOWNERS as Reviewers| BigBang
+    BigBang --> |MR Merged\n Issue Closed| Initial
+```