The usefulness of custom commands is dramatically less because I can't use values from environment variables. And I don't want to have to push my 'code' (groovy or python scripts, mvn commands, etc.) to a yet another wrapper script simply to access a value that GoCD already knows about. That's the entire reason for having custom commands in GoCD is it not ... to simplify the configuration of often used commands?
In my case, can't currently use parameters because: - I can't pass parameters via the GoCD RestAPI when scheduling pipelines. I can only pass in environment "variables" and can't use them anywhere in my pipeline except in a shell. - The "Configuration repository Extension" that allows YAML/JSON pipeline definitions as code does not support parameters as of today so I am having to restructure all pipelines that used parameters to using environment variables when translating from the XML to JSON and it makes the tasks ugly and harder to read. Why should it be one or the other? Why not both? Why not allow environment variables to be used wherever it makes sense ... even in custom commands that do not execute through a shell? I don't believe my suggestion diminishes or confuses the usage of environment variables vs parameters. The goal is to be able to call one of the MANY GoCD commands <https://docs.gocd.org/current/advanced_usage/command_repository.html> in a more generic fashion without having to wrap it in shell script just to access an environment variable. And while ranting a bit, I find the concept of parameter vs environment variables from a user perspective inherently confusing anyway, specifically because the API does not allow setting parameters when scheduling a new pipeline. Parameters seems to fit logically when scheduling a unique pipeline instance. Adding an additional use case for environment variables helps both increase the usefulness of custom commands (and environment variables), but it also (in my case at least) eliminates the need for parameters completely. - Jeff On Tue, Sep 19, 2017 at 4:54 PM, Darren Rowley <[email protected]> wrote: > I guess the problem is parameters are parameters and they are used at > configuration time in GoCd. Environment variables are Environment variables > and I expect them to be available in the environment if I provide one (like > bash where I can access environment variables and do clobbing etc). I think > if you move the environment variables resolution up into GoCd just before > execution it might muddy the issue of what environment variables are and > add a little bit of extra "black magic" to the process. Why not push your > "code' out of the GoCd tasks configuration and up into an overarching shell > script or such? I guess you also have good reasons why you can't use > Parameters? e.g. Like you are using Environments but parameter support is > non-existent? Maybe your coding efforts could be better channel elsewhere > :-) > > Anyway just my 0.02c > D. > > On Wednesday, September 20, 2017 at 4:44:14 AM UTC+12, Jeff Vincent wrote: >> >> Thanks. What are the chances of adding a feature as mentioned so GoCD >> will do the environment value substitution? >> >> I'm even willing to give the implementation a shot if someone could point >> me in the right direction. I've checked out the code but it's a beast :). >> >> Thanks! >> >> On Tue, Sep 19, 2017 at 3:45 AM, Aravind SV <[email protected]> >> wrote: >> >>> The closest I can think of for this, currently, is the script executor >>> task plugin. It will allow you to write a shell script there. I'm not a fan >>> of big scripts in the config, though. >>> >>> On Mon, Sep 18, 2017 at 1:24 PM, Jeff <[email protected]> wrote: >>> >>>> As far as I can tell, when wanting to pass environment variable values >>>> as input to a task, the only way I'm aware of for this to work correctly is >>>> to use the 'bash -c' command. For all of my tasks, I'm usually calling >>>> Groovy scripts and passing command-line options using the 'bash -c' method >>>> makes for a long and messy looking command. Here is an example: >>>> >>>> <exec command="/bin/bash" workingdir="dbmigration"> >>>> <arg>-c</arg> >>>> <arg>../continuous-deployment/src/OrchestrateFlywayDB.groovy >>>> -propertyFile ../materials/pipeline.properties -env $DEPLOY_ENV -user >>>> $FLYWAYDB_USER -password $FLYWAYDB_PASSWORD</arg> >>>> <runif status="passed" /> >>>> </exec> >>>> >>>> It would be really nice if there was a syntax for referencing >>>> environment variables that GoCD would use to do the environment variable >>>> substitution (similar to how parameters work) so I can call the tool (e.g., >>>> groovy) directly instead of wrapping it in a bash call. Possibly the >>>> syntax ${MY_ENV} which is similar to parameters. >>>> >>>> This would allow the tool to be called directly and the task definition >>>> would look more like: >>>> >>>> <exec command="groovy" workingdir="dbmigration"> >>>> <arg>../continuous-deployment/src/OrchestrateFlywayDB.groovy</arg> >>>> <arg>-propertyFile</arg> >>>> <arg>../materials/pipeline.properties</arg> >>>> <arg>-env</arg> >>>> <arg>${DEPLOY_ENV}</arg> *//<--ENVIRONMENT substitution by GoCD* >>>> <arg>-user</arg> >>>> <arg>${FLYWAYDB_USER}</arg> *//<--ENVIRONMENT substitution by GoCD* >>>> <arg>-password</arg> >>>> <arg>${FLYWAYDB_PASSWORD}</arg> *//<--ENVIRONMENT substitution by GoCD* >>>> <runif status="passed" /> >>>> </exec> >>>> >>>> Is there a way to do this today that I'm missing? If not, I've entered >>>> Issue >>>> #3863 <https://github.com/gocd/gocd/issues/3863> in case and wondered >>>> what the potential is for getting this feature added. >>>> >>>> Thanks! >>>> >>>> -Jeff >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "go-cd" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "go-cd" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "go-cd" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "go-cd" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
