Add default Env variable SUP_RELEASE

[stengaard]

The problem

Naming a release consistently across hosts is hard (since time might be off between hosts).

The proposed solution

Introduce SUP_RELEASE as a "global" variable like SUP_NETWORK. The idea is stolen from Capistrano.

SUP_RELEASE would be assumed to be unique and be time ordered.

[pkieltyka]

@stengaard you can use:

networks:
  production:
    env:
       APP_RELEASE: whatever
    host:
      - 192.168.0.1

commands:
  ...

[pkieltyka]

I'm not sure what the default value for SUP_RELEASE would be.. that it would be so consistent and useful. Can you explain more.. with examples

[stengaard]

Sorry - I wasn't clear.

network.Env["SUP_RELEASE"] = time.Now().Format("20060102150403")

in https://github.com/pressly/sup/blob/d406a20610c1f0035b04ac97ef5b6f688f67231a/cmd/sup/main.go#L100

That would make SUP_RELEASE sortable alphanumerically.

This would mean that you could do

networks:
  production:
    env:
       APP_RELEASE: whatever
    host:
      - 192.168.0.1

commands:
  get:
    run: wget http://s3/code.tgz -O /tmp/code.tgz
  extract: 
    run: mkdir -p /app/releases/$SUP_RELEASE && cd /app/releases/$SUP_RELEASE && tar -xzpf /tmp/code.tgz 
  link:
    run: ln -s /app/releases/$SUP_RELEASE /app/current 
 ...

Clean up could then be:

• remove old releases: ls -r | tail -n 4 | xargs rm -rf
• Cleanup in case of failed deploy code is easier: rm -rf /app/releases/$SUP_RELEASE

[pkieltyka]

ah I see. I would rather call it like SUP_TIMESTAMP or something like that, to reflect that its just the current time..

[stengaard]

Agreed - the name isn't perfect. SUP_TIMESTAMP doesn't really communicate that it's the timestamp from the CLI invocation though, but it's better.

[pkieltyka]

yea I agree, we can come up with something better still

[stengaard]

SUP_DEPLOY_ID? SUP_DEPLOY? SUP_START_TIME? SUP_NEXT_RELEASE?

[VojtechVitek]

How about passing ENV VARs from the CLI (Docker style)?

$ sup --env TIMESTAMP=$(date) production deploy

[stengaard]

SUP_DOG? ;)

[stengaard]

That seems very do-able. But wouldn't that quickly lead to situations where you forgot the exact combo of env vars and couldn't get your bundle of scripts to do the same thing as last time you deployed?

[eduardonunesp]

@VojtechVitek hey ENV VARs from CLI is a good idea :+1:

But add some internal ENV VARs are something that add flexibility to the project as well, like SUP NETWORK added. Many commands can be cumbersome, but adding embed ENV VAR are lovely

[VojtechVitek]

@stengaard ENV VARs from CLI will be useful for much more scenarios than this one.

To be honest, to get the "RELEASE_STRING", you should be using git tags or something similarly more permanent.. For example, we're using git describe --tags --long --dirty for LONG_VERSION and git describe --tags --abbrev=0 for SHORT_VERSION.

btw: To double check that you don't forget to set an ENV VAR, you could use a command check: test -z "$VAR" && exit 1 ||:;

[stengaard]

@VojtechVitek - yeah the git SHA is good as it guaranteed to be unique, but it doesn't also give you an ordering. To get both we could combine the two (not sure values in env is env var expanded):

networks:
  production:
    env:
       APP_RELEASE: $SUP_RELEASE-$GIT_SHA
    host:
      - 192.168.0.1

commands:
  get:
    run: wget http://s3/code.tgz -O /tmp/code.tgz
  extract: 
    run: mkdir -p /app/releases/$APP_RELEASE && cd /app/releases/$APP_RELEASE && tar -xzpf /tmp/code.tgz 
  link:
    run: ln -s /app/releases/$APP_RELEASE /app/current 
 ...

But note: you could end up redeploying the same version of the code several times.

[stengaard]

SUP_UNIQUE_ID?