search

deis / workflow-cli

The CLI for Deis Workflow
http://deis.com
MIT License
31 stars 43 forks source link

feat(CI): upload CLI to seperate buckets #190

Closed Joshua-Anderson closed 8 years ago

Joshua-Anderson commented 8 years ago

To avoid making changes, I'm going to start by uploading to both the workflow-cli bucket and then specific bucket. We can then start to migrate.

@vdice how do you propose looking up a revision for a CLI between the PR and master bucket in e2e? Try to download from master, and if that fails download from the PR bucket?

deis-bot commented 8 years ago

@vdice and @helgi are potential reviewers of this pull request based on my analysis of git blame information. Thanks @Joshua-Anderson!

codecov-io commented 8 years ago

Current coverage is 7.19% (diff: 100%)

Merging #190 into master will not change coverage

@@            master      #190   diff @@
========================================
  Files           49        49          
  Lines         3460      3460          
  Methods          0         0          
  Messages         0         0          
  Branches         0         0          
========================================
  Hits           249       249          
  Misses        3184      3184          
  Partials        27        27

Powered by Codecov. Last update 260d826...b9cf727

bacongobbler commented 8 years ago

is there an issue open to explain why this change is necessary? My concern is how this will affect the usability of install-v2.sh to install specific versions of the client

bacongobbler commented 8 years ago

fwiw I'm all for this just wanna know some background :)

Joshua-Anderson commented 8 years ago

@bacongobbler there's a few reasons for the change.

  1. security: We have credentials injected into PR builds, so making sure there is no way for a PR to touch/overwrite the offical binaries is nice. A edge case in our new versioning system accidentally overwrote the v2.4.0 artifacts, but a malicious attack could do far more harm.
  2. Cleanness: We want to keep the master and release binaries indefinitely, but many PR binaries are only used for CI. This makes it much easier to just clean up PR artifacts every once in a while.

My concern is how this will affect the usability of install-v2.sh to install specific versions of the client

We'll mirror the release binaries from the workflow-cli bucket to the workflow-cli-release bucket and then change the url in the install script. It should be transparent to users. If anyone uses the GCS URL directly, we can leave the workflow-cli bucket unchanged for a while.

vdice commented 8 years ago

@vdice how do you propose looking up a revision for a CLI between the PR and master bucket in e2e? Try to download from master, and if that fails download from the PR bucket?

@Joshua-Anderson that does sound like a first approach. Otherwise, we should be able to send a flag (IS_PR or some such) from the initial Jenkins test job all the way down to the workflow-e2e container which could be used to determine the bucket to attempt pulling from.