>>>> new release of hammer_cli_foreman_tasks completed today. version 0.0.4 is
>>>> out in the wild.
>>>>
>>>> hammer_cli_foreman_tasks-0.0.4 has been pushed to
>>>> https://rubygems.org/gems/hammer_cli_foreman_tasks
>>>>
>>>> rubygem_hammer_cli_foreman_tasks-0.0.4-1.el{6,7}.rpm is also built on
>>>> koji.katello.org in katello-nightly as well as katello-2.2
>>>> http://koji.katello.org/koji/packageinfo?packageID=657
>>>
>>> This should be submitted to foreman-plugins, like foreman-tasks itself
>>> is, not built as part of Katello.
>>
>> +1000000000000, thanks
>>
>> Both foreman_chef and foreman_salt use foreman_tasks as well.
>>
>> I really wish we'd revisit the topic of using foreman-packaging for all
>> katello packages, or least doing something similar. I don't think
>> the way we have things organized makes any sense at all.
>>
>
> I would like to revisit that topic as well, though i feel that foreman-packaging + current jenkins implementation is overly complicated.
> I don't see a problem with having specfiles (and deb, or any other package manager spec) living in their respective code repositories.
> Having the spec live with the project makes it trivial to quickly build a local package if need be, or even to build a package in koji if i need to.
> And because everything lives together in one repository, you can still setup automated tool around it.
I've mentioned my reasons for this in my first reply.
You might feel this works for one package built for only two OSes at the
micro level, but it doesn't scale at all.
And to add to Eric's point about variation of spec files, the fact that
the spec file you committed contains multiple errors and wouldn't have
passed review (either for us or by stricter Fedora guidelines) is
telling I think as to some of the problems of not centralising reviews
and the files themselves.
> I feel like with foreman-packaging and all this complicated jenkins tooling, we're trying to satisfy the tools' needs as opposed to satisfying our needs with the tools.
I would ask you not to try and bypass our package review process without
first raising the issues. If the packaging or implementing the feedback
was too much bother, I would have done it weeks ago.
As I mentioned, there are ways to get a scratch build of a non-released
repo (sbu), but we could also trivially implement something in our
repo's tito configuration, allowing:
tito release koji-foreman-plugins-test --test --scratch --arg
source=~/code/hammer-cli-foreman-tasks
or similar, just to point a builder at a directory and have it pull
sources from that for the build.
I also have an enhancement in a PR to add mock configs to the repo,
which can create a scratch package in seconds instead of the minutes
using Koji. These are solvable problems.
···
On 05/03/15 15:20, Adam Price wrote:
> ----- Original Message -----
>> On Thu, Mar 05, 2015 at 09:34:59AM +0000, Dominic Cleal wrote:
>>> On 04/03/15 21:59, Adam Price wrote:
–
Dominic Cleal
Red Hat Engineering
I know "build" and "tag". That's pretty much it.