|
4 | 4 | 
|
5 | 5 |
|
6 | 6 | # Parse features lib
|
7 |
| -This library helps you to work with the gardenlinux/features folder. It parses all info.yamls and builds a tree. |
8 | 7 |
|
9 |
| -Features (planned): |
10 |
| -* validate CNAMEs |
11 |
| -* validate info.yamls |
12 |
| -* Deduct dependencies from cname_base |
| 8 | +This library includes tooling to build and distribute [Garden Linux](https://github.com/gardenlinux/gardenlinux). |
| 9 | + |
| 10 | +Features: |
| 11 | + |
| 12 | +- compare APT repositories |
| 13 | +- parse features |
| 14 | +- parse flavors |
| 15 | +- push OCI artifacts to a registry |
13 | 16 |
|
14 | 17 | ## Quickstart
|
| 18 | + |
| 19 | +### Example: get a list of features for a given cname |
| 20 | + |
15 | 21 | **Inclusion via poetry**:
|
16 | 22 |
|
17 |
| -`parse_features_lib = { git = "https://github.com/gardenlinux/parse_features_lib", rev="main" }` |
| 23 | +`gardenlinux = { git = "https://github.com/gardenlinux/python_gardenlinux_lib", rev="0.6.0" }` |
| 24 | + |
18 | 25 | ```python
|
19 |
| -import parse_features_lib |
| 26 | +from gardenlinux.features import Parser |
| 27 | + |
| 28 | +feature_list = Parser().filter_as_list("aws-gardener_prod") |
| 29 | +for feature in feature_list: |
| 30 | + print(feature, info["oci_artifacts"]) |
| 31 | +``` |
| 32 | + |
| 33 | +## Developer Documentation |
| 34 | + |
| 35 | +The library is documented with docstrings, which are used to generate the developer documentation available [here](https://gardenlinux.github.io/python-gardenlinux-lib/). |
| 36 | + |
| 37 | +## Push OCI artifacts to a registry |
20 | 38 |
|
21 |
| -if __name__ == "__main__": |
22 |
| - # Step 1: parse the "features directory" and get the full graph containing all features |
23 |
| - all_features = parse_features_lib.read_feature_files("features") |
| 39 | +this tool helps you to push oci artifacts. |
24 | 40 |
|
25 |
| - # Step 2: supply desired features and get all their dependencies |
26 |
| - dependencies = parse_features_lib.filter_graph(all_features, {"gardener", "_prod", "server", "ociExample"}) |
| 41 | +### Installation |
27 | 42 |
|
28 |
| - # Step 3: play with the retrieved data. |
29 |
| - for feature, info in dependencies.nodes(data="content"): |
30 |
| - if "oci_artifacts" in info: |
31 |
| - print(feature, info["oci_artifacts"]) |
| 43 | +```bash |
| 44 | +git clone https://github.com/gardenlinux/python-gardenlinux-lib.git |
| 45 | +mkdir venv |
| 46 | +python -m venv venv |
| 47 | +source venv/bin/activate.sh |
| 48 | +poetry install |
| 49 | +gl-oci --help |
32 | 50 | ```
|
33 | 51 |
|
34 |
| -## Developer Documentation |
35 |
| -The library is documented with docstrings, which are used to generate the developer documentation available [here](https://gardenlinux.github.io/python-gardenlinux-lib/). |
| 52 | +### Usage |
| 53 | + |
| 54 | +The process to push a Gardenlinux build-output folder to an OCI registry is split into two steps: In the first step all files are pushed to the registry and a manifest that includes all those pushed files (layers) is created and pushed as well. An index entry that links to this manifest is created offline and written to a local file but not pushed to any index. This push to an index can be done in the second step where the local file containing the index entry is read and pushed to an index. The seperation into two steps was done because pushing of manifests takes long and writes to dedicated resources (possible to run in parallel). Updating the index on the other hand is quick but writes to a share resource (not possible to run in parallel). By splitting the process up into two steps it is possible to run the slow part in parallel and the quick part sequentially. |
| 55 | + |
| 56 | +#### 1. Push layers + manifest |
| 57 | + |
| 58 | +To push layers you have to supply the directory with the build outputs `--dir`. Also you have to supply cname (`--cname`), architecture `--arch` and version `--version` of the build. This information will be included in the manifest. You have to supply an endpoint where the artifacts shall be pushed to `--container`, for example `ghcr.io/gardenlinux/gardenlinux`. You can disable enforced HTTPS connections to your registry with `--insecure True`. You can supply `--cosign_file <filename>` if you want to have the hash saved in `<filename>`. This can be handy to read the hash later to sign the manifest with cosign. With `--manifest_file <filename>` you tell the program in which file to store the manifests index entry. This is the file that can be used in the next step to update the index. You can use the environment variable GL_CLI_REGISTRY_TOKEN to authenticate against the registry. Below is an example of a full program call of `push-manifest` |
| 59 | + |
| 60 | +```bash |
| 61 | +GL_CLI_REGISTRY_TOKEN=asdf123 gl-oci push-manifest --dir build-metal-gardener_prod --container ghcr.io/gardenlinux/gl-oci --arch amd64 --version 1592.1 --cname metal-gardener_prod --cosign_file digest --manifest_file oci_manifest_entry_metal.json |
| 62 | +``` |
36 | 63 |
|
| 64 | +#### 2. Update index with manifest entry |
| 65 | + |
| 66 | +Parameters that are the same as for `push-manifest`: |
| 67 | + |
| 68 | +- env-var `GL_CLI_REGISTRY_TOKEN` |
| 69 | +- `--version` |
| 70 | +- `--container` |
| 71 | +- `--manifest-file` this time this parameter adjusts the manifest entry file to be read from instead of being written to |
| 72 | + |
| 73 | +A full example looks like this: |
| 74 | + |
| 75 | +```bash |
| 76 | +GL_CLI_REGISTRY_TOKEN=asdf123 gl-oci update-index --container ghcr.io/gardenlinux/gl-oci --version 1592.1 --manifest_file oci_manifest_entry_metal.json |
| 77 | +``` |
0 commit comments