Infrastructure/infra-docs-fpo
1
0
Fork 0
Code Issues 100 Pull requests 6 Projects Releases Packages Wiki Activity Actions

Review infra-repo SOP

Browse source 
Signed-off-by: Michal Konečný <mkonecny@redhat.com>
This commit is contained in:
Michal Konečný 2021-09-02 15:20:22 +02:00
parent df7cb54128
commit 8716fbb054
2 changed files with 19 additions and 20 deletions
Download patch file Download diff file Expand all files Collapse all files

2
modules/sysadmin_guide/nav.adoc
View file

@ -51,7 +51,7 @@
** xref:infra-git-repo.adoc[Infrastructure Git Repos - SOP] ** xref:infra-git-repo.adoc[Infrastructure Git Repos - SOP]
** xref:infra-hostrename.adoc[Infrastructure Host Rename - SOP] ** xref:infra-hostrename.adoc[Infrastructure Host Rename - SOP]
** xref:infra-raidmismatch.adoc[Infrastructure Raid Mismatch Count - 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:infra-retiremachine.adoc[infra-retiremachine - SOP in review ]
** xref:ipsilon.adoc[ipsilon - SOP in review ] ** xref:ipsilon.adoc[ipsilon - SOP in review ]
** xref:iscsi.adoc[iscsi - SOP in review ] ** xref:iscsi.adoc[iscsi - SOP in review ]

37
modules/sysadmin_guide/pages/infra-repo.adoc
View file

@ -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. netapp and shared via the proxy servers after being built on koji.
For basic instructions, read the standard documentation on Fedora wiki: For basic instructions, read the standard documentation on Fedora wiki:
- https://fedoraproject.org/wiki/Using_the_Koji_build_system - https://fedoraproject.org/wiki/Using_the_Koji_build_system
This document will only outline the differences between the "normal" This document will only outline the differences between the "normal"
@ -13,12 +14,11 @@ repos and the infra repos.
== Contents == Contents
[arabic] * <<_contact_information>>
. Contact Information * <<_building_an_rpm>>
. Building an RPM * <<_tagging_an_existing_build>>
. Tagging an existing build * <<_promoting_a_staging_build>>
. Promoting a staging build * <<_koji_package_list>>
. Koji package list
== Contact Information == Contact Information
@ -27,7 +27,7 @@ Owner::
Contact:: Contact::
#fedora-admin #fedora-admin
Location:: Location::
PHX [53] https://kojipkgs.fedoraproject.org/repos-dist/ https://kojipkgs.fedoraproject.org/repos-dist/
Servers:: Servers::
koji batcave01 / Proxy Servers koji batcave01 / Proxy Servers
Purpose:: Purpose::
@ -37,7 +37,7 @@ Purpose::
Building an RPM for Infrastructure is significantly easier then building Building an RPM for Infrastructure is significantly easier then building
an RPM for Fedora. Basically get your SRPM ready, then submit it to koji 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: Example:
@ -47,35 +47,34 @@ koji build epel7-infra test-1.0-1.el7.infra.src.rpm
.... ....
[NOTE] [NOTE]
.Note
==== ====
Remember to build it for every dist / arch you need to deploy it on. 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 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 signed. The automatic signing system will pick it up and sign the
package for you without any further intervention. You can track when package for you without any further intervention. You can track when
this is done by checking the build info: when it is moved from 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: check this on the web interface (look under "Tags"), or via:
.... ....
koji buildinfo test-1.0-1.el7.infra koji buildinfo test-1.0-1.el7.infra
.... ....
After the build has been tagged into the $repo-infra-stg tag, After the build has been tagged into the `$repo-infra-stg` tag,
tag2distrepo will automatically create a distrepo task, which will `tag2distrepo` will automatically create a distrepo task, which will
update the repository so that the package is available on staging hosts. 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 After this time, you can yum clean all and then install the packages via
yum install or yum update. 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 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 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 respective `infra-candidate` tag. For example, if you have an _epel7_ build
of test2-1.0-1.el7.infra, run: of _test2-1.0-1.el7.infra_, run:
.... ....
koji tag epel7-infra-candidate test2-1.0-1.el7.infra koji tag epel7-infra-candidate test2-1.0-1.el7.infra
@ -87,7 +86,7 @@ applies.
== Promoting a staging build == Promoting a staging build
After getting autosigned, builds will land in the respective infra-stg 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 enabled on staging machines, but not on production. If you decide, after
testing, that the build is good enough for production, you can promote testing, that the build is good enough for production, you can promote
it by running: it by running:
@ -99,8 +98,8 @@ koji move epel7-infra-stg epel7-infra test2-1.0-1.el7.infra
== Koji package list == Koji package list
If you try to build a package into the infra tags, and koji says If you try to build a package into the infra tags, and koji says
something like: BuildError: package test not in list for tag something like: `BuildError: package test not in list for tag
epel7-infra-candidate That means that the package has not been added to 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 list for building in that particular tag. Either add the package to
the respective Fedora/EPEL branches (this is the preferred method, since the respective Fedora/EPEL branches (this is the preferred method, since
we should always aim to get everything packaged for Fedora/EPEL), or add we should always aim to get everything packaged for Fedora/EPEL), or add