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.l...