Repository navigation
Conversation
|
A few things I'm curious about:
|
|
This is very draft level. As you can see there's an if/else. I intend to expand that so it can also build gemspecs into gems. I imagine we can also detect setup.py to build python tarballs and/or wheels. We may need configuration since some packages have multiple gemspecs. I haven't thought about dependencies. Some thing I do wonder about is the |
|
Gemspec building still needs some stderr handling. This requires theforeman/foreman-installer#332 and theforeman/foreman#6576. As you can see I've handled the multiple gemspecs by using the directory name. This means we can clone and create a symlink for the core package. |
What does this mean for us going forward? How are you imagining this would be used? |
|
I'm not entirely sure, but I'm thinking about expanding the package manifest. One example is https://github.com/theforeman/foreman_ansible which has two gemspecs. If no directory is given it's the basename of the git repository (as git clone normally also does), possibly stripping packages:
hosts:
rubygem-foreman_ansible:
source:
git: https://github.com/theforeman/foreman_ansible
rubygem-foreman_ansible_core:
source:
git: https://github.com/theforeman/foreman_ansible
directory: foreman_ansible_coreThen we need some directive to enter build-from-source mode. I thought about passing in |
Currently we have a tito extension in foreman-packaging. The idea is expand this module to replace that and support building just by pointing at a git checkout. This is easy for development but also makes it easy to write a Jenkins job to build a scratch build of a PR.