Github
:github:for-each-release
Iterate over recent X github releases and execute a task.
Examples:
# build all versions of File Repository that matches tags v{NUMBER} eg. v3.0.0
# for each version execute: rkd :build --version=%MATCH_0% (it can be any command)
rkd :github:for-each-release \
--repository=riotkit-org/file-repository \
--exec 'rkd :build --version=%MATCH_0%' \
--dest-docker-repo quay.io/riotkit/file-repository \
--allowed-tags-regexp 'v([0-9.]+)'Class name to import: rkt_ciutils.github.ForEachGithubReleaseTask [see how to import]
:github:find-closest-release
Finds a release number closest to specified.
Examples:
rkd :github:find-closest-release --repository riotkit-org/file-repository -c 1.3Class name to import: rkt_ciutils.github.FindClosestReleaseTask [see how to import]
:docker:tag-exists
Checks if a docker image has a tag. Requires docker client, daemon and permissions to the daemon.
Examples:
# will result in a success
sudo rkd :docker:tag-exists -i alpine:latest
# will result in a failure
sudo rkd :docker:tag-exists -i alpine:not-existingClass name to import: rkt_ciutils.docker.DockerTagExistsTask [see how to import]
Docker
:docker:extract-envs-from-dockerfile
Extract list of environment variables, their descriptions and example values from a Dockerfile.
rkd :docker:extract-envs-from-dockerfile -f ~/Projekty/riotkit/riotkit/docker-taiga/Dockerfile --format bash_sourceClass name to import: rkt_ciutils.docker.ExtractEnvsFromDockerfileTask [see how to import]
:docker:generate-readme
Generates a README.md file from README.md.j2 template, considering environment variables from a Dockerfile.
rkd :docker:generate-readme --template docker-taiga/README.md.j2 --dockerfile docker-taiga/Dockerfile#### Configuration reference
List of all environment variables that could be used.
{% for env_var, attrs in DOCKERFILE_ENVS.items() %}{% if attrs[2] %}# {{ attrs[2] }}{% endif %}
- {{ attrs[0] }} # (default: {{ attrs[1] }})
{% endfor %}Class name to import: rkt_ciutils.docker.GenerateReadmeTask [see how to import]
Boat-CI
Provides Continuous Integration tasks designed to build docker images. Boat-CI is focusing on packaging existing applications, that are released on Github in separate repositories. The CI is customizable with environment variables and commandline switches.
Example scenario:
GIVEN we have project taigaio/taiga-back that is a backend application
AND there is a separate frontend application at taigaio/taiga-front-dist
AND we have THIS Boat-CI repository named riotkit-org/taiga-docker
WHEN we want to build docker image for each new release of Taiga (backend + frontend is a complete setup)
THEN on each pushed tag in riotkit-org/taiga-docker we run Boat-CI to produce images eg. taiga:5.0.1-D1.0, taiga:4.9-D1.0Concept:
The CI+Dockerfile is placed in a separate repository (application is in a separate repository, probably it can be configured differently)
SNAPSHOT on master/commit is a tag in the docker registry that overwrites all the time eg. taiga:4.1.5-SNAPSHOT, taiga:4.1.6-SNAPSHOT (SNAPSHOT means that CI+docker version is LATEST for given application version)
[customization] SNAPSHOT can consider ci+docker next version eg. taiga:4.1.5-D1.0.1-SNAPSHOT by using –dev-version-template=”%MATCH_0%-D%NEXT_VERSION%-SNAPSHOT”
SNAPSHOT tags are not propagated by default, so no 1.0.1 -> 1.0 -> 1 -> latest re-tagging of docker image
Naming convention:
TAG is the CI+Dockerfile repository git tag, not application repository tag
Application version is the tag in application repository
Example:
version: org.riotkit.rkd/yaml/v1
imports:
- rkd_python
- rkt_utils.docker
- rkt_ciutils.boatci
tasks:
:build-all-versions:
description: Build all versions of Taiga
arguments:
"--commit-msg":
required: True
steps: |
export GITHUB_REPOSITORY=taigaio/taiga-back
export ALLOWED_TAGS_REGEXP="([0-9\.]+)$"
export DEST_DOCKER_REPO=quay.io/riotkit/taiga
# == OPTIONAL, ADVANCED EXAMPLE ==
# Given we build backend from taigaio/taiga-back
# and the frontend is in separate repository - we try to find closest version of frontend
# to match our backend eg. 5.0.1 backend + 5.0.0 frontend (frontend didn't get the patch version released yet)
export DOCKER_BUILD_OPTS="--build-arg FRONTEND_VERSION=%FIND_CLOSEST_RELEASE(taigaio/taiga-front-dist)%"
echo " > Starting CI"
rkd --no-ui :boat-ci:process \
--commit-message="${ARG_COMMIT_MSG}":boat-ci:process
Takes incoming request from the CI.
Responsibility:
Decide about the destination version number and format
Decide if we REBUILD existing tags or not (release enforces this)
Behavior:
When “@force-rebuild” in commit message, then rebuild existing images (in case of “moving tags” - bad practice, but can happen, we handle such emergency case)
When “@force-rebuild-last-tag” is in commit message, rebuild previous tag’s images, warning: dangerous, use with caution
When is on TAG in current docker repository - build last X versions of application, set double version (app + docker)
When is on branch/commit in current docker repository - build a snapshot of last X versions of application #TODO VERIFY
1 maintainer
Metadata
1 maintainer
Release files for rkt-ciutils 3.0.4
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| rkt_ciutils-3.0.4.tar.gz | 12.5 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| rkt_ciutils-3.0.4-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 26.3 kB
Release files / rkt_ciutils-3.0.4.tar.gz
| Download URL | rkt_ciutils-3.0.4.tar.gz |
|---|---|
| Size | 12.5 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
3e07b4851dd1dd353d8c1846df92968ef64a5ebb39874cecf3c28ff5e1283e51
|
|
BLAKE2b-256 checksum How to use checksums |
bb609e26ef9c7c53f910943b45e66fe5fbcabac63498e3bc275b4262f33aaaf4
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/3.1.1 pkginfo/1.6.1 requests/2.25.0 setuptools/50.3.2 requests-toolbelt/0.9.1 tqdm/4.54.1 CPython/3.8.0
|
Release files / rkt_ciutils-3.0.4-py3-none-any.whl
| Download URL | rkt_ciutils-3.0.4-py3-none-any.whl |
|---|---|
| Size | 13.9 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
ab7b7ef085aa18bf3aca61794a8d1926335d26edb8fcc63789bfe721e425c385
|
|
BLAKE2b-256 checksum How to use checksums |
272c1cf0ffd766df7cd758b19684602b332a8f6bec7a8675352d2676e183782a
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/3.1.1 pkginfo/1.6.1 requests/2.25.0 setuptools/50.3.2 requests-toolbelt/0.9.1 tqdm/4.54.1 CPython/3.8.0
|
Security for rkt-ciutils 3.0.4
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.
