Cloned2Preserve
/
TrueChartsClone
mirror of https://github.com/truecharts/charts.git
1
0
Fork 0
Code

Port doc changes from k8s-at-home

This commit is contained in:
kjeld Schouten-Lebbing 2021-08-30 17:56:37 +02:00
parent 324f71dbce
commit 6c7329b750
No known key found for this signature in database
GPG Key ID: 4CDAD4A532BC1EDB
3 changed files with 58 additions and 131 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
docs/manual/development/Container Images.md
View File

@ -1,20 +0,0 @@
# Container Images
These [container images](https://github.com/truecharts/containers) are tailored for Kubernetes.
## Purpose
The goal of this project and the container images are to support [Semantic Versioning](https://semver.org/), security and native K8S support.
We try to keep a [KISS principle](https://en.wikipedia.org/wiki/KISS_principle) when building these images, which means no [s6-overlay](https://github.com/just-containers/s6-overlay) and all images are built on top of [ubuntu:focal](https://hub.docker.com/_/ubuntu).
## Configuration
In order to get the Container images repository and tags see [here](https://github.com/orgs/truecharts/packages?ecosystem=container&visibility=public).
For configuration and documentation see [here](https://truecharts/containers/getting-started/).
## Support
We have several different methods for getting support.
- [GitHub Discussions](https://github.com/truecharts/apps/discussions)

30
docs/manual/development/app-addition.md
View File

@ -1,30 +0,0 @@
# App Addition Guidelines
Though we aim to be as open to contributions, at TrueCharts we still sometimes have to decide which Apps we do and do not add to our catalog. This document aims to give some guidelines in how we are going to make such decisions.
### Guidelines
##### Target Audience
- Our target audience is Home and SMB users
- While we currently support only one node, due to TrueNAS SCALE constraints, we aim for a maximum adviced deployment size of 10 Nodes and/or 50 Drives. This is in line with what we expect our target audience to be
##### Commercial vs non-commercial
- Apps that are only useable for paying customers are a no-go
- Apps that are trial-ware to non-paying customers are a no-go. Apps that have an enterprise option, that doesn't obstruct the open-core version are generally allowed
- Apps that are open-source are prefered over closed-source Apps. If opensource alternatives are available we might not approve a closed-source App.
- If a company or official maintainer submits an App, we expect them to maintain it themselves. We do not have the resources to work for external projects.
##### Update Policies and stability
- We expect Apps to have decent security (options) in place
- We expect Apps not to contain higher-level CVE's
- We prefer Apps that are actively maintained. Expect Apps that are abandoned (or barely maintained) for a year or more to even be removed, as we do not expect those to be secure.
##### App design
- Apps charts are expected to be kept as simple as possible, preferably using the common-chart where-ever possible.
- It's adviced to only deploy HA versions of apps if they are relatively simple. Complicated Apps (with addon operators and load balancers for example), should only be used in key area's because they are harder to maintain.
- We aim for a "1 App - 1 DB - 1 DB Instance" solution, because small single DB instances can be easily spread over multiple nodes in the future.

139
docs/manual/development/unit-tests.md
View File

@ -1,129 +1,106 @@
# Unit tests
We unit test our common library, while it isn't near complete coverage but it does offer some basic checks.
We unit test our common library, while it isn't near complete coverage but
it does offer some basic checks.
## Running the tests
Running these tests can be done any way you like. In this document we describe
a number of approaches.
Running these tests can be done any way you like. In this document we describe a number of approaches:
* [Directly on your development machine](#directly-on-your-development-machine)
* [Through a development container in Visual Studio Code](#using-visual-studio-code)
* [Using a local Docker container](#using-a-local-docker-container)
### Directly on your development machine
## Directly on your development machine
First set up the environment:
```console
$ export RUBYJQ_USE_SYSTEM_LIBRARIES=1
$ bundle install
```sh
go mod download
```
Run the tests:
```console
$ bundle exec m -r test/charts
```sh
go test ./charts/.../tests
```
### Using Visual Studio Code
## Using Visual Studio Code
Our repo comes with a Visual Studio Code [development container](https://code.visualstudio.com/docs/remote/containers) definition and `launch.json` that allow you to quickly set up an environment in which you can run the tests.
Our repo comes with a Visual Studio Code
[development container](https://code.visualstudio.com/docs/remote/containers)
definition and `launch.json` that allow you to quickly set up an environment
in which you can run the tests.
##### Prerequisites
### Prerequisites
- Visual Studio Code is installed.
- Docker is installed and running.
- The "Remote - Containers" extension is installed and enabled in Visual Studio Code.
- The "Remote - Containers" extension is installed and enabled in Visual Studio
Code.
For more details, please refer to the [official documentation](https://code.visualstudio.com/docs/remote/containers#_system-requirements).
For more details, please refer to the
[official documentation](https://code.visualstudio.com/docs/remote/containers#_system-requirements).
##### Running tests
### Running tests
Once Visual Studio Code is set up, and you open the `charts` workspace, you will see a popup asking if you wish to re-open the workspace in a development container:
Once Visual Studio Code is set up, and you open the `charts` workspace, you
will see a popup asking if you wish to re-open the workspace in a development
container:
![Visual Studio Code development container popup](https://raw.githubusercontent.com/k8s-at-home/charts/master/docs/images/vscode_devcontainer_popup.png)
![Visual Studio Code development container popup](../../assets/screenshots/vscode_devcontainer_popup.png)
Select the option that you prefer. The workspace will be reopened and a Dockerized workspace will be built. You can now use Visual Studio Code as normal.
Select the option that you prefer. The workspace will be reopened and a
Dockerized workspace will be built. You can now use Visual Studio Code as
normal.
To run or debug the unit tests, click the "Run" button on the left sidebar and select the desired configuration:
To run or debug the unit tests, click the "Run" button on the left sidebar
and select the desired configuration:
![Visual Studio Code run configurations](https://raw.githubusercontent.com/k8s-at-home/charts/master/docs/images/vscode_run_unittests.png)
![Visual Studio Code run configurations](../../assets/screenshots/vscode_run_unittests.png)
* _UnitTest - active spec file only_: This configuration will try to run the currently opened test file.
- _stable/common tests_: This configuration will run the all test
files for the `common` library chart.
**Note:** Make sure that you have opened a valid test file (`.rb` files in the `test/charts` folder), or this will not work.
Next, press the green "Play" icon. This will start the tests show the
outcome in a terminal window.
* _UnitTest - all spec files_: This configuration will run the all test files in the `test/charts` folder.
## Using a local Docker container
Next, press the green "Play" icon. This will start the tests show the outcome in a terminal window.
The [Visual Studio Code development container](#using-visual-studio-code)
can also be leveraged without using Visual Studio Code.
### Using a local Docker container
The [Visual Studio Code development container](#using-visual-studio-code) can also be leveraged without using Visual Studio Code.
##### Prerequisites
### Prerequisites
- Docker is installed and running.
- You have the charts repo root folder opened in your shell of choice. The commands in this article assume you are running a Bash-compatible shell.
- You have the charts repo root folder opened in your shell of choice. The
commands in this article assume you are running a Bash-compatible shell.
##### Running tests
### Running tests
The first step is to build the development container image containing the required tools. This step only needs to be done once.
To build the container, run this command in your shell:
The first step is to build the development container image containing the
required tools. This step only needs to be done once. To build the container,
run this command in your shell:
```console
$ docker build -t k8s-at-home/charts-unit-test -f .devcontainer/Dockerfile .
```sh
docker build -t k8s-at-home/charts-unit-test -f .devcontainer/Dockerfile .
```
When you wish to run the tests, run this command in your shell:
```console
$ docker run --rm -it -v $(pwd):/charts --entrypoint "/bin/bash" -w /charts k8s-at-home/charts-unit-test -l -c "bundle exec m -r ./test/charts"
```sh
docker run --rm -it -l \
-v $(pwd):/charts --entrypoint "/bin/bash" \
-w /charts k8s-at-home/charts-unit-test \
-c "go mod download && go test ./charts/.../tests"
```
This will create a container with the charts repo root folder mounted to `/charts` and execute all the test files in the `test/charts` folder.
This will create a container with the charts repo root folder mounted to
`/charts` and execute all the test files belonging to the different charts.
!!! note
Depending on the performance of your environment, this can take a long time
where it seems as if your machine is not doing anything!
## Output
A successful test will output something like the following...
```text
Started with run options --seed 52955
common-test::statefulset volumeClaimTemplates
can set values for volumeClaimTemplates PASS (0.16s)
volumeClaimTemplates should be empty by default PASS (0.06s)
common-test::ports settings
targetPort can be overridden PASS (0.17s)
port name can be overridden PASS (0.17s)
defaults to name "http" on port 8080 PASS (0.16s)
targetPort cannot be a named port PASS (0.05s)
common-test::pod replicas
defaults to 1 PASS (0.08s)
accepts integer as value PASS (0.08s)
common-test::Environment settings
Check no environment variables PASS (0.05s)
set "valueFrom" environment variables PASS (0.11s)
set "static" and "Dynamic/Tpl" environment variables PASS (0.15s)
set "Dynamic/Tpl" environment variables PASS (0.11s)
set "static" environment variables PASS (0.10s)
common-test::ingress
ingress with hosts PASS (0.10s)
should be disabled when ingress.enabled: false PASS (0.06s)
ingress with hosts template is evaluated PASS (0.11s)
ingress with hosts and tls PASS (0.15s)
ingress with hosts and tls templates is evaluated PASS (0.16s)
should be enabled when ingress.enabled: true PASS (0.06s)
common-test::controller type
accepts "daemonset" PASS (0.06s)
accepts "statefulset" PASS (0.06s)
defaults to "Deployment" PASS (0.06s)
Finished in 2.26077s
22 tests, 59 assertions, 0 failures, 0 errors, 0 skips
ok github.com/k8s-at-home/library-charts/charts/stable/common/tests 54.087s
```