Gated Builds example usage help

Drone Support
1

Can anyone please explane how works gated builds?
Maybe little usage example how to configure and run it.

2

I’ll second this request. I’d like to know more about how gated builds work in Drone 0.7, and if it’s changed in 0.8. Thanks!

3

I’ve tried to run through a few scenarios using the output from --help in the CLI but the outcomes aren’t as expected. Started with this page (albeit for an older version): http://readme.drone.io/releases/0.6.0-rc.1/gating/

For example:

  • Defining a “public” repo: the specific repo is a question I have. In context, this could be a Github (enterprise) repo or the repo defined in Drone which also refers to repos.
  • Pending approval - is the approval through a UI or does it trigger some interrupt to a Github org admin?
  • Do gated builds even actually work? (docs say coming soon)
4

The gating capability (renamed protected repositories) has been in flux and is subject to change prior to the 1.0 release and may be removed or replaced with something different. With that being said, here is a brief summary of how it works:

  • you go into the repository settings page and label a repository as protected
  • any changes the yaml file require approval from the repository owner (individual that activated the repository)

At this time, it is solely intended for open source (public) repositories that want to prevent a malicious pull request from accessing secrets that have been explicitly exposed to pull request plugins. The scope may be expanded in the future.

Do gated builds even actually work? (docs say coming soon)

Yes, we are using in production for drone. Here is an example https://beta.drone.io/drone/drone-cache-lib/46

Pending approval. Is the approval through a UI or does it trigger some interrupt to a Github org admin?

Through the user interface

5

Thanks for the quick response; apologies for my delay.

Maybe there are other conditions that are needed to raise the prompt … hmmm.

The Drone repo setting has this “checked”. I am the repo owner for both git and drone. I am not a Drone administrator.

Oh - is this an additional condition to raise the prompt? (I’ll be testing in a few minutes, asking for clarity)

Does the prompt for approval get raised if the repo owner is the one submitting the PR? For tracking, this seems ideal - even if redundant. I’d lean towards explicit approval than implicit inference (think of it as a “are you SURE you want to do this?!”)

6

the current logic works like this:

// only pull requests are gated
// pull requests from the repository owner (that enabled the repo in drone) and whitelisted 
if build.Event == model.EventPull && build.Sender != user.Login {
	// check to see if this configuration has been used (or approved for use) in the past
	// If yes, allow the build to continue. If no, block the build pending approval.
	if ok, _ := b.conf.ConfigFindApproved(conf); ok {
		return true, nil
	}
}
7
  • Setting of protected checked
  • Secret with fakepass added to the repo, including pull_request event
  • Job build step to query secrets
  • Submit PR as a repo owner
  • No prompt

The biggest part here is with != user.Login means you won’t get prompted for your own PR gated builds. From a tracking/visibility perspective, not having that would provide more info on the gated build. I may be misreading the code snip as well.

8

Ah … the gated build is applicable to changes to the .drone.yml not necessarily a prompt to continue with a build. That clears things up.

If you have secrets in your build, you need to protect the repo in Drone if you’re exposing the secret for PRs.

got it.