Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Branch locking #13

Open
farmdawgnation opened this issue Jul 24, 2014 · 1 comment
Open

Branch locking #13

farmdawgnation opened this issue Jul 24, 2014 · 1 comment

Comments

@farmdawgnation
Copy link
Member

It would be nice if yardmaster allow for branch locking when certain jobs are deployed. Essentially, this is intended to address the problem of two people on the same team not realizing that the other needs to use the job in question.

Opting-in to locking

Locking would be turned off by default. I would envision turning it on looking something like

Hubot, enable locking for

At this point, the Hubot knows what the default branch for the job in question is. You could likewise disable locking for a particular job.

Hubot, disable locking for

Switching when locking is active

When locking is active for a job, yardmaster will require some extra information in order to switch a build over to the non-default branch. To switch a job to a feature branch you'd need to provide something like the following:

Hubot, switch to for

At this point, the reason for the branch switch has been logged. When the developer who is doing the testing is finished, they can say

Hubot, switch to

And the build is now considered unlocked and free for anyone to switch. However, if another developer tries to come in and deploy a second feature branch on top of the first one, let's say Mike tried to deploy a feature branch while Antonio was testing something, something like the following exchange would occur:

Mike: Hubot, switch alan-shepherd to awesome-sauce
Hubot: Sorry, Mike. Antonio is using alan-shepherd to test super-cool-branch-name for "super secret testing reason" since 7/23/2014 at 10:00 AM EST.

At this point Mike has two options.

  1. Tell Antonio to hurry the heck up and have Antonio unlock the build.
  2. Force the switch.

Hubot, force switch to for

A force switch overrides the lock functionality, but ideally shouldn't be used unless the developer who was using the job is unreachable for some reason.

@riveramj
Copy link
Member

I've been thinking about something like this for a while. I think it can be useful for sure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants