GithubHelp home page GithubHelp logo

heroku / heroku-pipelines Goto Github PK

View Code? Open in Web Editor NEW
33.0 89.0 19.0 751 KB

this code is now in https://github.com/heroku/cli

Home Page: https://www.npmjs.com/package/@heroku-cli/plugin-pipelines

JavaScript 100.00%
pipelines heroku devex heroku-cli-plugin

heroku-pipelines's Introduction

Pipelines Plugin for Heroku Toolbelt

Package has moved to: https://github.com/heroku/cli/tree/master/packages/pipelines

js-standard-style

npm version build status

A Heroku CLI plugin for continuous delivery on Heroku.

This plugin is used to set up a collection of apps sharing a common codebase where the latest slug of one app can be promoted to the app(s) in the following stage. The promotion only copies the upstream build artifact and leaves the downstream app's config vars, add-ons, and Git repo untouched.

How to install this plugin

This plugin is installed by default with the Heroku CLI. You do not need to install it yourself. Just update your CLI:

$ heroku update

Using Pipelines

https://devcenter.heroku.com/articles/pipelines

Development

First, please read Developing CLI Plugins on Heroku's DevCenter.

Run Tests

$ npm test

Deploy

  1. Release a new version of this npm package.
$ npm version patch/minor/major
  1. Open a new pr in https://github.com/heroku/cli/blob/master/package.json, updating to the appropriate heroku-pipelines version.

Commands

heroku pipelines

list pipelines you have access to

USAGE
  $ heroku pipelines

OPTIONS
  --json  output in json format

EXAMPLES
  $ heroku pipelines
  === My Pipelines
  example
  sushi

heroku pipelines:add PIPELINE

add this app to a pipeline

USAGE
  $ heroku pipelines:add PIPELINE

ARGUMENTS
  PIPELINE  name of pipeline

OPTIONS
  -a, --app=app        (required) app to run command against
  -r, --remote=remote  git remote of app to use
  -s, --stage=stage    stage of first app in pipeline

DESCRIPTION
  The app and pipeline names must be specified.
  The stage of the app will be guessed based on its name if not specified.

EXAMPLES
  $ heroku pipelines:add example -a example-admin -s production
  Adding example-admin to example pipeline as production... done

heroku pipelines:connect [NAME]

connect a github repo to an existing pipeline

USAGE
  $ heroku pipelines:connect [NAME]

ARGUMENTS
  NAME  name of pipeline

OPTIONS
  -r, --repo=repo  (required) the GitHub repository to connect

EXAMPLES
  $ heroku pipelines:connect example -r githuborg/reponame
  Configuring pipeline... done

heroku pipelines:create [NAME]

create a new pipeline

USAGE
  $ heroku pipelines:create [NAME]

ARGUMENTS
  NAME  name of pipeline, defaults to basename of app

OPTIONS
  -a, --app=app        (required) app to run command against
  -r, --remote=remote  git remote of app to use
  -s, --stage=stage    stage of first app in pipeline
  -t, --team=team      team to use

DESCRIPTION
  An existing app must be specified as the first app in the pipeline.
  The pipeline name will be inferred from the app name if not specified.
  The stage of the app will be guessed based on its name if not specified.
  The pipeline owner will be the user creating the pipeline if not specified with -t for teams or -o for orgs.

EXAMPLES
  $ heroku pipelines:create -a example-staging
  ? Pipeline name: example
  ? Stage of example-staging: staging
  Creating example pipeline... done
  Adding example-staging to example pipeline as staging... done

heroku pipelines:destroy PIPELINE

destroy a pipeline

USAGE
  $ heroku pipelines:destroy PIPELINE

ARGUMENTS
  PIPELINE  name of pipeline

EXAMPLES
  $ heroku pipelines:destroy example
  Destroying example pipeline... done

heroku pipelines:diff

compares the latest release of this app to its downstream app(s)

USAGE
  $ heroku pipelines:diff

OPTIONS
  -a, --app=app        (required) app to run command against
  -r, --remote=remote  git remote of app to use

EXAMPLES
  $ heroku pipelines:diff --app murmuring-headland-14719

heroku pipelines:info PIPELINE

show list of apps in a pipeline

USAGE
  $ heroku pipelines:info PIPELINE

ARGUMENTS
  PIPELINE  pipeline to show

OPTIONS
  --json  output in json format

EXAMPLES
  $ heroku pipelines:info example
  === example
  owner: my-team (team)

  app name                     stage
  ───────────────────────────  ──────────
  ⬢ example-pr-16              review
  ⬢ example-pr-19              review
  ⬢ example-pr-23              review
  ⬢ example-staging            staging
  ⬢ example-staging-2          staging
  ⬢ example-production         production

heroku pipelines:list

list pipelines you have access to

USAGE
  $ heroku pipelines:list

OPTIONS
  --json  output in json format

EXAMPLES
  $ heroku pipelines
  === My Pipelines
  example
  sushi

heroku pipelines:open PIPELINE

open a pipeline in dashboard

USAGE
  $ heroku pipelines:open PIPELINE

ARGUMENTS
  PIPELINE  name of pipeline

EXAMPLES
  $ heroku pipelines:open example

heroku pipelines:promote

promote the latest release of this app to its downstream app(s)

USAGE
  $ heroku pipelines:promote

OPTIONS
  -a, --app=app        (required) app to run command against
  -r, --remote=remote  git remote of app to use
  -t, --to=to          comma separated list of apps to promote to

EXAMPLES
  $ heroku pipelines:promote -a example-staging
  Promoting example-staging to example (production)... done, v23
  Promoting example-staging to example-admin (production)... done, v54

  $ heroku pipelines:promote -a example-staging --to my-production-app1,my-production-app2
  Starting promotion to apps: my-production-app1,my-production-app2... done
  Waiting for promotion to complete... done
  Promotion successful
  my-production-app1: succeeded
  my-production-app2: succeeded

heroku pipelines:remove

remove this app from its pipeline

USAGE
  $ heroku pipelines:remove

OPTIONS
  -a, --app=app        (required) app to run command against
  -r, --remote=remote  git remote of app to use

EXAMPLES
  $ heroku pipelines:remove -a example-admin
  Removing example-admin... done

heroku pipelines:rename PIPELINE NAME

rename a pipeline

USAGE
  $ heroku pipelines:rename PIPELINE NAME

ARGUMENTS
  PIPELINE  current name of pipeline
  NAME      new name of pipeline

EXAMPLES
  $ heroku pipelines:rename example www
  Renaming example pipeline to www... done

heroku pipelines:setup [NAME] [REPO]

bootstrap a new pipeline with common settings and create a production and staging app (requires a fully formed app.json in the repo)

USAGE
  $ heroku pipelines:setup [NAME] [REPO]

ARGUMENTS
  NAME  name of pipeline
  REPO  a GitHub repository to connect the pipeline to

OPTIONS
  -t, --team=team  team to use
  -y, --yes        accept all default settings without prompting

EXAMPLES
  $ heroku pipelines:setup example githuborg/reponame -o example-org
  ? Automatically deploy the master branch to staging? Yes
  ? Wait for CI to pass before deploying the master branch to staging? Yes
  ? Enable review apps? Yes
  ? Automatically create review apps for every PR? Yes
  ? Automatically destroy idle review apps after 5 days? Yes
  ? Enable automatic Heroku CI test runs? Yes
  Creating pipeline... done
  Linking to repo... done
  Creating production and staging apps (⬢ example and ⬢ example-staging)
  Configuring pipeline... done
  View your new pipeline by running `heroku pipelines:open e5a55ffa-de3f-11e6-a245-3c15c2e6bc1e`

heroku pipelines:transfer OWNER

transfer ownership of a pipeline

USAGE
  $ heroku pipelines:transfer OWNER

ARGUMENTS
  OWNER  the owner to transfer the pipeline to

OPTIONS
  -c, --confirm=confirm
  -p, --pipeline=pipeline  (required) name of pipeline

EXAMPLES
  $ heroku pipelines:transfer [email protected] -p example
  === example

  app name              stage
  ────────────────────  ───────────
  ⬢ example-dev         development
  ⬢ example-staging     staging
  ⬢ example-prod        production

    ▸    This will transfer example and all of the listed apps to the [email protected] account
    ▸    to proceed, type example or re-run this command with --confirm example
  > example
  Transferring example pipeline to the [email protected] account... done

  $ heroku pipelines:transfer acme-widgets -p example
  === example

  app name              stage
  ────────────────────  ───────────
  ⬢ example-dev         development
  ⬢ example-staging     staging
  ⬢ example-prod        production

    ▸    This will transfer example and all of the listed apps to the acme-widgets team
    ▸    to proceed, type example or re-run this command with --confirm example
  > example

  Transferring example pipeline to the acme-widgets team... done

heroku reviewapps:disable

disable review apps or settings on an existing pipeline

USAGE
  $ heroku reviewapps:disable

OPTIONS
  -a, --app=app            (required) parent app used by review apps
  -p, --pipeline=pipeline  (required) name of pipeline
  --autodeploy             disable autodeployments
  --autodestroy            disable automatically destroying review apps

EXAMPLES
  $ heroku reviewapps:disable -p mypipeline -a myapp --autodeploy
  Disabling auto deployment ...
  Configuring pipeline... done

heroku reviewapps:enable

enable review apps and/or settings on an existing pipeline

USAGE
  $ heroku reviewapps:enable

OPTIONS
  -a, --app=app            (required) parent app used by review apps
  -p, --pipeline=pipeline  (required) name of pipeline
  --autodeploy             autodeploy the review app
  --autodestroy            autodestroy the review app

EXAMPLES
  $ heroku reviewapps:enable -p mypipeline --a myapp --autodeploy --autodestroy
  Enabling review apps ...
  Enabling auto deployment ...
  Enabling auto destroy ...
  Configuring pipeline... done

heroku-pipelines's People

Contributors

appleton avatar bigkevmcd avatar dmathieu avatar fivetanley avatar gudmundur avatar jdx avatar jmahmood avatar joshwlewis avatar karatecowboy avatar krummi avatar matthieuprat avatar rasphilco avatar raulb avatar rco-ableton avatar sibson avatar taytay avatar wadewegner avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

heroku-pipelines's Issues

Subtrees

Is it possible to get this working with subtrees. Currently it requires the app.json to be at the toplevel but im looking to push a client app one level down

pipelines:info does not honor the pipeline name parameter

According to the docs, I can do:

heroku pipelines:info <pipeline_name>

Which has been working fine for us, but suddenly today I get a scrollable list of dates that looks like this:

$ heroku pipelines:info example-pipeline
? Which example-pipeline pipeline? (Use arrow keys)
❯ Thu Oct 22 2015 07:33:31 GMT-0600 (MDT) 
  Thu Oct 22 2015 07:34:30 GMT-0600 (MDT) 
  Mon Jul 27 2015 06:04:10 GMT-0600 (MDT) 
  Thu Oct 22 2015 07:51:22 GMT-0600 (MDT) 
  Thu Oct 22 2015 08:13:02 GMT-0600 (MDT) 
  Thu Oct 22 2015 07:38:28 GMT-0600 (MDT) 
  Thu Oct 22 2015 07:36:34 GMT-0600 (MDT) 
(Move up and down to reveal more choices)

First none of these dates are helpful to me, and second, when I pick one, it is not the "example-pipeline" that asked for, it is a completely different pipeline.

Return error details when `pipelines:setup` fails

(I believe this is related to #83 but manifests and error that is a blocker for pipelines:setup.

When running the pipelines:setup command I got the error:

 ▸    Couldn't create application ⬢ pipelinedeleme-staging: invalid app.json

Digging in, it seems it's because my app.json requires vars that aren't set on the pipeline. Something like:

 "manifest_errors": [
    "config var \"DEV_HUB_SFDX_AUTH_URL\" is required",
    "config var \"SFDX_BUILDPACK_DEBUG\" is required"
  ],

However, that error wasn't exposed to me. I had to get support.

It would be good return the error so the developer knows what needs to be fixed.

As an aside, it appears that there's no way to resolve this with pipelines:setup because I don't have a way to run setup on a pipeline and set of apps that are already configured, and the command itself doesn't expose a way to set these vars.

Additional "nice to haves" for setting up piplines

  1. On enable/disable of autodeploy or autodestroy, provide an updated message to the user telling them exactly what we're doing. (@raulb's suggestion)

  2. Create a heroku pipelines:disconnect -p "pipeline" command. (@bigkevmcd's suggestion)

  3. Handle the following scenario better (I think this is due to the repo already being connected to a pipeline, but not sure why we get this kind of error, @bigkevmcd ):

$ heroku pipelines:connect "my-pipeline" -r "bigkevmcd/my-repo"
Linking to repo... !
 ▸    Response code 422 (Unprocessable Entity)
  1. For reviewapps:disable perhaps the help should say that if no options are provided, it will disable both (@bigkevmcd's suggestion)?

  2. The pattern from reviewapps:enable might be adopted where it outputs how it's interpreting the flags (@bigkevmcd's suggestion)?

if (context.flags.autodeploy) {
  cli.log('Disabling auto deployment...');
  settings.pull_requests.auto_deploy = false;
}
  1. Maybe reviewapps:enable should indicate after how many days the app will be autodestroyed?

setup task failing on linking to repo

I'm getting the following when running pipelines:setup:

$ heroku pipelines:setup some-app someorg/somerepo -y --org someorg
Creating pipeline... done
Linking to repo... !
 ▸    The `body` option must be a plain Object or Array when the `form` or `json` option is used

It seems as though the issue is happening here:
https://github.com/heroku/heroku-pipelines/blob/master/commands/pipelines/setup.js#L308

which leads to here:
https://github.com/heroku/heroku-pipelines/blob/master/lib/kolkrabbi-api.js#L26

I don't know if the issue is dependency version incompatibility or if one of the components isn't returning an expected value.

Make `pipelines:info` work with sudo without specifying user

Otherwise, it returns a 500:

--> GET /pipelines?eq[name]=PIPE_NAME
<-- 500 Internal Server Error
<-- {"id":"internal_server_error","message":"Internal server error."}
 ▸    Internal server error.
Error: Expected response to be successful, got 500

Fails silently with paranoid apps

$ h pipelines:promote -a paranoid-app-staging
Fetching app info... done
Fetching apps from paranoid-app... done
Starting promotion to production... !
Two-factor code: ********************************************
Fetching app info... done
Fetching apps from paranoid-app... done
Starting promotion to production... done
Waiting for promotion to complete... done

Promotion successful

Seems to require preauth first to work.

pipelines:add fails to exit when called from another node process

We are executing heroku commands with Node and when we call heroku pipelines:add if the command succeeds, the child process never exits which hangs the parent process.

We were using execFile, but I switched to spawn so we could watch the output. If the command is run directly from the terminal, it works fine. Since pipelines are not supported in the API yet, exec-ing the toolbelt is the easiest way to implement this that I know. If we should try to require this module and use it directly instead, we could try that I guess.

I tried this with Node 0.10, 0.12, and 4.2 with the same result. We can't use 5 yet, so I haven't tried that. We are transitioning off of 0.10 over the next few months, but we still need this work until then.

What our code is doing (with dummy names for pipeline and app instead of the variables we pass):

      var execFile = require('child_process').execFile,
        child;

      console.log('calling heroku pipelines ...');
      child = execFile('heroku', ['pipelines:add', 'my-pipeline', '--stage', 'development', '--app', 'my-app-name'],
        function (error, stdout, stderr) {
          if (error !== null) {
            console.log('$execFile error: ' + error);
          }
          console.log('$stdout: ' + stdout);
          console.log('$stderr: ' + stderr);
        });

With the resulting output:

calling heroku pipelines ...

but the callback is never called, the process doesn't exit, and the ps command still shows the heroku command running.

When using spawn to watch the output more carefully:

      var spawn = require('child_process').spawn,
        ls    = spawn('heroku', ['pipelines:add', 'my-pipeline', '--stage', 'development', '--app', 'my-app-name']);

      ls.stdout.on('data', function (data) {
        console.log('$stdout: ' + data);
      });

      ls.stderr.on('data', function (data) {
        console.log('$stderr: ' + data);
        //if (/^done/.test(data)) {
        //  console.log('killing');
        //  ls.kill('SIGQUIT');
        //}
      });

      ls.on('close', function (code) {
        console.log('$child process exited with code ' + code);
      });

With output:

$stdout: 
$stderr: Adding my-app-name to my-pipeline pipeline as development... 
$stderr: done

But we never get the 'close' event, and the process hangs.

Running the command directly in the terminal works fine:

$ heroku pipelines:add my-pipeline --stage development --app my-app-name
Adding my-app-name to my-pipeline pipeline as development... done
$ echo $?
0
$

Using the regex check for done in the stderr stream in the spawn example and force killing the process, or using the {timeout: 3000} option in execFile also work around the issue, but aren't very tidy.

pipelines:promote does not prompt for 2FA when necessary

When promoting to a paranoid app, I don't get prompted for 2FA entry:

maciek@mothra:~/code/herokudata$ h pipelines:promote -a herokudata-staging
Fetching app info... done
Fetching apps from herokudata... done
Starting promotion to production... done
Waiting for promotion to complete... done
 ▸    
 ▸    Promotion to some apps failed
herokudata: failed
            A second authentication factor or pre-authorization is required for this request. Your account has either two-factor or a YubiKey registered.

If I preauth this works fine, but is it possible to have pipelines handle this transparently if the app being promoted to requires 2FA for deploy?

Feature parity with Heroku Dashboard

Keeping track of features you can do in Dashboard, but not with the CLI today:

  • Create a pipeline (and adding an app to this pipeline)
$ heroku pipelines:create -a example-staging
? Pipeline name: example
? Stage of example-staging: staging
Creating example pipeline... done
Adding example-staging to example pipeline as staging... done
  • Delete a pipeline
$ heroku pipelines:destroy example
Destroying example pipeline... done
  • Add apps to a pipeline
$ heroku pipelines:add example -a example-admin -s production
Adding example-admin to example pipeline as production... done
  • Remove apps from a pipeline
$ heroku pipelines:remove -a example-admin
Removing example-admin... done
  • Promotions
$ heroku pipelines:promote -r staging
Promoting example-staging to example (production)... done, v23
Promoting example-staging to example-admin (production)... done, v54
$ heroku pipelines:promote -r staging --to my-production-app1,my-production-app2
Starting promotion to apps: my-production-app1,my-production-app2... done
Waiting for promotion to complete... done
Promotion successful
my-production-app1: succeeded
my-production-app2: succeeded
  • Enable/Disable CI in a pipeline
  • Connect a pipeline to GitHub
  • Disconnect a pipeline from GitHub
  • Enable automatic deploys
  • Disable automatic deploys
  • Enable destroying automatically idle review apps after 5 days
  • Disable destroying automatically idle review apps after 5 days
  • Enable review apps
  1. Ask for a parent app (based on apps already part of the pipeline)
  2. Enable (or not) automatic creation of review apps.
  3. Enable (or not) destroying stale review apps.
  • Disable review apps
  1. Warn existing ones will be deleted.
  2. Disable
  • Transfer a pipeline to another owner
  • Rename pipeline

pipelines:info should infer pipeline from cwd

Running heroku pipelines:info in a directory that is already associated with an app currently yields a

$ heroku pipelines:info
 ▸    Missing argument: PIPELINE

We could use the GET /apps/:id/pipeline-couplings endpoint to resolve the pipeline:id and then obtain information about the pipeline.

Provide a command to enable/disable review apps

Enabling

  1. Ask for a parent app (based on apps already part of the pipeline)
  2. Enable (or not) automatic creation of review apps.
  3. Enable (or not) destroying stale review apps.

Disabling

  1. Warn existing ones will be deleted.
  2. Disable

Pipeline not found

$ h pipelines:info api
=== api
Staging:    support-api-staging
Production: support-api

$ git remote -v
origin  [email protected]:heroku/support-api.git (fetch)
origin  [email protected]:heroku/support-api.git (push)
prod    https://git.heroku.com/support-api.git (fetch)
prod    https://git.heroku.com/support-api.git (push)
staging https://git.heroku.com/support-api-staging.git (fetch)
staging https://git.heroku.com/support-api-staging.git (push)

$ h pipelines:status -r staging
 ▸    Pipeline not found

Provide a way to use `pipelines:setup` on a pipeline that's already configured

Currently pipelines:setup create the apps for you. But there are cases where you already have these created and you want to add them to a newly created pipeline. And while you can do that today, you can't do it && run pipelines:setup to configure things like the assign git repo, enable review apps, etc.

Essentially, let me do the following (pseudo-code):

heroku apps:create mydev
heroku apps:create mystaging
heroku apps:create myprod

# ... configure those apps (vars, buildpacks, etc.) ...

heroku pipelines:create mypipe -a mydev-s development
heroku pipelines:add mypipe -a mystaging -s staging
heroku pipelines:add mypipe -a myprod -s production

# this is important because the app.json likely has required vars
heroku ci:config:set -p mypipe blah=blah

heroku pipelines:setup mypipe wadewegner/myrepo -y

Something like that.

Help text experience inconsistent

The behavior of heroku pipelines --help is inconsistent with the behavior of heroku apps --help, heroku pg --help, heroku spaces --help. I believe the behavior of the latter ones is correct.

I think this will become increasingly important as new pipelines sub-commands are added. After Ike's demo showing heroku pipelines:setup ... I bumbled around trying to find help to see how the setup sub-command works.

It looks like heroku pipelines --help is interpreted as heroku pipelines:list --help:

👉  heroku pipelines --help
Usage: heroku pipelines:list

list pipelines you have access to

 --json              # output in json format

Example:
  $ heroku pipelines:list
  === My Pipelines
  example
  sushi

However, what I expect is something more similar to the output of heroku apps --help:

👉  heroku apps --help
Usage: heroku apps

list your apps

 -A, --all           # include apps in all organizations
 -o, --org ORG       # organization to use
 -p, --personal      # list apps in personal account when a default org is set
 -s, --space SPACE   # filter by space
 --json              # output in json format

Example:

 $ heroku apps
 === My Apps
 example
 example2

 === Collaborated Apps
 theirapp   [email protected]

Commands for apps, type "heroku help apps:COMMAND" for more details:

 heroku apps                           # list your apps
 heroku apps:create [APP]              # create a new app
 heroku apps:destroy                   # permanently destroy an app
 heroku apps:errors                    # view app errors
 heroku apps:favorites                 # list favorited apps
 heroku apps:favorites:add             # favorites an app
 heroku apps:favorites:remove          # unfavorites an app
 heroku apps:fork                      # fork an existing app into a new one
 heroku apps:info                      # show detailed app information
 heroku apps:join                      # add yourself to an organization app
 heroku apps:leave                     # remove yourself from an organization app
 heroku apps:lock                      # prevent organization members from joining an app
 heroku apps:open [PATH]               # open the app in a web browser
 heroku apps:rename NEWNAME            # rename an app
 heroku apps:stacks                    # show the list of available stacks
 heroku apps:suspend                   # (sudo) suspend an app
 heroku apps:sync                      # (sudo) sync an app
 heroku apps:syncimplicits             # (sudo) syncs an apps implicit attachments
 heroku apps:transfer RECIPIENT        # transfer applications to another user, organization or team
 heroku apps:unlock                    # unlock an app so any organization member can join
 heroku apps:unsuspend                 # (sudo) unsuspend an app

If I have some time, I'll make a PR, but just wanted to get the issue documented first.

pipelines:promote expected behavior?

I have a Rails app on heroku right now. I may be making incorrect assumptions here, but I was expecting to be able to promote my staging app to production heroku pipelines:promote -a STAGING_APP and rely on my production environment variables to be swapped into place during rake assets:precompile on my production server. However, what I am seeing is that after a pipelines:promote the assets precompiled on staging are now on production, and are using the staging environment variables instead of production variables.

I found that when I manually deployed my master branch to my production server rake assets:precompile runs as expected and my assets are now using production env vars.

Is it recommended to have parity between staging and production env variables when using heroku pipelines? I feel like I may not be using pipelines as intended? Thanks for any clarification :) Also, lmk if there is a better place to ask this question

pipeline:diff fails when downstream app is paranoid

e.g.:

$ heroku pipelines:diff -a addons-staging
Fetching apps from pipeline... done
Fetching release info for all apps... done

addons-staging was not compared to addons as addons does not have any releases

$ heroku preauth -a addons
Two-Factor code: ********************************************

$ heroku pipelines:diff -a addons-staging
Fetching apps from pipeline... done
Fetching release info for all apps... done

addons-staging is ahead of addons by 10 commits:
  2973fb5  2015-12-07T23:50:03Z  Merge pull request #1319 from heroku/slug-validations (Bo Jeanes)
  79650fc  2015-12-07T20:44:38Z  Merge pull request #1312 from heroku/cdwort_small_addon_model_refactors (Bo Jeanes)
  8ec6b95  2015-12-07T20:28:42Z  Merge pull request #1316 from heroku/citext-slugs (Bo Jeanes)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.