mock-rpm's Introduction

Mock RPM Action

This GitHub Action provides a friendly interface for building RPMs using Mock.

For building source RPMs (SRPMs) please see the jw3/mock-srpm action.

Example workflow

name: build
on: [push, pull_request]

jobs:
  rpm:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: jw3/mock-srpm@v1
        with:
          chroot: fedora-39-x86_64
          spec: test/simple/simple.spec
      - uses: jw3/mock-rpm@v1
        with:
          chroot: fedora-39-x86_64
          srpm: simple-*.src.rpm

Inputs

Name	Required	Default	Description
chroot	Y		Mock chroot id (list)
srpm	Y		Path to the src rpm
cache	N		Enable chroot environment caching
image	N	`fedora:latest`	Container image for Mock execution
debug	N		Show rpmbuild logs on success (auto on-fail)
result-dir	Y	`github.workspace`	Target path for writing build artifacts

Caching

Using actions/cache to persit the Mock chroot, via the root_cache plugin, is enabled by default.

Also cached is the container image, but only when mock has been installed by this action.

To enable caching set the cache property to 'true'

About Mock

Mock is used by the Fedora Build system to populate a chroot environment, which is then used in building a source-RPM (SRPM). It can be used for long-term management of a chroot environment, but generally a chroot is populated (using DNF), an SRPM is built in the chroot to generate binary RPMs, and the chroot is then discarded.

https://github.com/rpm-software-management/mock

License

MIT

mock-rpm's People

Contributors

Watchers

mock-rpm's Issues

Can shell be defaulted?

Saw this for a regular workflow...

defaults:
  run:
    shell: bash

Default result-dir may conflict with working-directory

Defaulting result-dir to github.workspace may have unexpected results when paired with working-directory.

Orginally the result-dir was set to ., which may be a better choice.

Specify mock config

Allow a mock cfg file to be passed in.

Use fedora:stable for default image

Add option to run a preconfigured Docker Image to bypass all of the DNF mock installation

It takes quite a bit of time and bandwidth to install mock. Could this action be updated so that it could use a pre-configured Docker image with the mock stuff already installed so that all of the repetitive downloads aren't necessary? I've got several, very small SPEC files that take about 10 seconds to build but it takes about three minutes just to build the mock environment. The vast majority of this time is initializing the mock environment.

Perhaps fedora:latest could be a variable and then logic surrounding the initialization and configuration of mock could be bypassed in the event that (for example) ${mock_container} is defined.