search

mesosphere / kubernetes-mesos

A Kubernetes Framework for Apache Mesos
637 stars 92 forks source link

Auto-generate DCOS packages #598

Open karlkfi opened 8 years ago

karlkfi commented 8 years ago

We want to be able to auto-generate dcos packages with recent changes without manually creating new docker images and multiverse PRs. We would use these for automated and manual testing.

Branches to build with:

CI steps:

  1. auto-generate the appropriate docker images
  2. push new images to dockerhub (overwrite old dev image version)
  3. modify multiverse dev version to point to new docker image
  4. pushes mesosphere/multiverse:k8s-dev commit

Users then just use the appropriate mesosphere/multiverse:k8s-dev zip url as a multiverse source.

jdef commented 8 years ago
karlkfi commented 8 years ago

rotating out the old docker image builds

I suspect we'll just manually delete old dev builds for MVP. They'll be easy to spot with the -dev suffix.

subcommand packaging

I'm not entirely sure how that works, but we'll likely want to build it too, since it's included in the dcos package.

gh-assets-release

I don't think we need to do nightlies for github release pushes. the github releases are more for people and docs. we don't want to spam dev releases. we will need to update the docs on the one-liner to generate a kubectl tho. It's pretty trivial tho. So we don't really need to automate it.

At Pivotal we used to push CI artifacts to S3. That way they stuct around if we needed to repro old bugs, but it meant they sat around forever and were never cleaned up. it was kind of a mess. I'd like to avoid that and just make them easy to reproduce instead.

sttts commented 8 years ago

Nothing to build for the subcommand.

sttts commented 8 years ago

Is the lack of automation a bottleneck right now?

sttts commented 8 years ago

Where is the connection to the 0.7 release?

jdef commented 8 years ago

This ticket might become a higher priority the closer we get to a "production quality" release. At this point we build dcos packages pretty infrequently so I'm fine w/ the manual process that we currently have. I concede that what we do now could be a bit more documented.

karlkfi commented 8 years ago

The primary reason to do this sooner rather than later is so that we can test changes without making a new release PR manually every time. That way we can easily test that a certain bug is fixed or feature works and close the corresponding ticket with confidence.

sttts commented 8 years ago

The bottleneck we have right now is not at all building the images, but testing them. My v0.6.7 was laying around for literally weeks now without somebody testing. More CI build will not help here.