Skip to content

Commit

Permalink
chore: update practices around maintaining the UDS Common framework (#…
Browse files Browse the repository at this point in the history
  • Loading branch information
Racer159 authored Oct 4, 2024
1 parent c828932 commit a733122
Show file tree
Hide file tree
Showing 18 changed files with 233 additions and 121 deletions.
8 changes: 8 additions & 0 deletions .github/pull_request_template.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
## Description

...

## Checklist before merging

- [ ] ADR proposed if making an architectural change to the repo
- [ ] Tests run, docs added or updated as needed
52 changes: 52 additions & 0 deletions .github/workflows/callable-scorecard.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
name: Scorecards supply-chain security
on:
# Only the default branch is supported.
branch_protection_rule:
schedule:
- cron: 30 1 * * 6
push:
branches: [main]
# This allows other repositories to call this workflow in a reusable way
workflow_call:

# Declare default permissions as read only.
permissions: read-all

jobs:
run:
name: Scorecards analysis
runs-on: ubuntu-latest
permissions:
# Needed to upload the results to code-scanning dashboard.
security-events: write
# Used to receive a badge.
id-token: write

steps:
- name: Checkout code
uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
with:
persist-credentials: false

- name: Run analysis
uses: ossf/scorecard-action@62b2cac7ed8198b15735ed49ab1e5cf35480ba46 # v2.4.0
with:
results_file: results.sarif
results_format: sarif
repo_token: ${{ secrets.SCORECARD_READ_TOKEN }}
publish_results: true

# Upload the results as artifacts (optional). Commenting out will disable uploads of run results in SARIF
# format to the repository Actions tab.
- name: Upload artifact
uses: actions/upload-artifact@50769540e7f4bd5e21e526ee35c689e35e0d6874 # v4.4.0
with:
name: SARIF file
path: results.sarif
retention-days: 5

# Upload the results to GitHub's code scanning dashboard.
- name: Upload to code-scanning
uses: github/codeql-action/upload-sarif@294a9d92911152fe08befb9ec03e240add280cb3 # v3.26.8
with:
sarif_file: results.sarif
28 changes: 8 additions & 20 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -1,8 +1,8 @@
# Welcome to UDS Common

Thank you for your interest in contributing to the common patterns Defense Unicorns uses across UDS!
Thank you for your interest in contributing to the common framework Defense Unicorns 🦄 uses across UDS!

This document describes the process and requirements for contributing.
Below are the process and requirements for contributing.

## Developer Experience

Expand All @@ -16,6 +16,10 @@ Specifically:
* Continuous integration (CI) pipeline tests are definitive
* We create immutable release artifacts

### Philosophy

Before contributing or suggesting a larger change it is important to keep in mind that the "Best way to avoid punch. No be there." ―Miyagi to Daniel in Karate Kid. This means that the best way to update a task or a configuration is to require no downstream changes at all and to suggest changes in architecture that will lead to fewer and fewer downstream changes over all. When proposing architectural changes in [ADRs](#architecture-decision-records-adr) you should clearly outline (and test!) the consequences of changes to downstream consumers.

### Developer Workflow

:key: == Required by automation
Expand All @@ -34,24 +38,8 @@ Specifically:

We've chosen to use ADRs to document architecturally significant decisions. We primarily use the guidance found in [this article by Michael Nygard](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions) with a couple of tweaks:

- The criteria for when an ADR is needed is undefined. The team will decide when the team needs an ADR.
- An ADR is needed whenever there is an architectural/structural change to the repository that will incur downstream impacts to other repositories.
- We will use the tool [adr-tools](https://github.com/npryce/adr-tools) to make it easier on us to create and maintain ADRs.
- We will keep ADRs specific to this package in the repository under `adr/NNNN-name-of-adr.md`.
> `adr-tools` is configured with a dotfile to automatically use this directory and format.
- We will keep ADRs relating to Software Factory as a whole in the [UDS Software Factory](https://github.com/defenseunicorns/uds-software-factory) repository under `adr/NNNN-name-of-adr.md`.

### How to use `adr-tools`

```bash
# Create a new ADR titled "Use Bisquick for all waffle making"
adr new Use Bisquick for all waffle making

# Create a new ADR that supersedes a previous one. Let's say, for example, that the previous ADR about Bisquick was ADR number 9.
adr new -s 9 Use scratch ingredients for all waffle making

# Create a new ADR that amends a previous one. Let's say the previous one was ADR number 15
adr new -l "15:Amends:Amended by" Use store-bought butter for all waffle making

# Get full help docs. There are all sorts of other helpful commands that help manage the decision log.
adr help
```
- We will keep ADRs relating to specific teams in their repositories (i.e. the [UDS Software Factory](https://github.com/defenseunicorns/uds-software-factory) repository).
107 changes: 20 additions & 87 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,100 +1,33 @@
# UDS Common
# 🦄 UDS Common

This repository contains common configuration and tasks used in UDS Packages for management, setup, creation, deployment, and publishing of packages and bundles. It also includes [UDS package practices](./docs/package_integration/uds-package-practices.md) defining requirements and standards to obtain the [<img alt="Made for UDS" src="docs/made-for-uds.svg" height="20px"/>](https://github.com/defenseunicorns/uds-core) Badges.
[![Latest Release](https://img.shields.io/github/v/release/defenseunicorns/uds-common)](https://github.com/defenseunicorns/uds-common/releases)
[![Build Status](https://img.shields.io/github/actions/workflow/status/defenseunicorns/uds-common/tag-and-release.yaml)](https://github.com/defenseunicorns/uds-common/actions/workflows/tag-and-release.yaml)
[![OpenSSF Scorecard](https://api.securityscorecards.dev/projects/github.com/defenseunicorns/uds-common/badge)](https://api.securityscorecards.dev/projects/github.com/defenseunicorns/uds-common)

## Task Usage

The tasks are designed to be consumed via remote task includes and GitHub Actions (WIP). It is typically easiest to include tasks in a single root level `tasks.yaml`. Includes should follow the standard remote include pattern documented by UDS CLI:

```yaml
includes:
- deploy: https://raw.githubusercontent.com/defenseunicorns/uds-common/$TAG/tasks/deploy.yaml
```
Pinning to a specific tag of a task (rather than `main`) with renovate watching for updates is recommended since tasks do rely on dependencies like command syntax for `zarf` and `uds` as well as the published versions of `uds-core`.

## Supported Tool Versions

- UDS CLI: 0.17.0
- UDS Core: 0.28.0
- K3D: 5.7.4
- Lula: 0.8.0

NOTE: Zarf is not required for tasks in this repo, the vendored zarf (`uds zarf`) included with UDS CLI is used instead to prevent version mismatches.

## Task Files

There are multiple task files available in this repository with different objectives and required variables.

### setup.yaml

This task file includes two tasks:

- `k3d-test-cluster` sets up a k3d cluster running the `uds-core-istio-dev` package. This provides a baseline cluster with Istio and the UDS Core Pepr capabilities necessary to test against.
- `registry-login` performs a registry login and retry a max of 10 times at a desired retry interval (in seconds). It reads in variables for the task to use for the registry login parameters. The variable inputs are:
- `REGISTRY`: the target registry
- `REGISTRY_USERNAME`: the username for the registry
- `REGISTRY_PASSWORD`: the password for the registry
- `REGISTRY_RETRY_INTERVAL`: the number in seconds to wait between retries

### create.yaml

This task file includes two tasks:

- `package`: creates a zarf package located at the base of the repository. It has a required variable of `FLAVOR` which defaults to `upstream` and inputs to override the default path and options used for creation (useful in publishing workflows).
- `test-bundle`: creates a test bundle located at the path `bundle/` (by default). It uses `UDS_ARCH` to override the default architecture used for creation (useful in publishing workflows). Note that this task does not create any pre-requisite zarf packages so those tasks must be run first.

### deploy.yaml
This repo acts as a UDS Package Framework that contains common configuration, tasks and documentation useful for building downstream UDS Packages. It defines and helps consumers implement [UDS package practices](./docs/package_integration/uds-package-practices.md) within their specific package repositories and is intended to help streamline keeping those practices up to date over time.

This task file includes two tasks:
## Contents

- `package`: deploys a zarf package located at the base of the repository (using the regex match `zarf-package-*-${UDS_ARCH}-*.tar.zst`).
- `test-bundle`: deploys a test bundle located at the path `bundle/` (using the regex match `bundle/uds-bundle-*-${UDS_ARCH}-*.tar.zst`) and the config file located at `bundle/uds-config.yaml`.
The repo itself contains:

### publish.yaml
- [UDS tasks](tasks) to maintain, build, test, validate, and publish UDS Packages.
- [Documentation](docs) on what makes a "UDS Package" a UDS Package and how to implement one for yourself.
- [Renovate configuration](config/renovate.json5) to update Helm charts, Docker images, Zarf packages and more.
- [VSCode configuration](config/.vscode) to setup syntax highlighting for different tooling in your IDE.
- [An example](.) UDS Package for Nginx that demonstrates the general structure and acts as a test for the common tasks.

This task file includes two tasks:

- `package`: which publishes a zarf package. Inputs for this task:

- `PATH`: the path to the directory in which to look for the package. Defaults to `.`
- `VERSION`: the version of the zarf package to publish with no default. This should typically be version controlled by something like release-please.
- `ARCHITECTURE`: the architecture of the zarf package to publish, defaults to `${UDS_ARCH}`
- `TARGET_REPO`: the target OCI repository to publish the zarf package to (without the `oci://` scheme) - this defaults to `ghcr.io/defenseunicorns/packages/uds`.

The package will be matched based on the pattern `${PATH}/zarf-package-*-${ARCHITECTURE}-${VERSION}.tar.zst` and published to `oci://${TARGET_REPO}`

- `test-bundle`: which publishes a UDS bundle. Inputs for this task:

- `PATH`: the path to the directory in which to look for the bundle. Defaults to `bundle`
- `VERSION`: the version of the bundle to publish with no default. This should typically be version controlled by something like release-please.
- `ARCHITECTURE`: the architecture of the bundle to publish, defaults to `${UDS_ARCH}`
- `TARGET_REPO`: the target OCI repository to publish the bundle (without the `oci://` scheme) - this defaults to `ghcr.io/defenseunicorns/packages/uds/bundles`.

The bundle will be matched based on the pattern `${PATH}/uds-bundle-*-${ARCHITECTURE}-${VERSION}.tar.zst` and published to `oci://${TARGET_REPO}`


### pull.yaml

This task file includes one task:

- `latest-package-release`: finds the latest package release for the repo and pulls it into the specified directory path. It has a required variable of `FLAVOR` which defaults to `upstream` and a `TARGET_REPO` variable which is the target OCI repository to pull the zarf package from (without the `oci://` scheme) - this defaults to `ghcr.io/defenseunicorns/packages/uds`.

### lint.yaml
## Task Usage

This task file includes two tasks:
Common `tasks` can be included in downstream repositories and executed with `uds run`. You can learn more about the common tasks in this repo on the [tasks README](./tasks/README.md).

- `deps`: installs all of the dependencies for linting the repository.
- `yaml`: lints all of the `.yaml` files within the repository.
- `oscal`: lints targeted OSCAL files within the repository.
## Configuration Usage

### compliance.yaml
Common configuration used between repositories is located in the `config` directory and is imported via specific tool mechanisms (like Renovate's `extends` key).

This task file includes two tasks:
## Example Usage

- `validate`: performs a compliance assessment of the repository against the identified OSCAL standard.
- `evaluate`: Compares the results (when present) to evaluate compliance.
The example in this repository is based around Nginx and can be interacted with as you would in any other UDS Package repo - i.e. `uds run test-package`

## Configuration Usage
## Contributing

Common configuration used between repositories is located in the `config` directory and is imported via specific tool mechanisms (like Renovate's `extends` key).
Please see the [CONTRIBUTING.md](./CONTRIBUTING.md)
File renamed without changes.
4 changes: 2 additions & 2 deletions docs/package_integration/development-ide-configuration.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,11 +12,11 @@ Open the command palette and select the specific level of settings you want to m

![Command Pallete](./.images/cmd-pallete.png)

In the file that opens, add your yaml language server specific settings (and any other setting you may want globally) in line with the example [configuration](.vscode/settings.json). Then save the settings.
In the file that opens, add your yaml language server specific settings (and any other setting you may want globally) in line with the example [configuration](../../config/.vscode/settings.json). Then save the settings.

### Per Repo Config

Either manually or via the Command Palette, create a `.vscode/settings.json` at the repo level you are working on. In that `settings.json`, you can add the appropriate `yaml.schemas` settings, similar to what is found in the [example](.vscode/settings.json) in this repo.
Either manually or via the Command Palette, create a `.vscode/settings.json` at the repo level you are working on. In that `settings.json`, you can add the appropriate `yaml.schemas` settings, similar to what is found in the [example](../../config/.vscode/settings.json) in this repo.

> [!NOTE]
> The references to schema versions are tied to git tags in the example; depending on your goals, it may be appropriate to do this to validate the schema is correct for the version of the tools you expect to be using in the repo. Otherwise, to check if the schema is up to date with the latest, you can have the links to each json schema pointed at `main`.
Expand Down
8 changes: 4 additions & 4 deletions renovate.json
Original file line number Diff line number Diff line change
Expand Up @@ -15,28 +15,28 @@
"regexManagers": [
{
"depNameTemplate": "defenseunicorns/uds-core",
"fileMatch": ["README\\.md"],
"fileMatch": ["tasks/README\\.md"],
"matchStrings": ["- UDS Core: (?<currentValue>.*)"],
"datasourceTemplate": "github-tags",
"extractVersionTemplate": "^v(?<version>.*)$"
},
{
"depNameTemplate": "defenseunicorns/uds-cli",
"fileMatch": ["README\\.md"],
"fileMatch": ["tasks/README\\.md"],
"matchStrings": ["- UDS CLI: (?<currentValue>.*)"],
"datasourceTemplate": "github-tags",
"extractVersionTemplate": "^v(?<version>.*)$"
},
{
"depNameTemplate": "k3d-io/k3d",
"fileMatch": ["README\\.md"],
"fileMatch": ["tasks/README\\.md"],
"matchStrings": ["- K3D: (?<currentValue>.*)"],
"datasourceTemplate": "github-tags",
"extractVersionTemplate": "^v(?<version>.*)$"
},
{
"depNameTemplate": "defenseunicorns/lula",
"fileMatch": ["README\\.md"],
"fileMatch": ["tasks/README\\.md"],
"matchStrings": ["- Lula: (?<currentValue>.*)"],
"datasourceTemplate": "github-tags",
"extractVersionTemplate": "^v(?<version>.*)$"
Expand Down
Loading

0 comments on commit a733122

Please sign in to comment.