[REQUEST] Option to include a config file (for FPM, not for package)

[akamensky]

Use case:

I am building many packages, which suppose to share some of the arguments, such as URL, Maintainer etc.

Many other arguments change (such as -t, -s etc).

Right now without this option the command is incredibly long.

Thus the idea is to have option such as --include file where file could be JSON or YAML or INI and where I could place shared data such as above. It would not override options on CLI, but rather extend them or possible that CLI arguments to override config file settings (many tools do that, for example Ansible comes first to my mind)

So the full command could look like:

fpm -s dir -t rpm -n some-package -v 1.0.0 --include fpm-settings.json mydir/

[hatt]

Does putting the flags on separate lines in a file called .fpmrc in your CWD work? We don't really have a flag precedence model the way Ansible does and that's currently the closest there is available. A proper syntax and precedence sounds nice though.

[akamensky]

@hatt Unfortunately that does not work for me because I am using Jenkins for building packages. It is going to be 100s of separate CWDs.

In this case solution would be either $HOME/.fpmrc (judging from your message it uses CWD instead of HOME, so it won't work) or much better solution is the one I proposed.

With my solution I can supply that file as a separate repository (Jenkins will fetch them recursively) so on each build it will fetch latest file for config. Unfortunately that won't work for CWD, because first level directory (.) cannot refer to another repo.

[hatt]

You can have the file in your $HOME as well. After checking the code, it looks like it's been renamed to just .fpm and the order of precedence is $HOME/.fpm; $CWD/.fpm so it will check your home directory first. There is also an FPMOPTS env var you can set in your build config.

See lib/fpm/command.rb#L523 for more information.

[akamensky]

Got it.

Still ugly solution, because will not be applied automatically in case if I move server or start using cluster of Jenkins servers. I will need to go and manually add this in JENKINS_HOME.

I would suggest considering a command line argument for config file inclusion.

[hatt]

Good feature idea for sure. If you use the job builder plugin or something, the ENV var option may be better as you can build it into the templates or jobs. Configuration management should be able to assist in setting up new servers with the settings but either is not so ideal.

Personally I store a file in my app repo itself so that each job can inherit the options required but there is definitely a level of copied info in each project.