Closed ncoghlan closed 7 years ago
Do you want like below thing?
$CUSTOM_DIR/
fedpkg_koji.yml (custom file)
fedora-rawhide-x86_64.cfg (mock configuration file)
Using --mock-config
that is same with mock -r CONFIG
is not enough?
Yep, that's how it works out. I unfortunately can't use the --mock-config
option, as it currently has dependencies on rhpkg and on the use of branch naming scheme that fedpkg/rhpkg knows how to turn into a release tag: https://github.com/sclorg/rpm-list-builder/issues/66
@junaruga While setting CUSTOM_DIR
specifically was very easy to implement locally, I'm wondering if a better upstream API might instead be a feature to pass in environment variables on the command line that are then passed to the custom download and build processes.
Essentially something akin to the way Docker's -e
switch works: https://docs.docker.com/engine/reference/run/#env-environment-variables
Then my particular use case would be a matter of passing -e CUSTOM_DIR=<absolute path>
to the rpmlb
call.
Since the new env var is a single line change and fully addresses my particular use case, I decided to go ahead and submit it as a PR: https://github.com/sclorg/rpm-list-builder/issues/79
Passing arbitrary environment variables may still be useful in the future, but at least in my case, I can equally well use a config file stored next to the custom build configuration file.
@ncoghlan
I'm wondering if a better upstream API might instead be a feature to pass in environment variables on the command line that are then passed to the custom download and build processes.
Yes, I agree with you.
You mean that you want to use docker run -e CUSTOM_DIR=<path>
in our project's .travis.yml
?
@junaruga I filed https://github.com/sclorg/rpm-list-builder/issues/81 as an attempt to better explain what I mean. I'll also add a more concrete example that should hopefully illustrate the concept better.
I've patched rpm-list-builder locally to set an additional
CUSTOM_DIR
variable when running custom download and build commands:This allows other files (such as mock configurations) to be located relative to the custom YAML file rather than relative to the package directory.
If such an addition were to be pushed back upstream, what else would be needed in order to include it?