Big +1 to all of that. I think COPR provides some own GPG keys and IIRC you can't override those. It is possible to download packages from COPR and sign them again with a custom key of course. That's perhaps your plan I guess. Custom signatures is on COPR development TODO I think.
LZ On Wed, Nov 1, 2017 at 7:00 PM, Eric D Helms <ericdhe...@gmail.com> wrote: > In a previous thread [1], we discussed building an SCL vs. vendorizing gems > and the general consensus was to build an SCL. This thread is to outline a > starting plan for how to build and maintain a Rails 5.1 SCL. I invite and > appreciate comments towards this design. > > I'll begin by laying out some overall goals for the effort, a general > proposal of information and finally a breakdown of the why for each of the > proposal items to better explain my thinking. > > > Goals > > * Stand alone Rails 5.1 SCL and repository > * Owned and maintained by the Foreman community > * Easy to update and maintain > * Strive for automation and package tooling to reduce maintenance cost > > > Proposal > > Build location: Copr > SCL Name: tfm-ror51 > Git repository: theforeman/tfm-ror51-packaging > Hosted: yum.theforeman.org/rails/tfm-ror51 > RPM Signing: signed by unique Foreman owned GPG key > Tooling Repo: create package tooling repository separate from > tfm-ror51-packaging repo > Tooling Technology: Ansible > > > Breakdown > > Build Location > > There has been discussion around moving our RPM builds to Copr and off of > Koji. This will require shifting our configuration and setup, testing and > working out kinks in Copr workflow. Building this Rails SCL provides us an > opportunity to use Copr from the start, get familiar with it and workout > tooling to interact with and manage a repository there. Therefore, I am > proposing to start with Copr from the get go and avoid Koji. > > SCL Name > > Given the Foreman community will own the SCL, and our SCL namespace is 'tfm' > I am suggesting we follow convention by naming it tfm-ror51. Previous Rails > SCLs, were named similarly: rh-ror41, rh-ror42, sclo-ror42. > > Git Repository > > I am proposing we don't put this into foreman-packaging given the lifecycle > of the SCL will not follow that of Foreman. Further, with the goal to create > a stand-alone Rails SCL repository this should have its own lifecycle. > > Hosted > > We could point at the direct Copr repository, and reduce our bandwidth. > However, since we own this Rails SCL I believe we should host it as such > officially. Further, this would allow us to do some pre-flight testing by > building a repository in Copr, running a test of either the SCL itself > and/or Foreman against the SCL updates before promoting. > > RPM Signing > > I am recommending here that we sign the SCL RPMs with a new GPG key > generated just for signing the SCL packages. > > Tooling > > With an eye towards foreman-packaging changes, I am proposing we create a > separate git repository for all package tooling. The goal here would to > build out new tooling to allow easier maintenance of the packaging and > repository. This will allow the tooling to evolve independently of either > packaging repository. Further, when applying this tooling to > foreman-packaging later, the tooling would not have to be duplicated across > branches. > > Tooling Technology > > I am proposing a centralization on Ansible as the tooling technology for a > number of reasons. First, I feel that it has a low barrier to entry while > providing a mix of high and low level interfaces. Secondly, Ansible allows > orchestrating and building out more complex and directed tasks. Third, a > team of us has some built out Ansible tooling that has been working well for > us in another area that would be easy to port for packaging management. I > personally think bash is complex to understand for complex actions and is > too simple for building up a set of cohesive tooling. > > -- > Eric D. Helms > Red Hat Engineering > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Later, Lukas @lzap Zapletal -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
