Use Metadata env variables in deploy script

[dboek]

Is it possible to use metadata, like the branch name in the deploy script?

I have the following scenario: If a test was successful the corresponding feature branch should be deployed. But I don't want to deploy the bundle, I just want to execute a script that launches a docker container on the remote system handing over the branch name. In the container the feature branch will be checked out and build. So I would like to use the metadata env variables from the metadata plugin and use it in the ssh deploy script.

Is this a valid use case for you or others, as well?

[kfatehi]

Hi @dboek

If it's something you'd use, then yeah I would say it's valid.

As far as implementation... we need a way to inject environment variables into the remote session. Looking at ssh2 it seems there's a way to do that.

On this line https://github.com/Strider-CD/strider-ssh-deploy/blob/master/remotely.js#L19 our call to #exec would need to now take 3 arguments where the middle one is passed an options hash containing the env hash we want to inject. From the ssh2 readme:

• exec(< string >command[, < object >options], < function >callback) - (void) - Executes command on the server. Valid options properties are:
  • env - < object > - An environment to use for the execution of the command.

I'm just not sure how to access the env hash after the metadata and env plugins have executed. @jaredly might know. In any case the first thing to do is to make sure the above change to #exec will work and give you the env var in the scope of your remote shell script -- if so there's multiple ways to populate that, including detecting a peer dependency of strider-metadata and providing its UI inline within the config for strider-ssh-deploy or something like that.

[dboek]

Thanks for your response. I will hack the deploy module on my side and try to hardcode the third argument and see if this works as expected - but I think this is exactly the functionality I need.

[dboek]

tried to hack the exec call with conn.exec(script,{'env':{'STRIDER':'production'}},function(err, stream) { afterwards I did an echo on $STRIDER, but the variable doesn't seem to be transmitted. Will run some other tests to check where it gets stuck. I had another idea looking a the slack plugin. There you allow to use params in the input fields, that get evaluated later like <%= ref.branch %> -- that is maybe an easier solution, because during the deploy I just want to run a shell script handing over some dynamic information: ./deploy.sh <%= ref.branch %> <%= ref.username %>

[kfatehi]

@dboek yeah I thought about the ejs template approach too -- that's not a bad idea and is definitely much easier and less hacky. thanks for investigating the ssh2 environment variable approach though

[dboek]

and if necessary env variables can be set directly in the script field. I will have a look at how ejs is implemented in the slack plugin.

[dboek]

pressed the wrong button

[dboek]

Ok, when I use ejs in deploy.js it works quite nicely:

var ejs = require("ejs");
......
var compiled = ejs.compile(config.script,'utf-8');
var deployScript = compiled(context.job);

function proceed(scp) {
  var promises = _.map(hosts, function(sshOpts) {
    return remotely.deploy(
      context.out, projectName, deployScript, sshOpts, scp
    )
    .......

In the deploy input field I can use all meta information:

./deploy.sh <%= ref.branch %>

Am I missing something?

[kfatehi]

@dboek cool, so it's working ?

[kfatehi]

If it's working send a pull request, let's merge it :)

[dboek]

@keyvanfatehi jap it's working, will create the pull request :-)

[kfatehi]

Nice work!