#181 A bug in passing on the RPM macros defined in modulemd file
Closed: Invalid by ppisar. Opened by mschorm.

Hello,
I've just created a new module stream 10.9 of my mariadb module.
I've migrated it from the modulemd v2 format to modulemd-packager v3 format.

Here is the source of the module:
https://src.fedoraproject.org/modules/mariadb/blob/10.9/f/mariadb.yaml
requesting build for three Fedora releases; and defining two RPM macros on line 53.

All of the tree Fedora releases, for which the build will be done, share the same source(s), defined on lines 63 and 66.

The MBS started three builds:
https://release-engineering.github.io/mbs-ui/modules
14771, 14772, 14773

The F37 build passed, and by inspecting the build.log , we can verify, that the RPM macros were passed successfully.
The macro I'm talking about is the: %runselftest 0 which is correctly received on line 10 of the mariadb.spec:
https://src.fedoraproject.org/rpms/mariadb/blob/10.9/f/mariadb.spec
and then on line 1180 it controls whther anything at all is being rung in the %check phase, ending on line 1244.

In the build.log of mariadb on F37:
https://koji.fedoraproject.org/koji/getfile?taskID=89791387&volume=DEFAULT&name=build.log&offset=-46000
There is no trace of the testsuite being executed in the %check phase - as expected.

However on F35, the testuite is clearly being run:
https://koji.fedoraproject.org/koji/getfile?taskID=89792191&volume=DEFAULT&name=build.log&offset=-153500
and it is the cause of the build failure on every architecture.


I'll try to duplicate the

    buildopts:
      rpms:
        macros: |
          %runselftest 0
          %ignore_testsuite_result 1

code to every context.

Sadly, there is no way to test such changes.
I can't submit a module scratch build without pushing the code to the production ... which leads to me pushing to the production random bits of code and fixups just to see if it will change anything ...

buildopts section is specific to a context where it is located. If you want to apply the macros to all contexts, you need to duplicate the section into each context. I know it's tedious, I planned adding a top-level buildopts which would inherit, but the plan ceased on changes required in MBS. MBS is in maintenance mode, i.e. no new features.

You can scratch-build changes without pushing the code into dist-git server: fedpkg module-scratch-build --file my_local.yaml. Though you will also need to specify module and stream with --optional because your YAML document does not specify them.

Metadata Update from @ppisar:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

Metadata