Create design document for automated releases

Signed-off-by: Courtney Pacheco <6019922+courtneypacheco@users.noreply.github.com>

docs/ci/ci-automated-release-workflow.md

@@ -0,0 +1,77 @@
+# Creating Automated Releases: Design Document
+
+## Motivation & Overview
+
+Presently, the release processes for every library within this `instructlab` GitHub organization is entirely manual:
+
+A maintainer has to:
+
+1. Manually create a new release branch -- e.g., `release-0.y.0`,
+2. Manually create a pull request against `release-0.y.0` to cap the versions on some of the dependencies defined in their library's `requirements.txt` file,
+3. Optionally trigger an E2E test against that pull request,
+4. Wait for all pull request CI checks to complete,
+5. Manually request two maintainers to approve the pull request, and
+6. Manually create a release from the GitHub UI using that new branch
+
+This entire process takes at least 10 minutes of manual work, plus however long it takes for the pull request's checks to complete. (In some repositories, like the core repo, this can take 2+ hours.)
+
+Going forward, we should automate these release processes so that contributors and maintainers can focus on development work such that maintainers 
+
+## Automation Workflow
+
+### Brief Overview of the Automation
+
+This section contains the initial design diagram for the automated release process. Essentially, a Git workflow file will be created and used in each library (as desired) to automate said library's entire release process. Thus, the diagram below describes what generic steps will be defined in the Git workflow file. This workflow can certainly be converted to an in-house GitHub action if desired, but it should be at least reusable.
+
+### Goals of the Automation
+
+The automated process should be:
+
+1. Configurable so that any library maintainer can configure the automation to meet their specific repository's needs
+2. Schedulable so that releases are generated according to a specific cadence
+
+Scheduled releases are generally important for setting expectations around release cadences, but they are by no means required for every library and may not even be applicable to some in this GitHub organization. Therefore, this design includes an option for manual triggers or scheduled triggers.
+
+### Configurable Components
+
+As mentioned above, there are configurable components within this release process automation. The diagram in the next section references two configurable components:
+
+#### Trigger Schedule
+
+The trigger schedule defines the day and time (in UTC) when the release process will kick off. This schedule can be disabled if desired, and maintainers can trigger the release process manually when needed instead.
+
+#### Custom List of Dependencies to Cap
+
+With each release, some library maintainers may want to cap the vesrion of certain dependencies within their `requirements.txt` file as well as specify the desired upper cap for each one. This list will be provided in the form of a configuration file that each library maintainer can place under the `.github` folder. For example,
+
+`cap-deps.cfg`:
+
+```
+instructlab-sdg, +0.1.0
+instructlab-eval, +0.2.0
+instructlab-training, +1.0.0
+```
+
+The first column specifies the dependencies to cap. (In this case, we only have three: `instructlab-sdg`, `instructlab-eval`, and `instructlab-training`. The other dependencies in the `requirements.txt` file will be ignored and left untouched.)
+
+The second column specifies the cap relative to the current lower bound. For example, let's say the current `requirements.txt` file looks like this:
+
+```bash
+instructlab-sdg>0.20.0
+instructlab-eval>0.1.0
+instructlab-training
+```
+
+In this case, the automated logic will create a pull request that updates the `requirements.txt` file like so (ignoring the inline explanations I provided as comments):
+
+```bash
+instructlab-sdg>0.20.0,<=0.21.0 # increment by 0.1.0 because of the '+0.1.0' in the `cap-deps.cfg` file
+instructlab-eval>0.1.0,<=0.3.0  # increment by 0.2.0 because of the '+0.2.0' in the `cap-deps.cfg` file
+instructlab-training            # do nothing because there was no lower bound set.
+```
+
+If there is no `.github/cap-deps.cfg` file within the repository, then none of the dependencies defined in `requirements.txt` will be capped.
+
+## Release Diagram
+
+![Automated workflow for creating new GitHub releases](images/design-diagram-for-automated-releases.png)