Blueprint accepting OS-level environment variable

[zaerl]

This blueprint:

{
  "login": true,
  "steps": [
    {
      "step": "runPHP",
      "code": "<?php require_once 'wordpress/wp-load.php'; wp_insert_post( [ 'post_title' => 'env', 'post_content' => print_r( $_ENV, true ) ] );"
    }
  ]
}

Generates a post with this content:

Array
(
  [USER] => web_user
  [LOGNAME] => web_user
  [PATH] => /
  [PWD] => /
  [HOME] => /home/web_user
  [LANG] => C.UTF-8
  [_] => cli.ts
  [USE_ZEND_ALLOC] => 0
)

It can be a useful addition for blueprints started using the CLI in this way:

TEST="test" bun cli.ts server --blueprint=./test.json

To inherit the TEST environment var. This is a quite advanced option so it should be available only to PHPRunOptions. The env record should be open to be overwritten by the caller. Such as:

```json
{
  "login": true,
  "steps": [
    {
      "step": "runPHPWithOptions",
      "options": {
        "env": {
          "TEST": "false"
        },
        "code": "<?php require_once 'wordpress/wp-load.php'; wp_insert_post( [ 'post_title' => 'env', 'post_content' => print_r( $_ENV, true ) ] );"
      }
    }
  ]
}

So that it will be possible to write this for rapid prototyping:

TEST="true" bun cli.ts server --blueprint=./test.json

The CLI should have a list of env vars to exclude, such as other security measures.

Addendum: Apparently, $_ENV does not have the values passed if used in the code entry. This may be a bug.

[adamziel]

$ENV being empty does sound like a bug. getenv() works, though:

{
  "steps": [
    {
      "step": "runPHPWithOptions",
      "options": {
        "code": "<?php file_put_contents('/wordpress/index.php', getenv('IS_PRODUCTION')); ?>",
        "env": {
          "IS_PRODUCTION": "yes"
        }
      }
    }
  ]
}

It would indeed be nice if the CLI had an option to accept the OS-level env variables, or if there was something in Blueprints to define env variables for the entire Playground server. I'm hesitant of just loading all the env variables by default as that would breach the OS isolation we're getting from WASM AND some variables might actually introduce problems, e.g. $PATH or $HOME won't match any WASM filesystem paths.

[adamziel]

Out of curiosity – how would you use this?

[zaerl]

Out of curiosity – how would you use this?

For quick tests like this:

{
  "steps": [
    {
      "step": "runPHPWithOptions",
      "options": {
        "code": "<?php do_something( getenv( 'VALUE_TO_TEST' ) );",
        "env": {
          "VALUE_TO_TEST": "The default value"
        }
      }
    }
  ]
}

VALUE_TO_TEST="Another value" bun cli.ts server --blueprint=./test.json. So, you can force an environment variable without rewriting the blueprint if you want to check what happens.