#51 Describe Koji module builds
Merged 5 years ago by asamalik. Opened 5 years ago by jkaluza.
fedora-docs/ jkaluza/modularity cg-builds  into  master

@@ -28,13 +28,30 @@ 

  

  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 @@ 

  ----

  

  * `STRATEGY` — name of a specific build strategy (listed above)

+ 

no initial comment

Pull-Request has been merged by asamalik

5 years ago
Metadata