(Created page with "Koji maintains repositories of various content types to assist with quickly creating consistent build environments. This page assumes you have read the The supported content t...") |
No edit summary |
||
| Line 3: | Line 3: | ||
* RPMs (via yum repositories) | * RPMs (via yum repositories) | ||
* Java Artifacts (via Maven repositories) | * Java Artifacts (via Maven repositories) | ||
=== Kojira === | |||
All repositories are kept under the <code>/mnt/koji/repos</code> directory on shared storage. They are maintained by the **Kojira** service, which is responsible for regenerating them as needed when the content of a build tag changes (including inheritance changes), and for deleting them when they become stale. | All repositories are kept under the <code>/mnt/koji/repos</code> directory on shared storage. They are maintained by the **Kojira** service, which is responsible for regenerating them as needed when the content of a build tag changes (including inheritance changes), and for deleting them when they become stale. | ||
All repositories are associated with a (build) tag, which in turn is associated with a target. Therefore, all Koji targets have a | All repositories are associated with a (build) tag, which in turn is associated with a target. Therefore, all Koji targets have a yum repository associate with them. Each one has a single repository that is marked as READY in the database, and those that were created earlier (chronologically) are marked as EXPIRED. Once a repository has been expired long enough, Kojira comes along to delete it from the filesystem and mark it DELETED in the database. | ||
Kojira is a standard service that can be started and stopped as necessary, but leaving it running is the recommended practice. Configuration is controlled in the <code>/etc/kojira/kojira.conf</code>. Like the other Koji services it needs auth configuration set up before it can function, and details about that are in the [[/ServerHowTo| Run Your Own Koji Build Server]] page. The two options we will cover here control the lifetimes of the repositories. | Kojira is a standard service that can be started and stopped as necessary, but leaving it running is the recommended practice. Configuration is controlled in the <code>/etc/kojira/kojira.conf</code>. Like the other Koji services it needs auth configuration set up before it can function, and details about that are in the [[/ServerHowTo| Run Your Own Koji Build Server]] page. The two options we will cover here control the lifetimes of the repositories when they are marked EXPIRED. | ||
<code>deleted_repo_lifetime</code> | <code>deleted_repo_lifetime</code> controls the expiry time for unsigned repositories, which are used for normal builds. It accepts a value in seconds, and the default is one week's worth. (604800) Ergo, repositories sit in the EXPIRED state for one week before Kojira deletes them for good. | ||
<code>signed_repo_lifetime</code> controls the expiry time for signed repository of RPM content. These are a new feature in Koji designed to make building images and containers with signed RPMs easier. Like the previous option, the default is one week's worth of seconds. | |||
Koji | === Manually Creating Repositories === | ||
Koji users with the **repo** permission can create repositories manually. To create | |||
=== Maven Repositories === | === Maven Repositories === | ||
Revision as of 19:59, 30 March 2016
Koji maintains repositories of various content types to assist with quickly creating consistent build environments. This page assumes you have read the The supported content types today are:
- RPMs (via yum repositories)
- Java Artifacts (via Maven repositories)
Kojira
All repositories are kept under the /mnt/koji/repos directory on shared storage. They are maintained by the **Kojira** service, which is responsible for regenerating them as needed when the content of a build tag changes (including inheritance changes), and for deleting them when they become stale.
All repositories are associated with a (build) tag, which in turn is associated with a target. Therefore, all Koji targets have a yum repository associate with them. Each one has a single repository that is marked as READY in the database, and those that were created earlier (chronologically) are marked as EXPIRED. Once a repository has been expired long enough, Kojira comes along to delete it from the filesystem and mark it DELETED in the database.
Kojira is a standard service that can be started and stopped as necessary, but leaving it running is the recommended practice. Configuration is controlled in the /etc/kojira/kojira.conf. Like the other Koji services it needs auth configuration set up before it can function, and details about that are in the Run Your Own Koji Build Server page. The two options we will cover here control the lifetimes of the repositories when they are marked EXPIRED.
deleted_repo_lifetime controls the expiry time for unsigned repositories, which are used for normal builds. It accepts a value in seconds, and the default is one week's worth. (604800) Ergo, repositories sit in the EXPIRED state for one week before Kojira deletes them for good.
signed_repo_lifetime controls the expiry time for signed repository of RPM content. These are a new feature in Koji designed to make building images and containers with signed RPMs easier. Like the previous option, the default is one week's worth of seconds.
Manually Creating Repositories
Koji users with the **repo** permission can create repositories manually. To create