-
Notifications
You must be signed in to change notification settings - Fork 158
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
Add 'commit messages' for things like emp run, emp scale, emp set #767
Comments
Discussed a little bit with @phobologic Rough decisions for v1:
For v2, we can add an alternative event backend that also publishes events to some persistent storage (S3 or RDS etc) |
v1:
v1.1:
v1.2:
|
We could store the commit message on the |
Yeah, the weird part with storing this is the fact that we are looking for commits in other events that don't create releases, like scaling events. |
Ah yeah, good call. Although honestly, maybe those should create new releases? The only reason we didn't was to have the same behavior as Heroku. |
+1 to scaling events creating releases. Would love to be able to see them On Wed, Apr 27, 2016, 15:46 Eric Holmes notifications@github.com wrote:
|
I'm waffling on the idea. It feels weird in the 12factor world. I'd almost be more prone to support an 'Events' table and an |
Why is it weird? I think it's nice to have the entire application described On Wed, Apr 27, 2016, 16:50 Michael Barrett notifications@github.com
|
Yeah, the more I think about this, the more I think scaling should be a new release. Releases should be immutable, but scaling is the only operation that modifies a release. But, to play devils advocate, there is a performance disadvantage, because creating a new release requires that we submit it to the scheduler, which means all new task definitions across all processes. It may also get weird if ECS ever adds autoscaling, since that wouldn't be reflected in the release. |
Just the way we've defined a release in the past - a release is the combination of code & config. Scaling didn't change either of those - you could deploy a release across any sort of scale. They feel like very different things - and I could see us wanting to limit what someone can do in the future. IE: let people scale, but no change config or code. |
additionally, you can either provide
|
It'd be good to have some context when these things happen.
Maybe a flag to make it required or not, and a
-m
option to add it automatically from the command line, or else you get prompted?I think this is a good set of commands to start with:
@sanjayprabhu
The text was updated successfully, but these errors were encountered: