On Mar 05 15:09, Karanbir Singh wrote: > On 05/03/15 15:02, Brian Stinson wrote: > > On Mar 05 11:41, Karanbir Singh wrote: > >> On 09/26/2014 02:33 PM, Karanbir Singh wrote: > >>>> Currently koji doesn't have any read access controls, or at least not > >>>> any related to builds. Most folks would probably either use a private > >>>> koji, or just run mock against koji's yum repos. > >>>> > >>>> Are we really only talking about a scratch build type scenario, or do > >>>> folks want a real build that is hidden? Difference being that in the > >>>> former case, you'd end up running a non-scratch rebuild after the > >>>> embargo lifts, while in the latter you'd flip a switch and have the > >>>> build appear. > >>>> > >>>> The latter case is much harder (and also begs for embargo lockdown in > >>>> source control), but neither is trivial to implement. > >>> > >>> What we really need is a way for $person to build 'stuff' without it > >>> going public. If that means the sources cant hit git.centos.org then > >>> thats ok, we just need to make sure folks understand that > >>> no-commit-to-git.c.o till public. > >>> > >>> If that then imples that koji's targets can only be used once stuff is > >>> public, that too might be fine ( as long as the person has had the > >>> change to test builds against the same target in the past ). > >>> > >>> Our exposure in this case would then be limited to the time it takes to > >>> build something, and since the scratch builds will use the same repos - > >>> we can be fairly confident (!) about result; we'd still test it, but we > >>> can go into the testing with a higher level of confidence. > >> > >> reviving an old thread - we're again in a situation where we need SIGs > >> to be able to build security updates and do some testing around content > >> that is under embargo. > >> > >> Depending on how much work this is, do we go down the route of replacing > >> one of the koji builders with a reimzul like instance that runs private > >> builds ? reimzul can generate per-build htaccess entries for basic-auth, > >> that way ( apart from folks who have shell access to the machine ), > >> there is some level of privacy as well. > >> > >> If we do go down that route, we'd need a way for koji to import those > >> builds at a later stage, when they need to be signed and released. > >> > > > > When we brought this up at the CBS meeting I remember talking about > > having the SIGs do local mockbuilds (perhaps on devcloud?) and then > > commit to their branches after the embargo is lifted. Are there some > > requirements that aren't covered by that workflow? > > there is no way to prep-ahead and test-ahead using this, also it means > folks need to be around and standing by as embargo is lifted. in many > cases, thats not possible. > > I'm assuming that you meant commit to their branch, then trigger a > build, and then do the testing. Something like: 1) Create VM on devcloud 2) Pull package from git.c.o 3) Patch with embargoed content 4) `centpkg mockbuild` 5) Local tests - Should be valid since they would be building against koji repos 6) (Once the Embargo is lifted) Commit, push, and build in koji 7) CI Tests? 8) Tag/Sign/Release Looking back, that was our "temporary" workflow we talked about in our meeting in September[1]. For the permanent solution (whether reimzul or something else) we may want to look at some convenience methods in the client tools. Brian [1]http://www.centos.org/minutes/2014/september/centos-devel.2014-09-29-13.01.log.html