Ability to configure ENV

[dantran]

My build need to set NODE_TLS_REJECT_UNAUTHORIZED=0, rather than heavily depend on jenkins, I like to do it inside Maven pom, so i can run every where.

[eirslett]

Try sending a PR to Apache Maven?

[dantran]

Why do you think this fix should be at Apache Maven? frontend plugin invokes a command line tool so it should provide a way for user to inject env variable

[jackson-chris]

Not sure which nodeJS version you are using, but have you tried adding the following configuration to your npm goal using the arguments element?

     set strict-ssl false <npm command>

[dantran]

@blindenvy how does your solution translate into Maven npm goal configuration?

[jackson-chris]

It might be easier if your provide more context around what you're trying to accomplish? My solution was making the assumption that you were trying to execute the npm command using this plugin and wanted to bypass server verification. Was that assumption correct?

[dantran]

Currently, the current npm install goal fails due corporate fireware screw up in term ssl rewriting when npm reaches outside to download onf of dependency package. Fixing this is beyond our control. The work around is to inject the mention env var before invoking npm commnad. To be generic, I ask for the capability to inject any env var
Thanks

[jackson-chris]

Try adding the following configuration to your execution with a goal of npm:
<configuration>
<arguments>set strict-ssl false install</arguments>
</configuration>

Obviously you can add more arguments there if needed.

[dantran]

when i configure the setttings per your recommendation, the command just skip. No error. of course it will fail what ever next command is

[INFO] --- frontend-maven-plugin:0.0.22:npm (npm install) @ xxxx-ui ---
[INFO] Running 'npm set strict-ssl false install --color=false'

[eirslett]

Can you try using an .npmrc file?

[dantran]

in turn out strict-ssl (regardless it is from command line or from .npmrc) does not solve the issue. Here is the error

[INFO] > node_modules/grunt-protractor-runner/node_modules/protractor/bin/webdriver-manager update
[INFO] Updating selenium standalone
[INFO] downloading http://selenium-release.storage.googleapis.com/2.42/selenium-server-standalone-2.42.0.jar...
[INFO] Updating chromedriver
[INFO] downloading https://chromedriver.storage.googleapis.com/2.10/chromedriver_linux64.zip...
[ERROR]xxxxxx

The Protractor installation itself tries to download chromedriver

[jackson-chris]

It appears to me that you need to modify the configuration for protractor. Take a look at https://www.npmjs.com/package/grunt-protractor-runner for more info. You will see the following argument:

chromeDriver string: Location of chrome driver overridng the property in config file

You want to override the location where the chromedriver is downloaded from to an http option, not an https option. So you would modify your grunt file in your project to include a protractor section similar to this:
protractor: {
options: {
args: {
chromeDriver: "http://chromedriver.storage.googleapis.com/2.10/chromedriver_linux64.zip"
} } }

Note simply copying and pasting the above isn't going to work. Please see the documentation I pointed you to.

[dantran]

@blindenvy thanks, this may work, but supporting ENV is much more generic. Today I have a need to configure more ENV to make maven build much more isolation,

see

#163

[wherget]

Aside from the fact that @dantran has a different underlying issue (which may or may not be worked around using other configuration means), I too find the ability to check for environment variables in spawned build processes very handy for customising a given build run.
I know, you already have the <arguments> configuration, and conceivably one could throw everything in there and parse it back out again on the node end, for which there exist good libraries. Still, you're dealing with string concatenation and quoting for the command line when going down that route, which I find highly irritating. Environment variables are probably a sensible thing to have either way.
That's why I quickly knocked out these couple commits in the PR. I know it's not very pretty, but I'm open for discussion on that.

[lalomartins]

There's all sorts of reasons why you could want to pass build properties to your node scripts, and ENV is the best way to do that. Right now I'm working around it by using https://github.com/Aleks-Ya/write-text-files-maven-plugin to write an npmrc, but that's too ugly to live.

[csvan]

Being able to pass env var would help yarn installs which require env tweaks, e.g.

yarnpkg/yarn#1538

[blacelle]

it would also enable adding sonething like CI=1 as prefix
cypress-io/cypress#1243

it seems also available with:

<configuration>
	<arguments>ci</arguments>
	<environmentVariables>
		<CI>1</CI>
	</environmentVariables>
</configuration>