Description of problem: Currently to send a content specification to brew is a two step operation. Ideally it should be possible to combine these steps into one action (csprocessor brew) which builds/assembles the content specification and then sends it directly to brew. For consistency with rhpkg it would also be useful to be able to add a --nowait parameter to have execution of the csprocessor stop once the brew build has been launched.
See the duplicate bug for details about why this won't be implemented as eventually this should become a project usable by anyone and not only internal staff. I'll discuss this with Matt and/or Misty to make sure and put the details back into this RFE. *** This bug has been marked as a duplicate of bug 818043 ***
Seems like an odd call given brewkoji exists upstream, is used heavily in Fedora, and the Fedora docs team are moving to a publication process very similar to the internal one in the near future. Publican lives entirely upstream and I don't believe Jeff makes any effort to hide the brew support there?
The other more flexible, but probably more involved, option I was thinking about was adding 'hooks'. In this case the ability to add a line to your config specifying a command to run post-assembly, in the directory where the publican.cfg exists, though you could just as easily have others. We did this early in the life of the topic tool to support prototyping of various ideas, not sure if csprocessor has something similar. Basically there was the ability to specify a pre and post hook for every command line action in the config: PRE_EXPORT_HOOK=/home/sgordon/pre-export.sh POST_EXPORT_HOOK=/home/sgordon/post-export.sh Any extra arguments detected after those required for the action were also fed to the hooks. This is a significantly different request to my original RFE here, but would facilitate what I want without having to add a new verb specific to brew (even though as stated in a previous comment I think it's not that specific to internal usage, at least in upstreams I am involved in - though they are admittedly RH sponsored).
Well in that case, it should be fine. The main reason was that some of the things mentioned where set-up for internal items (or at a quick glance). Anyways if it's possible to do with components that already exist then I see no issue with it. Moving this to assigned for now.
Thinking about it further there are still some differences (will get to how this would be handled in a generic way in a moment), as I understand it upstream brew has been running on a GIT backend for some time - whereas the internal instance only just switched over. To interact with this upstream they use a tool called fedpkg, the options available through it are in large part very similar to those exposed by the newer rhpkg utility used internally - with the exception of publican-build. So at least at this stage it looks like it will be necessary to support tweaking of the command used to brew, upstream users will I suspect want something like: publican package --brew (or --srpm, not sure yet as the ticket for the infrastructure changes is only just now being raised). While internal users will want: rhpkg publican-build Other upstreams (such as oVirt, which I am hoping to get a docs site up for in the near future) may need something else again. So I think what I am really after is a new verb that assembles the content spec, and then runs a configurable command in the resultant assembly (in the directory holding publican.cfg). To make the language less dependant on a specific implementation maybe 'publish' would be a more accurate verb than 'brew'? For the upstreams I am thinking of it will in fact be brew, albeit possibly called via a different mechanism, but this would allow for other publication methods to be supported too.
Perhaps an acceptable implementation is something similar to what I've done with publican builds where you can configure the arguments via the csprocessor.ini configuration file. The main issue with that though is as you mentioned it would be better to have it setup per "project" as different projects may be published to different sites/mechanisms. As such perhaps the details in the csprocessor.ini should act as a default if nothing is stored in the csprocessor.cfg. I will need to come up with an appropriate way of defining how to set those variables in the csprocessor.cfg as well. My initial thought is to do a similar concept to the way server url's are handled where you would set various publish options in the csprocessor.ini and then use the name of the setup as a command line option when doing "csprocessor checkout". You would also have a default in the same way as the URL's so if no publish options are setup in csprocessor.cfg it has something to go back to. I also agree that publish would be a more accurate verb in this case, even though in most cases it's likely to be brew. The publish command should do these four items: Validate -> Build -> Assemble -> Publish
http://fedorapeople.org/~mziaei1/git/aug25-fedorapackager/org.fedoraproject.eclipse.packager.koji/src/org/fedoraproject/eclipse/packager/koji/api/ Possible API for accessing Brew to get the pubsnumber.
Additional Notes: To go with the publish command I've added two override parameters to the build command. The new overrides are "Author_Group.xml" and "Revision_History.xml". These two overrides allow you to specify a file to be used instead of the defaults used within the CSP. eg. csprocessor publish --override AuthorGroup.xml=/home/lnewson/Defaults/Author_Group.xml The content itself at the moment of this comment isn't validated, however there is validation done to ensure that the specified file exists and is actually a file.
Closing and setting as current release as no QA was performed by the original reporter. If there is still an issue with this bug still than please re-open it.