Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Passing arguments with '=' inside does not work as expected #1226

Closed
andersosthus opened this issue Apr 19, 2016 · 6 comments
Closed

Passing arguments with '=' inside does not work as expected #1226

andersosthus opened this issue Apr 19, 2016 · 6 comments

Comments

@andersosthus
Copy link
Contributor

Description

I'm trying to pass in an argument from my build system to the build script. This argument is a BASE64 string. It looks something like this: c3VwZXJzZWNyZQ==. When the argument reaches my code, it's missing the trailing == (the padding).

Repro steps

  1. Save the following script:
#r @"packages/FAKE/tools/FakeLib.dll"
open Fake

let secret = getBuildParamOrDefault "secret" ""

Target "Test" (fun _ ->
    traceFAKE "SECRET %s" secret
)

"Test"
RunTargetOrDefault "Test"
  1. Call it with FAKE.exe repro.fsx Test secret=c3VwZXJzZWNyZQ==

Expected behavior

Expected the line SECRET c3VwZXJzZWNyZQ== to be printed, showing that the value is correct with what has been passed in.

Actual behavior

SECRET c3VwZXJzZWNyZQ is printed (notice the missing ==).

Known workarounds

I could manually pad the base64 string to the correct length, but that's messy. I've tried all sorts of escaping, without any luck.
I could also temp store it in an env variable I assume, but since the value is a secret, I'd rather not.

Related information

  • Operating system - Windows 10 Pro Insider Preview 14316
  • Branch - FAKE - F# Make "4.25.4"
@inosik
Copy link
Contributor

inosik commented Apr 20, 2016

Seems to be a problem with the "old" argument parsing, FAKE.exe -ev secret c3VwZXJzZWNyZQ== works for me.

@andersosthus
Copy link
Contributor Author

@inosik yes, that seems to work fine. One question about this:
Accordig to the help documentation, the switch does the following: --envvar [-ev] <string> <string>: Set environment variable <name> <value>. Supports multiple..

I also updated my test code to the following:

#r @"packages/FAKE/tools/FakeLib.dll"
open Fake

let secretarg = getBuildParamOrDefault "secret" ""
let secretenv = environVar "secret"

Target "Test" (fun _ ->
    traceFAKE "SECRET ARG %s" secretarg
    traceFAKE "SECRET ENV %s" secretenv
)

"Test"
RunTargetOrDefault "Test"

When using the -ev key value switch, both trace statements show the correct value. But according to the -ev documentation, I would only expect the second one to be correct.

@inosik
Copy link
Contributor

inosik commented Apr 20, 2016

FAKE handles it's parameters as environment variables. In fact, the BuildParam functions call the environVar function.

There might be some clarification needed about this, though. I remember asking the same questions as you, and ended looking up the source.

@andersosthus
Copy link
Contributor Author

Oh, that's really not what I expected :)

I guess in most cases that's a valid approach, but when having to pass in secrets to the build process it would be prefered not to have them set as env variables. Especially now that more and more are using shared/semi-shared build services.

I haven't looked at the source yet, but it do look like FAKE either cleans up these variables after it's done, or start up an internal process where they are set, because I'm unable to see them after the build is done, so that's good.

@inosik
Copy link
Contributor

inosik commented Apr 20, 2016

FAKE sets them as environment variables in process scope. It's children processes (fsi.exe and all the tools you call from your script), therefore have access to them, too. After FAKE.exe terminates, the variables get cleared.

@andersosthus
Copy link
Contributor Author

Thanks @inosik,

That makes it more workable :) I think I can live with that for now, though I do think that this whole part should maybe have had a look-over at some point, if nothing else on the documentation side, since it was at least a bit confusing to me.

I can't help much with the coding part of this (F# isn't my strongest language), but I'll see if I can't add a PR to expand the documentation on this.

@forki forki closed this as completed in cac15ad Apr 27, 2016
forki added a commit that referenced this issue Apr 27, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants