Ability for an admin to permit a repo's builds to be privileged about gitness HOT 5 CLOSED

a PR for this would be great.

We could add a checkbox from the repository settings screen to toggle privileged mode. My initial thinking is, if a commit-hook-triggered build requires privileged mode, so does a pull-request-triggered build. Perhaps in this case you disable pull requests? We have a checkbox for this.

Or we could make this a system administrator function. Since privileged mode could pose an overall security issue, maybe the system administrator should be responsible for toggling the privileged flag for a repository.

I think the first option is the easiest, for now, since we don't need to design an entire set of new admin screens. Thoughts?

from gitness.

I think it has to be a system administrator function. With "actual" root in a container all bets are off (reboot the host by echoing to /proc/sysrq-trigger). Docker/LXC uses AppArmor, and that helps, but I don't know how much people trust it with root + user-injected code. I may be preaching to the choir here; just want to make sure we're on the same page.

That being said, having automated CI for pull requests is very nice, so I wouldn't want it disabled entirely. I'd treat it with the same scrutiny as secure env vars, which shouldn't be exposed to external pull requests. Once the PR is merged the the build will go again, this time privileged, but by this point it's been vetted by a trusted user.

from gitness.

yep, on the same page

let's only set Docker's Privileged=true where len(repo.PullRequest) == 0, and add a screen to the sysadmin section to toggle privileged mode.

from gitness.

Started working on this; not ready for a PR yet but making progress. It's rebased on top of #83 since that fixes the 'privileged' typo more thoroughly.

See https://github.com/vito/drone/commits/privileged-builds

I've started building out some testing infrastructure. Still a WIP; I'd like the docker client to be injected, so the tests aren't mutating global state to fake it out. Haven't tested that this actually works yet either.

By the way, I usually use Ginkgo/Gomega for testing. It provides a rich set of matchers, BDD-style testing, and a lot of nice concurrency-focused primitives. What would you think of adopting it? (I won't sneak it into this PR. :) )

from gitness.

yes, sounds good. I merged #83 last night

I haven't tried gomega, however, we've been playing around with goconvey. let me know what you think:
https://github.com/drone/drone/blob/master/pkg/handler/testing/users_test.go

from gitness.