Review infra-repo SOP
Signed-off-by: Michal Konečný <mkonecny@redhat.com>
This commit is contained in:
parent
df7cb54128
commit
8716fbb054
2 changed files with 19 additions and 20 deletions
|
@ -51,7 +51,7 @@
|
|||
** xref:infra-git-repo.adoc[Infrastructure Git Repos - SOP]
|
||||
** xref:infra-hostrename.adoc[Infrastructure Host Rename - SOP]
|
||||
** xref:infra-raidmismatch.adoc[Infrastructure Raid Mismatch Count - SOP]
|
||||
** xref:infra-repo.adoc[infra-repo - SOP in review ]
|
||||
** xref:infra-repo.adoc[Infrastructure Yum Repo - SOP]
|
||||
** xref:infra-retiremachine.adoc[infra-retiremachine - SOP in review ]
|
||||
** xref:ipsilon.adoc[ipsilon - SOP in review ]
|
||||
** xref:iscsi.adoc[iscsi - SOP in review ]
|
||||
|
|
|
@ -6,6 +6,7 @@ the RHEL RPMs). Rebuilds go into this repo which are stored on the
|
|||
netapp and shared via the proxy servers after being built on koji.
|
||||
|
||||
For basic instructions, read the standard documentation on Fedora wiki:
|
||||
|
||||
- https://fedoraproject.org/wiki/Using_the_Koji_build_system
|
||||
|
||||
This document will only outline the differences between the "normal"
|
||||
|
@ -13,12 +14,11 @@ repos and the infra repos.
|
|||
|
||||
== Contents
|
||||
|
||||
[arabic]
|
||||
. Contact Information
|
||||
. Building an RPM
|
||||
. Tagging an existing build
|
||||
. Promoting a staging build
|
||||
. Koji package list
|
||||
* <<_contact_information>>
|
||||
* <<_building_an_rpm>>
|
||||
* <<_tagging_an_existing_build>>
|
||||
* <<_promoting_a_staging_build>>
|
||||
* <<_koji_package_list>>
|
||||
|
||||
== Contact Information
|
||||
|
||||
|
@ -27,7 +27,7 @@ Owner::
|
|||
Contact::
|
||||
#fedora-admin
|
||||
Location::
|
||||
PHX [53] https://kojipkgs.fedoraproject.org/repos-dist/
|
||||
https://kojipkgs.fedoraproject.org/repos-dist/
|
||||
Servers::
|
||||
koji batcave01 / Proxy Servers
|
||||
Purpose::
|
||||
|
@ -37,7 +37,7 @@ Purpose::
|
|||
|
||||
Building an RPM for Infrastructure is significantly easier then building
|
||||
an RPM for Fedora. Basically get your SRPM ready, then submit it to koji
|
||||
for building to the $repo-infra target. (e.g. epel7-infra).
|
||||
for building to the `$repo-infra` target. (e.g. `epel7-infra`).
|
||||
|
||||
Example:
|
||||
|
||||
|
@ -47,35 +47,34 @@ koji build epel7-infra test-1.0-1.el7.infra.src.rpm
|
|||
....
|
||||
|
||||
[NOTE]
|
||||
.Note
|
||||
====
|
||||
Remember to build it for every dist / arch you need to deploy it on.
|
||||
====
|
||||
|
||||
After it has been built, you will see it's tagged as
|
||||
$repo-infra-candidate, this means that it is a candidate for being
|
||||
`$repo-infra-candidate`, this means that it is a candidate for being
|
||||
signed. The automatic signing system will pick it up and sign the
|
||||
package for you without any further intervention. You can track when
|
||||
this is done by checking the build info: when it is moved from
|
||||
$repo-infra-candidate to $repo-infra-stg, it has been signed. You can
|
||||
`$repo-infra-candidate` to `$repo-infra-stg`, it has been signed. You can
|
||||
check this on the web interface (look under "Tags"), or via:
|
||||
|
||||
....
|
||||
koji buildinfo test-1.0-1.el7.infra
|
||||
....
|
||||
|
||||
After the build has been tagged into the $repo-infra-stg tag,
|
||||
tag2distrepo will automatically create a distrepo task, which will
|
||||
After the build has been tagged into the `$repo-infra-stg` tag,
|
||||
`tag2distrepo` will automatically create a distrepo task, which will
|
||||
update the repository so that the package is available on staging hosts.
|
||||
After this time, you can yum clean all and then install the packages via
|
||||
yum install or yum update.
|
||||
|
||||
== Tagging existing builds
|
||||
== Tagging an existing build
|
||||
|
||||
If you already have a real build and want to use it in the
|
||||
infrastructure before it has landed in stable, you can tag it into the
|
||||
respective infra-candidate tag. For example, if you have an epel7 build
|
||||
of test2-1.0-1.el7.infra, run:
|
||||
respective `infra-candidate` tag. For example, if you have an _epel7_ build
|
||||
of _test2-1.0-1.el7.infra_, run:
|
||||
|
||||
....
|
||||
koji tag epel7-infra-candidate test2-1.0-1.el7.infra
|
||||
|
@ -87,7 +86,7 @@ applies.
|
|||
== Promoting a staging build
|
||||
|
||||
After getting autosigned, builds will land in the respective infra-stg
|
||||
tag, for example epel7-infra-stg. These tags go into repos that are
|
||||
tag, for example `epel7-infra-stg`. These tags go into repos that are
|
||||
enabled on staging machines, but not on production. If you decide, after
|
||||
testing, that the build is good enough for production, you can promote
|
||||
it by running:
|
||||
|
@ -99,8 +98,8 @@ koji move epel7-infra-stg epel7-infra test2-1.0-1.el7.infra
|
|||
== Koji package list
|
||||
|
||||
If you try to build a package into the infra tags, and koji says
|
||||
something like: BuildError: package test not in list for tag
|
||||
epel7-infra-candidate That means that the package has not been added to
|
||||
something like: `BuildError: package test not in list for tag
|
||||
epel7-infra-candidate`. That means that the package has not been added to
|
||||
the list for building in that particular tag. Either add the package to
|
||||
the respective Fedora/EPEL branches (this is the preferred method, since
|
||||
we should always aim to get everything packaged for Fedora/EPEL), or add
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue