From 597faa05305b2937a37bf0dd9e70b1ec3386001b Mon Sep 17 00:00:00 2001
From: Jan Kaluža <jkaluza@redhat.com>
Date: Feb 20 2019 07:00:13 +0000
Subject: Describe Koji module builds


---

diff --git a/modules/ROOT/pages/making-modules/building-modules.adoc b/modules/ROOT/pages/making-modules/building-modules.adoc
index 592e3c8..29075f1 100644
--- a/modules/ROOT/pages/making-modules/building-modules.adoc
+++ b/modules/ROOT/pages/making-modules/building-modules.adoc
@@ -28,13 +28,30 @@ You can also watch the build(s) on Fedora Module build service:
 
 https://release-engineering.github.io/mbs-ui/modules
 
+== Module build results
+
+All the packages built in the module are tagged in Koji tag named as ``module-$name-$stream-$version-$context``. The link to this tag is also available in Fedora Module build service UI mentioned earlier.
+
+There are also two Koji Builds representing single module build.
+
+* ``$name-$stream-$version.$context`` - Contains the metadata with final RPMs which will be included in a compose and will be therefore visible by the end user.
+* ``$name-devel-$stream-$version.$context`` - Contains the metadata with filtered RPMs which are not normally visible to end user, but might be sometimes useful when building other packages against the module. Generally, in Fedora we do not ship the -devel modules.
+
+NOTE: You will not find ``$name-devel`` module build in Module Build Service, because this is only another representation of non-devel module build. It is not separate module build on its own and it only exists as Koji build.
+
+Both Koji module builds contains various metadata files:
+
+- ``modulemd.src.txt`` - The unchanged input modulemd metadata used to build a module as stored in dist-git.
+- ``modulemd.txt`` - The expanded modulemd metadata which was used by Module Build Service to build this particular module. This for example contains the right build requirements based on the Module Stream Expansion.
+- ``modulemd.$arch.txt`` - The per-architecture modulemd metadata listing the RPMs which will end up in a compose and therefore be visible to end user. This for example respects filters or multilib modulemd options.
+
 == Rebuild strategies
 
 In case you want to control which packages get rebuilt and which get reused, you can enforce a specific rebuild strategy while submitting a build.
 
 There are different rebuild strategies to choose from:
 
-* ``all`` — All packages in the module get rebuilt.
+* ``all`` — All packages in the module get rebuilt.
 * ``only-changed`` — Only packages that have changed since the last successful build get rebuilt. This is the **default** in Fedora.
 * ``changed-and-after`` — This one leverages xref:making-modules/defining-modules.adoc#_building_in_a_specific_order_optional[build groups (buildorder)]. Packages that have changed since the last successful build get rebuilt, and also all packages with a buildorder higher than any of the changed ones get rebuilt as well.
 
@@ -45,3 +62,4 @@ $ fedpkg module-build --optional rebuild_strategy=STRATEGY
 ----
 
 * `STRATEGY` — name of a specific build strategy (listed above)
+