Shopify / Shopify/shipit-engine

[Feature proposal] Whitelist Repositories allowed to dynamically create stacks

Open
#960 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Ruby
Stars
1.5k
Forks
154
Avg merge
2h 26m
Merged PRs (30d)
3

Description

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?

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the README workflow guidelines and inspect how the existing Stack concept connects applications, repositories, pipelines, branches, and environments. Done requires an agreed project-level allowlist design for dynamic stack creation, including behavior when pull requests close or merge and a path for upstream adoption.

Written by the indexing model from the issue text.

Assessment

Tech stack
kubernetes, ruby
Domain
cloud, devops, infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.