feat: initial docs (#10)

.github/actions/install-uds-cli/action.yaml

@@ -11,7 +11,7 @@ inputs:
 runs:
   using: composite
   steps:
-  - name: Set UDS CLI Arch
+  - name: Set UDS Releaser Arch
     id: setUdsCliArch
     shell: bash
     run: INPUT=${{ runner.arch == 'X64' && 'amd64' || runner.arch }}; echo "ARCH=${INPUT,,}" >> "$GITHUB_OUTPUT"

.github/workflows/scan-codeql.yaml

@@ -44,7 +44,7 @@ jobs:
       - name: Install UDS CLI
         uses: ./.github/actions/install-uds-cli
 
-      - name: Build UDS CLI
+      - name: Build UDS Releaser
         run: uds run build-cli-linux-amd
 
       - name: Initialize CodeQL

CODEOWNERS

@@ -0,0 +1,5 @@
+* @defenseunicorns/swf @defenseunicorns/uds-appstore
+
+# Additional privileged files
+/CODEOWNERS @jeff-mccoy @daveworth
+/LICENSE @jeff-mccoy @daveworth

CONTRIBUTING.md

@@ -0,0 +1,69 @@
+# Contributing to UDS Releaser
+
+Welcome :unicorn: to UDS Releaser! If you'd like to contribute, please reach out to one of the [CODEOWNERS](CODEOWNERS) and we'll be happy to get you started!
+
+Below are some notes on our core software design philosophies that should help guide contributors.
+
+## Table of Contents
+
+1. [Code Quality and Standards](#code-quality-and-standards)
+1. [How to Contribute](#how-to-contribute)
+    - [Building the app](#building-the-app)
+    - [Pre-Commit Hooks and Linting](#pre-commit-hooks-and-linting)
+    - [Testing](#testing)
+
+## Code Quality and Standards
+
+Fundamentally, Software Engineering is a communication problem; we write code for each other, not a computer. When working on this project (or any project!) keep your fellow humans in mind and write clearly and concisely. Below are some general guidelines for code quality and standards that make UDS Releaser :sparkles:
+
+- **Write tests that give confidence**: Unless there is a technical blocker, every new feature and bug fix should be tested in the project's automated test suite. Although many of our tests are E2E, unit and integration-style tests are also welcomed. Note that unit tests can live in a `*_test.go` file alongside the source code, and E2E tests live in `src/test/e2e`
+
+- **Prefer readability over being clever**: We have a strong preference for code readability in UDS Releaser. Specifically, this means things like: naming variables appropriately, keeping functions to a reasonable size and avoiding complicated solutions when simple ones exist.
+
+### Continuous Delivery
+
+Continuous Delivery is core to our development philosophy. Check out [https://minimumcd.org](https://minimumcd.org/) for a good baseline agreement on what that means.
+
+Specifically:
+
+- We do trunk-based development (`main`) with short-lived feature branches that originate from the trunk, get merged into the trunk, and are deleted after the merge
+- We don't merge code into `main` that isn't releasable
+- We perform automated testing on all changes before they get merged to `main`
+- We create immutable release artifacts
+
+## How to Contribute
+
+Please ensure there is a GitHub issue for your proposed change, this helps the UDS Releaser team to understand the context of the change and to track the progress of the work. If there isn't an issue for your change, please create one before starting work. The recommended workflow for contributing is as follows:
+
+1. **Fork this repo** and clone it locally
+1. **Create a branch** for your changes
+1. **Create, [test](#testing)** your changes
+1. **Add docs** where appropriate
+1. **Push your branch** to your fork
+1. **Open a PR** against the `main` branch of this repo
+
+### Building the app
+
+To build the app, check out the [tasks](tasks.yaml) with `uds run --list-all`, find the appropriate build target for your system, and run it from the root of the repo (ex. `uds run build-cli-mac-apple`). This will create a binary in the `build` directory that you can use to test your changes (note that this binary is automatically used when running [E2E Tests](#running-tests).
+
+### Testing
+
+We strive to test all changes made to UDS Releaser. If you're adding a new feature or fixing a bug, please add tests to cover the new functionality. Unit tests and E2E tests are both welcome, but we leave it up to the contributor to decide which is most appropriate for the change. Below are some guidelines for testing:
+
+#### Unit Tests
+
+Unit tests reside alongside the source code in a `*_test.go` file. These tests should be used to test individual functions or methods in isolation. Unit tests should be fast and focused on a single piece of functionality.
+
+#### E2E Tests
+
+E2E tests reside in the `src/test/e2e` directory. These tests leverage the `releaser.yaml` file in `src/test` and have util functions to work out of `src/test/sandbox`.
+
+#### Assertions
+
+We prefer to use Testify's [require](https://github.com/stretchr/testify/tree/master/require) package for assertions in tests. This package provides a rich set of assertion functions that make tests more readable and easier to debug. See other tests in this repo for examples.
+
+#### Running Tests
+
+- **Unit Tests**: To run unit tests, run `uds run test:unit` from the root of the repo. This will run all unit tests in the `src` directory.
+
+- **E2E Tests**: To run E2E tests, you'll need build UDS Releaser locally, and re-build any time you make a change to the source code; this is because the binary in the `build` directory is used to drive the tests. To run the entire suite of E2E tests locally, run `uds run e2e`.

README.md

@@ -1,5 +1,54 @@
 # UDS-Releaser
 
-⚠️💀 UDS-Releaser is still in the experimental/prototype stage and is not ready for any kind of public consumption.
+## Overview
 
-Small GoLang tool to facilitate release processes for uds-packages
+UDS-Releaser is a tool designed to assist in publishing releases for UDS Packages. It automates the process of creating releases and tagging versions for each flavor.
+
+## Features
+
+- Automated release and tag creation
+- GitLab Integration (More to come)
+- Customizable release configuration file
+
+## Installation
+
+Download the latest UDS-Releaser binaries from the [GitHub Releases](https://github.com/defenseunicorns/uds-releaser/releases) page.
+
+## Usage
+
+After installation, you can use uds-releaser via the command line:
+
+### Commands
+
+- `check`: Check if release is necessary for a given flavor
+- `release`: Create a new release on the specified platform for a given flavor
+- `show`: Print the current version of the specified flavor
+- `update-yaml`: Update the version fields in the zarf and uds-cli yaml files based on flavor
+
+### Example
+
+Pseudo flow for CI/CD:
+
+```bash
+uds-releaser check <flavor>
+
+uds-releaser update-yaml <flavor>
+
+# publish the package #
+
+uds-releaser release <flavor>
+```
+
+## Configuration
+
+UDS-Releaser can be configured using a YAML file named uds-releaser.yaml in your project's root directory.
+
+```yaml
+flavors:
+  - name: upstream
+    version: "1.0.0-uds.0"
+  - name: registry1
+    version: "2.0.0-uds.0"
+  - name: unicorn
+    version: "1.0.0-uds.0"
+```