- Python 97.6%
- Shell 1.9%
- Jinja 0.5%
|
All checks were successful
Red Hat Konflux / flatpak-build-on-pull-request Success
Red Hat Konflux / flatpak-build-on-push Success
Red Hat Konflux / build-enterprise-contract / flatpak-build Integration test for component flatpak-build snapshot build-20260715-130747-000 and scenario build-enterprise-contract has passed
The Konflux CI pipeline has been broken since the platform migrated from a shared "appstudio-pipeline" service account to component-specific service accounts. The old pipeline also used a custom build-pipeline.yaml with stale task bundle digests from 2024. Switch to the standard docker-build-multi-platform-oci-ta pipeline resolved from the Konflux tekton-catalog bundle, and add the required taskRunTemplate.serviceAccountName for the component-specific SA. This eliminates the need for a locally maintained build-pipeline.yaml. Assisted-by: Cursor |
||
|---|---|---|
| .tekton | ||
| .vscode | ||
| flatpak_container_tools | ||
| tests | ||
| tools | ||
| .flake8 | ||
| .gitignore | ||
| Dockerfile.c9s | ||
| Dockerfile.rhel9 | ||
| flatpak-container-tools.spec | ||
| LICENSE | ||
| LICENSE.gplv3 | ||
| MANIFEST.in | ||
| OWNERS | ||
| pyproject.toml | ||
| README.md | ||
| requirements-build.txt | ||
| requirements.txt | ||
| tox.ini | ||
About
flatpak-container-tools is a set of command line tools (mostly accessed via a single 'flatpak-container' executable) for operations related to maintaining Flatpak applications and runtimes as OCI containers built from RPMs.
flatpak-container build-container
Creates a OCI container of an Flatpak application or runtime from packages downloaded from Koji or in a local repository.
Usage: flatpak-container [global options] build-container [--install] [--containerspec=somedir/container.yaml] [--flatpak-metadata=labels/annotations/both] [--target=some-koji-target]
--install automatically install the resulting Flatpak or runtime systemwide
--containerspec
path to container.yaml - defaults to ./container.yaml
--flatpak-metadata
how flatpak metadata should be stored. Defaults to both. Using
only labels require Flatpak >= 1.6.
--target Koji target to build against. Determined from runtime_version if missing.
flatpak-container install
Installs a Flatpak or Runtime built as an OCI bundle for the current user. If it doesn't
already exist, a flatpak-container-tools remote is added to the Flatpak's user configuration.
Usage: flatpak-container [global options] install [PATH-or-URL]
--koji Look up argument as NAME[:STREAM] in Koji, instead of a path or an URL, and install the latest Flatpak build that matches.
global options
--verbose/v Show verbose debugging output
--config/c Additional configuration file to read
--profile/p
Alternate configuration profile to use. Default is production. The standard config file
for flatpak-container-tools defines production and staging, which result in using the
Fedora production and staging environments, respectively.
Configuration
Configuration is read from the following sources, in descending order of priority:
- Any config file specified on the comand line, first has highest priority
~/.config/flatpak-container/config.d/*.yaml, sorted alphabetically~/.config/flatpak-container/config.yaml/etc/flatpak-container/config.d/*.yaml, sorted alphabetically/etc/flatpak-container/config.yamlconfig.yamlin the Python installation directory of flatpak-container-tools
A config file looks like:
profiles:
profile_name:
# Koji config file; leave blank to use standard files in /etc and ~/.koji
koji_config: null
koji_profile: koji
# Different koji instance used for sources when rebuilding RPMs; if both
# are unset, koji_config/koji_profile is used.
source_koji_config: null
source_koji_profile: null
# Target used to build Flatpak application RPMs (prefix=/app rebuilds)
rpm_koji_target: f$release-flatpak-app
# Target used to build Flatpak containers
flatpak_koji_target: f$release-flatpak-candidate
# Tag used to get source for rebuilding RPMs locally;; refers to
# source_koji_config/source_koji_profile if those are set.
source_koji_tag: f$release-build
(normally, it won't be necessary to set all these values.) The profile name __default__ provides defaults that
are used if a particular profile doesn't have a key.
Development
You can use tox to setup a local environment for testing:
tox -e dev
. .venv/bin/activate
Subsequently, you just need . .venv/bin/activate unless your dependencies change.
Note that certain dependencies (libsolv, rpm) can't meaningfully be installed in a virtual environment, so the devenv is a "site-packages" virtual environment.
Release process
- Create a signed tag (
git tag -s -m "Version 0.9.3" v0.9.3) - Make a source tarball (
pyproject-build -s) - Push tag and any commits (
git push origin --tags main) - Upload source to PyPI (
twine upload dist/flatpak-container-tools-0.9.3.tar.gz) - Create updated packages for current Fedora releases and EPEL
- File Bodhi updates as necessary
LICENSE
flatpak-container-tools-depchase is licensed under the terms of the GNU General Public License, version 3 or later. See the LICENSE.gplv3 file for details.
The rest of flatpak-container-tools is licensed under the MIT license. See the LICENSE file for details.