[Feature proposal] Whitelist Repositories allowed to dynamically create stacks

[indiebrain]

Greetings,

At PowerHRG we desire to implement the ability to automatically deploy a branch as a new "review instance" of our application to our Kubernetes cluster when a Pull Request for that branch is opened - and subsequently clean up the instance when the PR is closed or merged - functionality similar to Heroku's Review Apps. However, we maintain a number of projects and do NOT want to expose this functionality for every application/repository/pipeline.

As we understand it, Shipit offers no mechanism at the repository level to control which repositories can dynamically provision stacks. We'd like to add such a feature to Shipit and are seeking design guidance / gauging appetite for possible upstream contribution. It seems the Stack is the highest level concept which involves an application/repository/pipeline, but this remains insufficient since the Stack also marries a particular branch and environment to the application/repository/pipeline concept. What we think we'd like is a higher level concept which represents the application/repository/pipeline to which stacks could belong. This application/repository/pipeline could then contain its own configuration for the project-level features we desire.

As I've stated earlier, we seek guidance:

1. Are we alone in this problem?
2. What aren't we considering?
3. How are others achieving this goal already given the existing tools?
4. Does this seem like a reasonable feature for Shipit?
5. Does the design direction make sense given the goals of Shipit?
6. Aside from the workflow guidelines listed in the README, what's the least contentious path for upstream adoption of contributions?

[casperisfine]

Are we alone in this problem?

Probably not.

What aren't we considering?

Stacks aren't designed to be ephemeral, and they're also the "top level object", so you wouldn't have anywhere to put the auto-provisioning code.

How are others achieving this goal already given the existing tools?

We don't have that exact workflow, but we achieve similar things using tasks on a stack, plus some glue code in a Webhook handler using Shipit's API. e.g. trigger a task with some parameters on PR opening, and another one on PR close.

[indiebrain]

@casperisfine , thanks for the swift reply.

Stacks aren't designed to be ephemeral

I'm no expert, but I can't rationalize why making stacks optionally, slightly less permanent might be a problem. Given one can manually add/remove Stacks in Shipit-Engine (and we've done so in our production instance a handful of times), what would be the concern with making "Review" stacks shorter lived and their creation/destruction the act of an optional automated process? Is there something specific you're thinking of, but in my blind-spot of ignorance, which would prevent this?

...and they[stacks]'re also the "top level object", so you wouldn't have anywhere to put the auto-provisioning code.

Exactly, which is why we propose to add a concept for the repository; to which stacks and additional configuration/logic might belong. One might argue that the Stack shows evidence of feature envy of the repository concept already - via its repo_name and repo_owner attributes, though I recognize it's not an air-tight case.

We don't have that exact workflow, but we achieve similar things using tasks on a stack, plus some glue code in a Webhook handler using Shipit's API. e.g. trigger a task with some parameters on PR opening, and another one on PR close.

In this way, wouldn't one lose the ability to use Shipit to determine which commits/deployments have been made against the PR branch and its target instance via Shipit? IE if it isn't a stack, we lose the commit and deployment history of the stack UI, ya?

[casperisfine]

I can't rationalize why making stacks optionally, slightly less permanent might be a problem.

Ultimately it would "work", but lots of limitations would appear, e.g. Git repositories are not shared between stacks so the disk usage would ballon real quick. There's also the cleanup after a delete that is subject to a bunch of races that can leave things around etc.

No huge deal, and nothing that can't really be ironed out with some work, but I'm just not convinced it's the best direction.

Exactly, which is why we propose to add a concept for the repository;

That could be a solution indeed, but that's quite a large refactoring (which doesn't mean I'm not open to the idea).

In this way, wouldn't one lose the ability to use Shipit to determine which commits/deployments have been made against the PR branch and its target instance via Shipit? IE if it isn't a stack, we lose the commit and deployment history of the stack UI, ya?

No it's still a stack. It's just that you use one off tasks to deploy rather than true deploys. Simple tasks will appear in the timeline just like regular deploys.

e.g. (not tested)

deploy:
  - echo noop
tasks:
  deploy_branch:
    action: Deploy a branch
    title: Deployed %{BRANCH} to ${SHA}
    steps:
      - script/to/depoy
    variables:
      - name: BRANCH
      - name: SHA

[benlangfeld]

@casperisfine

No it's still a stack. It's just that you use one off tasks to deploy rather than true deploys. Simple tasks will appear in the timeline just like regular deploys.

One loses the visual display of commits deployed, the built-in continuous delivery routine, and the separation of unrelated PRs for ease of understanding. We're trying to make these deployments first class citizens in Shipit.

Would the maintainers be willing, in principle, to accept a change which introduces Application / Repository as a parent to Stack?

[casperisfine]

Would the maintainers be willing, in principle, to accept a change which introduces Application / Repository as a parent to Stack?

Well, that's a refactoring I wanted to do since a long time for other reasons (sharing git repo, being able to quick link to other envs, etc), so yes I would merge such refactoring.

I can't guarantee however that I'd merge an automatic provisioning of stacks upon PR opening. If the implementation end up being simple and elegant yes, but otherwise it's unlikely.