#3952 Explanation for build_rpm policy
Opened a year ago by tkopecek. Modified a year ago
tkopecek/koji issue3951  into  master

@@ -134,8 +134,11 @@ 

  * ``build_rpm``: control whether builds are allowed, this is superceding older

                   ``build_from_srpm`` to handle all task types. ``build_from_srpm``

                   and ``build_from_repo_id`` are now deprecated and will be removed

-                  when py2 support will be dropped (rhel6 builders).

-                  Default policy allows everything.

+                  when py2 support will be dropped (rhel6 builders). In the interim

+                  set up them as ``allow :: all`` and all requested logic place

+                  into build_rpm policy instead. The first two policies can disappear

+                  in some new release, so it is not good practice to rely on them.

+                  Default ``build_rpm`` policy allows everything.

  * ``build_from_srpm``: checked when a build from srpm (not an SCM reference) is

    requested.

  * ``build_from_scm``: checked when a build task from SCM is executing on builder

rebased onto db522d7

a year ago

Metadata Update from @tkopecek:
- Pull-request tagged with: doc, no_qe

a year ago

Looking this over, it seems like we need a better story for managing these rules before we can consider these older policies deprecated. For that matter, it would be quite natural for an admin to want to manage the from_srpm and repo_id cases as sub policies for readability. So we might not want to remove them entirely.

Also, the build_rpm is already mis-named as it is checked for image builds, yet this falls short of "control whether builds are allowed ... to handle all task types".