deis/deisrel

A releaser tool for Deis

	This repository (deis/deis) is no longer developed or maintained. The Deis v1 PaaS based on CoreOS Container Linux and Fleet has been replaced by Deis Workflow which is based on Kubernetes.

Deis v1 PaaS

Deis (pronounced DAY-iss) is an open source PaaS that makes it easy to deploy and manage applications on your own servers. Deis builds upon Docker and CoreOS to provide a lightweight PaaS with a Heroku-inspired workflow.

New to Deis? Learn more about Deis Concepts, Architecture and how to Deploy an Application.

Installing Deis v1

Deis is a set of Docker containers that can be deployed anywhere including public cloud, private cloud, bare metal or your workstation. Decide where you'd like to deploy Deis, then follow the provider-specific documentation for provisioning.

Trying out Deis? Please follow the documentation on getting set up with Vagrant. Upgrading from a previous Deis release? See Upgrading Deis for additional information.

Troubleshooting

See the Troubleshooting Deis documentation for assistance with common issues.

Contributing

Interested in contributing to Deis? Check out our Open Roadmap and Planning Process or jump right into hacking on Deis and testing your Deis cluster.

License

Copyright 2013, 2014 Engine Yard, Inc.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

deisrel's Issues

Use changelog when tagging a release

Use the change log as the body of the commit message for hte last commit when tagging a release

Retrieve canonical list of workflow component/repo names

In https://github.com/deis/deisrel/blob/master/actions/common.go we produce a local data structure involving ideally the most up-to-date listing of Deis Workflow component repo names. It would be preferable to go straight to the canonical source for such information.

Though this canonical source doesn't quite exist yet, it is envisioned that Workflow Manager will be the likely candidate.

Break actions up into logical packages

This has been started with added functionality (see changelog.go, git.go, etc.) but we should revisit/refactor more non-cli action code out into their own packages.

remove "for testing only!" notices in helm-stage

Following step 7 in the release checklist, I ended up with the following diff:

diff --git a/router-v2.0.0/Chart.yaml b/router-v2.0.0/Chart.yaml
index 3cdbc4f..003f7c2 100644
--- a/router-v2.0.0/Chart.yaml
+++ b/router-v2.0.0/Chart.yaml
@@ -1,15 +1,17 @@
 name: router-v2.0.0
 home: https://github.com/deis/router
-version: v2.0.0
-description: Deis Router
+version: v2-beta
+description: For testing only!
 maintainers:
 - Deis Team <[email protected]>
 details: |-
+  WARNING: this chart is for testing only! Features may not work and there are likely to be bugs.
+
   The Deis Router is a simple program that manages Nginx and Nginx configuration for managing
[...]

Now that we are (almost) out of beta, we should remove these warnings. :)

Templatize "metadata" files in helm charts

This issue is for using Go templates in Chart.yaml and README.md files in helm charts so that deisrel doesn't have to do string replacement, which is brittle. My proposal is to add a generate_metadata.toml in the same directory as the README.md and the Chart.yaml, and make the latter two files into Go templates. deisrel would then get a new command that reads the generate_metadata.toml and generates the README.md and Chart.yaml templates based on the values in that file.

In this new scheme, a new workflow-tpl folder would be created in the https://github.com/deis/charts repository. That repo would have a README.md that looks similar to the below, with a similar Chart.yaml file as well.

# Workflow {{.WorkflowVersion}}

{{.WorkflowWarning | default "WARNING: this chart is for testing only! Features may not work, and there are likely to be bugs."}}

Please report any issues you find in testing Workflow to the appropriate GitHub repository:
{{range .WorkflowComponents}}
- {{.Name}}: {{.Link}}
{{end}}

A version-specific file would be created by the releaser to cut a new chart. This file would not necessarily need to be checked in to any source control, because it's only used once. See below for a sample:

WorkflowVersion = "v2.0.0"
WorkflowWarning = ""
[WorkflowComponents]
builder = "https://github.com/deis/builder"
...

With those changes in place, the deisrel command to create a new template would be as follows:

deisrel helm tpl ./workflow-tpl ./workflow-2.1.0 --params=workflow-2.1.0-metadata.toml

This command would not only create a new chart based on workflow-2.1.0-metadata.toml, it would also adjust the tpl/generate_params.toml so that helmc generate can correctly generate new manifests when the user is installing deis workflow. The latter is current behavior of deisrel.

cc/ @vdice for thoughts and feedback

[Meta] Cover step 4 (Docker image tagging and pushing)

The outcome of this work should be a deisrel command that replaces the use of deis-workflow-group as seen in http://docs-v2.readthedocs.io/en/latest/roadmap/release-checklist/#step-4-tag-and-push-docker-images

TODO:

• command for docker tagging checking docker tags #6
• command for docker pushing #57
• update https://github.com/deis/workflow/blob/master/src/roadmap/release-checklist.md

add create-releases feature

Add deisrel create-releases <params> <opts> command/functionality, enabling the following workflow:

deisrel create-releases <params> <opts> -> creates releases for all repos using the appropriate GH api call, specifying same tag & title for each release and repo-specific changelog for its POST body (can use existing deisrel changelog functionality to derive) -> command returns by printing collated/aggregated changelog to stdout -> user copies & pastes, sends to Marketing, etc. for blog announcement(s).

Where <params> includes release_tag and release_title (possibly same string)

Where <opts> includes, minimally, a --ref <ref> flag for passing in a different ref other than master to create release from. (Should also consider a --dry-run flag, or, alternatively, a prompt to proceed after supplying info on what will be done.)

implement proposal #52

Collapse all of the helm chart related functionality into a single command, as proposed in #52

Create command for generating changelogs

A new command should be added to generate changelogs from a given tag to a SHA. The former parameter should be defined globally, and the latter should be per-project (defined as an input). For example:

deisrel git gen-changelogs -since=v2.0.0-beta1 -shas=shas.txt

The command should add the new release to the changelog on each repo, and set the new changelog on that repo. There should be an optional parameter to submit a pull request for the changelog instead of committing directly to master

Add integration with quay.io API

With #3, the tool should check to make sure each git-sha-tagged image exists before trying to re-tag

changelog generated is lacking link to commit sha

deisrel changelog ... commands produce output like:

# Features

 - 7abd71b managing-workflow: add back production deployments
 - c8b3548 storage: modify docs for configuring storage using env vars
 - 9e9fc03 customizing-workflow: add component tuning
...

But we'd like to stick to the precedent of having the shas be links to the commits:

#### Features

 - [`7abd71b`](https://github.com/deis/workflow/commit/7abd71b5a1409e8aa6d0bc738a71eb5e87ed0de9) managing-workflow: add back production deployments
 - [`c8b3548`](https://github.com/deis/workflow/commit/c8b3548979be2a483f6deaf58baa9fe7d197f340) storage: modify docs for configuring storage using env vars
 - [`9e9fc03`](https://github.com/deis/workflow/commit/9e9fc031e96ec757c2747a8d16fd778647512416) customizing-workflow: add component tuning
...

document deisrel

deisrel has but one doc string: "a releaser tool for Deis". At some point we should document deisrel so others know how to get set up and use this tool!

add --dry-run tag to git tag

this will allow us to test this command without actually making changes to the repositories

deisrel doesn't know what to do with these...

This is a short, but probably non-exhaustive list of deis repos that deisrel currently lacks any knowledge of. Not all of these repos represent a "component," and further, some are versioned with the rest of Workflow and some are not necessarily. (As a for instance, docker-go-dev, has its own progression of releases.) What all of these do have in-common as that, afaik, their labels and milestones are controlled by deis/seed-repo and their issues and PRs are often tagged to a Workflow milestone...

Insofar as #101 seeks to make bulk reassignment of issues from one milestone to another a possibility, we probably need to figure out how to incorporate each of the following into deisrel. (i.e. The semantics of dealing with repos seems to be different for those containing the source of "components" vs those that that do not. The semantics might be different still for repos that shouldn't be versioned in lock step with Workflow.)

cc @arschles

• controller-sdk-go
• deisrel
• docker-go-dev
• docker-python-dev
• docker-shell-dev
• e2e-runner
• gutenberg
• jenkins-jobs
• k8s-claimer
• nsq
• object-storage-cli
• seed-repo
• wal-e
• workflow-cli
• workflow-manager-api

Stage charts for standalone components

Some components (e.g. router) can be used without the rest of Workflow. We should update deisrel to generate new charts for said components in addition to the new Workflow charts.

Add command for releasing new version to versions.deis.com

cc/ @jackfrancis

also track repos needing changelog/git tag updates

Mistakenly, the workflow repo was removed from this tool on the premise that it wasn't a workflow component needing image tag updates to quay and/or in the release chart. Although that is true, this repo does require release changelogs and git tagging, like the rest, so it should be included once again.

Another similar non-workflow-chart-related repo would be deis/charts.

Therefore, we need to minimally add these two repos for use in deisrel changelog ... and deisrel git tag invocations.

pull deis org via command line flag

see conversation here - #26

publish deisrel binary to bintray

add create-branches feature

Add deisrel create-branches <params> <opts> command/functionality, enabling the following workflow:

deisrel create-branches <params> <opts> -> creates (release) branches for all repos using the appropriate GH api call, specifying same branch name provided by user with <params>

Where <params> includes branch_name to be created.

Where <opts> includes, minimally, a --ref <ref> flag for passing in a different ref other than master to branch from. (Should also consider a --dry-run flag or, alternatively, a prompt to proceed after supplying info on what will be done.)

GITHUB_TOKEN should be GITHUB_ACCESS_TOKEN

create documentation on how to use the tool

README should be updated to provide instructions on each command and how it should be used

env var needing to be deleted in release chart

From release checklist, there is the following manual step:

Delete the `KUBERNETES_POD_TERMINATION_GRACE_PERIOD_SECONDS` env var from `workflow-$WORKFLOW_RELEASE_SHORT/tpl/deis-controller-rc.yaml`

We should automate this step in deisrel -- perhaps after inquiring as to the origins of exactly why it needs to be deleted and whether or not a different approach in chart itself might be a better option...

Retrieve canonical generate_params.toml via GH API

In https://github.com/deis/deisrel/blob/master/actions/generate_params.go and https://github.com/deis/deisrel/blob/master/actions/generate_params_e2e.go we construct local versions of the appropriate .toml files, but it would be better to pull the latest canonical versions of each from the deis/charts repo as these files change.

[proposal] refactor helm-params,stage

Current State

The current deisrel workflow for generating all of a given release chart's files needing updating (inserting $WORKFLOW_RELEASE(_SHORT) where necessary, inserting latest git sha values for component dockerTag values, etc.) can be seen in the current version of the Release Checklist. For instance, it looks something like:

Stage copies of the tpl/generate_params.toml for each chart into staging. deisrel will automatically populate the latest commit sha values for each component's dockerTag:

deisrel helm-params --stage workflow
deisrel helm-params --stage e2e

Stage copies of the additional files in workflow-dev(-e2e) charts needing release value updates into staging (i.e., Chart.yaml, README.md, etc.)

deisrel helm-stage workflow
deisrel helm-stage e2e

Copy these staged files back to the correlating chart directories created in step 2 above:

cp -r staging/workflow-dev/* workflow-$WORKFLOW_RELEASE_SHORT
cp -r staging/workflow-dev-e2e/* workflow-$WORKFLOW_RELEASE_SHORT-e2e

Proposed State

I propose we reduce the number of deisrel/associated command invocations. I'd like to see the above workflow change to something like:

Stage all release-updated files for each (workflow, e2e) chart into the newly created release chart dirs:

deisrel helm-stage --stagedir workflow-$WORKFLOW_RELEASE_SHORT workflow
deisrel helm-stage --stagedir workflow-$WORKFLOW_RELEASE_SHORT-e2e e2e

Which would generate all necessary files for each chart and output them directly into supplied --stagedir. If not supplied, it would default to throwing files into local staging dir as before.

quay api write on closed buffer

#62 brings the necessary code in for checking the existence of Docker image tags on both DockerHub and quay, using the respective apis in https://github.com/heroku/docker-registry-client/ and https://github.com/coreos/go-quay. Although all set up, it seems we frequently hit write on closed buffer errors from the quay.io api calls like the following:

$ ./deisrel docker check-tags
2016/06/06 10:56:49 registry.ping url=https://index.docker.io/v2/
2016/06/06 10:56:51 registry.tags url=https://index.docker.io/v2/deisci/slugrunner/tags/list repository=deisci/slugrunner
Error encountered attempting checking tag (Get https://quay.io/api/v1/repository/deisci/influxdb/tag/git-2d57388/images: write on closed buffer)
Error encountered attempting checking tag (Get https://quay.io/api/v1/repository/deisci/controller/tag/git-d8a0ddf/images: write on closed buffer)
Error encountered attempting checking tag (Get https://quay.io/api/v1/repository/deisci/fluentd/tag/git-ff4f8ea/images: write on closed buffer)
Error encountered attempting checking tag (Get https://quay.io/api/v1/repository/deisci/stdout-metrics/tag/git-1929eb9/images: write on closed buffer)
Error encountered attempting checking tag (Get https://quay.io/api/v1/repository/deisci/registry/tag/git-c2e69a2/images: write on closed buffer)
Error encountered attempting checking tag (Get https://quay.io/api/v1/repository/deisci/workflow-e2e/tag/git-4c7eb28/images: write on closed buffer)
Error encountered attempting checking tag (Get https://quay.io/api/v1/repository/deisci/minio/tag/git-313b767/images: write on closed buffer)
Error encountered attempting checking tag (Get https://quay.io/api/v1/repository/deisci/slugbuilder/tag/git-ae0e295/images: write on closed buffer)
Error encountered attempting checking tag (Get https://quay.io/api/v1/repository/deisci/router/tag/git-347931d/images: write on closed buffer)
Error encountered attempting checking tag (Get https://quay.io/api/v1/repository/deisci/workflow-manager/tag/git-c15c268/images: write on closed buffer)
Error encountered attempting checking tag (Get https://quay.io/api/v1/repository/deisci/logger/tag/git-191b2ac/images: write on closed buffer)
Error encountered attempting checking tag (Get https://quay.io/api/v1/repository/deisci/postgres/tag/git-560085d/images: write on closed buffer)
Error encountered attempting checking tag (Get https://quay.io/api/v1/repository/deisci/builder/tag/git-5be2e94/images: write on closed buffer)
Error encountered attempting checking tag (Get https://quay.io/api/v1/repository/deisci/dockerbuilder/tag/git-337f588/images: write on closed buffer)
Successfully found the following image tags in Quay.io and DockerHub registries:
deisci/slugrunner:git-3aadf5d

use updated arschles/sys functionality

arschles/sys has updated functionality as of arschles/sys#2 that we can use instead of all the current code in https://github.com/deis/deisrel/blob/master/actions/fileSys.go

Refactor global changelog generator to use changelog package functions

#47 introduces a github.com/deis/deisrel/changelog package, which contains a function to generate a changelog on a single repository. This issue is for removing duplicate code in the actions package and using the functionality in that package. It may require adding some functionality to that changelog package too.

need to update cli

Getting the following deprecation warning when we run deisrel:

DEPRECATED Action signature.  Must be `cli.ActionFunc`.  This is an error in the application.  Please contact the distributor of this application if this is not you.  See https://github.com/codegangsta/cli/blob/master/CHANGELOG.md#deprecated-cli-app-action-signature

Create command for tagging repos

A new command should be added to set a git tag on each repo. For example:

deisrel git tag -shas=shas.txt -tag=v2.0.0-beta2

The input file should be the SHA to tag each repo with

Limit cross-compilation to just darwin/amd64 and linux/amd64

These two combinations should sufficiently cover anyone who might actually coordinate a release of Workflow (i.e. the deis team). There's no reason to build all the other os/arch permutations and allow them to take up space in GCS if they will never be used.

create command for generating changelogs for an individual repository

Summary

deisrel should gain a new command that ports the logic in generate-changelog.sh to Go. The command should replace the script referenced in https://docs-v2.readthedocs.io/en/latest/roadmap/release-checklist/#step-6-update-changelogs.

Command Specifics

The command's logic is pretty straightforward (iterate through commits since a previous tag, group them, and execute a template with the groups), but the command structure itself should be changed.

Currently, we have a generate-changelogs command, which aggregates all existing changelogs and prints the result to STDOUT. Since this issue adds a new changelog-related command, deisrel should get a new parent command with two subcommands. They should look like the following:

• deisrel changelogs generate-global
• deisrel changelogs generate <repo> <old_tag> <sha> <new_tag>

This issue is for changing the command structure and implementing the second bullet. The changelog should be written to STDOUT.

Possible Improvements

A possible improvement on this this command would be to automatically generate the changelog and (which could go into a separate issue) is to automatically generate the changelog and commit it directly to the repository (using the GH API). This improvement requires a lot more work and could go into a separate issue. It's up to the implementor how to proceed with this section.

update `version` in Chart.yaml for release charts

update version value in Chart.yaml for all release charts with the proper $WORKFLOW_RELEASE (full semver release) value.

See https://github.com/deis/charts/blob/master/workflow-dev/Chart.yaml#L3 and https://github.com/deis/charts/blob/master/workflow-dev-e2e/Chart.yaml#L3

Makefile: Create commands that dont rely on docker

Add command for aggregating all changelogs

This issue is for using the GH API to fetch all changelogs from each repository and aggregating them all into one global changelog. This changelog is used for the blog post and other announcements for each new release, and currently this aggregation is done manually.

[Meta] Further deisrel enhancements

Top priority items

To reduce current release toolset down from 2 (deis-workflow-group and deisrel) to 1 (deisrel), in priority order:

• deisrel docker retag: #58, PR: #89
• deisrel create (release) branches: #99
• deisrel create releases: #98
• get list of repos/components from file (#115)
• retrieve canonical generate_params.toml files: #11
• templatize chart metadata: #103

Next in priority as bandwidth allows:

• jenkins job for component release build/deploy: deis/jenkins-jobs#110
• deisrel move to server proposal: #83

These tickets/enhancements would feed into the below proposed release process, and the documentation should be updated as new commands get implemented.

Release Steps Using deisrel

1. create all release branches for all repos (#99)
   • note: need a --ref flag for this, so we can do unscheduled/patch releases from a previous tag and not master
   • this would kick off the jenkins job detailed above (deis/jenkins-jobs#110), building/pushing docker images to the quay.io/deisci org.
2. copy helm chart from workflow-dev and update critical files (deisrel helm-stage)
3. change release branch on deis/charts repo to have new generate_params.toml, README, etc... (created by step 2)
4. e2e & manual testing on chart created in step 3
   • if we find an issue in a component, fix in the a branch on the component's repo, PR it, merge it to master, wait for CI to build a new image, then change the docker tag SHA in the deis/charts repo
   • PROBLEM: we don't have a code freeze. if person A commits an unrelated change to master, then person B commits the fix, we would have to do 1 of the following:
     • cherry pick the fix into the release PR - this is a problem b/c the docker image tagged with the master SHA has more than what we cherry picked
     • rebase everything in master up to person B's commit back into the release PR - this is a problem because the release PR has more than just the fix in it
   • SOLUTION: do cherry pick, and have a pipeline that builds, docker-builds and docker-pushes artifacts from release branches
   • Quick Fix: after the cherry pick, manually kick off the appropriate job (https://ci.deis.io/job/builder for example) for the repo that the cherry pick happened on, overriding the sha1 job parameter to match the commit on the release branch
   • Better Fix: implement deis/jenkins-jobs#110 above that looks at all branches across all repos, and runs a build/docker-build/docker-push pipeline on commits to all branches where branch name matches release-*
5. Merge the deis/charts release PR
   • At this point, the workflow artifact is released. The remaining steps are to release the individual component artifacts (repo tags & docker images)
6. Create releases for all release branches (#98)
   • implicitly creates changelog & tags
   • not merging any of the release branches back into master (except for the deis/charts one, which was already merged)
   • output from this command is aggregated (global) changelog that should be copied and sent to Jason, marketing, etc... (in future, would be ideal to have deisrel automatically create gist and/or post to an agreed-upon spot)
   • Long-term: move functionality to server (#83)
7. Re-tag all docker images to the pretty tag (#58)
   • for example, quay.io/deisci/builder:git-12345 (tag SHA) --> quay.io/deis/builder:v2.1.0 (tag name)
   • Quick fix: re-purpose deisrel docker retag to do this, instead of using the webhook server for now (in progress at #89)
   • Better fix: move functionality to server (#83)

Create command for pushing Docker tags

Create a command to push (release) tags to all appropriate component Docker repos, realistically to be used in conjunction with the docker retag functionality introduced in #6 . For example:

deisrel docker push-tags -tag=<tag_to_push>

Automate release chart(s) creation

See https://github.com/deis/workflow/blob/master/src/roadmap/release-checklist.md#step-2-create-a-new-helm-chart for the steps needing to be covered.

TODO:

• #10
• #13

Related to the meta ticket deis/jenkins-jobs#55

Create command for docker tagging

The input should be the list of git SHAs (each of which represents image tags), and the command should re-tag image as a specified tag. For example:

deisrel docker retag -i shas.txt -newtag=v2.0.0-beta2

git tag should sort repo list

makes it hard to know if you've left a repo out or not

Pull down workflow-dev(-e2e) charts to gen release versions

Add command(s) to pull down latest workflow-dev(-e2e) charts to generate their $DEIS_RELEASE_SHORT counterparts as described in the Release Checklist.

This is part of effort described in #1

Proposal: move deisrel to the server

Currently, deisrel is just a CLI that runs all logic exclusively on the client's machine. Moving the core logic to the server and making the CLI just do RPCs to the server would provide benefits:

• Connect to a DB to keep a ledger of releases
  • This includes storing the global release notes for each release
• Use the DB to track status of an ongoing release
• Faster network-heavy operations such as docker tagging

This issue is a proposal and venue for brainstorming

Upload git-tagged releases to a folder in the GCS bucket

Right now, all releases are being uploaded to a the root of the deisrel bucket, but over time, as builds accumulate, that bucket is going to become very crowded. Instead, the releases that are git-tagged should be put into a sub-folder of that bucket, and the releases that are tagged with latest should be in the root

versions table should be updated on a new release

We have versions table which stores all the latest releases for a component which is used by the wfm api server(prod and staging clusters) and client gets the information from server to see if the update is available.

upload builds to s3

see deis/workflow-cli#73

readme output was incorrect when running deisrel helm-stage

For a major release, we were using v2.0.0 as the release name. However, in the README I got

# Deis Workflow 2.0.0-v2.0.0

As the title. This is probably due to deisrel replacing all instances of -rc2 with -v2.0.0.

generate-changelog should handle repos that do not have a starting tag

generate-changelog requires a beginning tag for it to work properly. If this tag does not exist then we drop all commit messages on the floor and we leave out that repo completely. This means that the first release a component would show up in it would not get an entry in the aggregate changelog.

In this case we should take commit 0...HEAD

Deploy a tagged version of the client when we create tags

This issue was created in response to #88 (comment)

git release branch creation

As of this writing, our release process includes pushing release branches to all component and/or Workflow-related repos. Currently, this is done from sgoings/deis-workflow-group, but we intend to discontinue use of this tool once the functionality exists here.

Therefore, this ticket is for implementing the functionality mentioned in Step 1.1 of the Release Checklist.

generate-changelog: Should output what repo the message came from

 - adb9b43 secret: use objectstorage secret for creds than minio user secret
 - d4dcc0d config: move from time_local to time_iso8601
 - dce56d5 config: add application name as part of the log information

Would be nice if it looked like this

 - adb9b43 (Minio) - secret: use objectstorage secret for creds than minio user secret
 - d4dcc0d (Router) - config: move from time_local to time_iso8601
 - dce56d5 (Router) - config: add application name as part of the log information