Add support to store environment variables as facts #13
Conversation
|
Not in this form yet, which is why it's a draft. In theforeman/puppet-pulpcore#123 I did test the approach. Will continue on it later because I need the same thing in multiple places. |
|
@ekohl I actually wanted to use environment variables from CI in the hyperglass example so this is great!. |
|
Suggest that we always add a fact (aside from ---
version: 5
defaults:
datadir: data
data_hash: yaml_data
hierarchy:
- name: "Acceptance testing with Beaker"
path: "beaker/%{facts.beaker}.yaml"
- name: "common"
path: "common.yaml" |
|
I did think about that. Perhaps it could be unified with the beaker tier. We don't really use it in our tests, but you can use it. Then it uses tags. However, I am hoping https://github.com/puppetlabs/beaker-hiera will be unarchived and moved to VP. Then we can properly add that supposed and easily sync over a test set without resorting to putting those in the main hierarchy. It will also be useful to configure external modules. |
This code converts BEAKER_FACTER_* env vars to facts on target machines. This allows testing variations. While this is similar to tiers, it's not really the same. For example, a tier can be single node vs multi node, but those can both be run with multiple versions.
ekohl
force-pushed
the
env-vars-to-facts
branch
from
eb153e2 to
3e8bd4c
Compare
|
Updated. Now with fewer bugs and more documentation :) |
|
|
||
| if beaker_facts.any? | ||
| require 'json' | ||
| on(hosts, "mkdir -p #{File.dirname(FACT_FILE)} && cat <<VOXPUPULI_BEAKER_ENV_VARS > #{FACT_FILE}\n#{beaker_facts.to_json}\nVOXPUPULI_BEAKER_ENV_VARS") |
There was a problem hiding this comment.
took me a little while to wrap my head round this bash heredoc, but it does look correct.
There was a problem hiding this comment.
Yes, it's a bit obscure. However, the alternative was using scp_to and that wasn't great either. Ideally beaker would have something like write_to_file(destination, content).
This code converts
BEAKER_FACTER_*env vars to facts on target machines. This allows testing variations. While this is similar to tiers, it's not really the same. For example, a tier can be single node vs multi node, but those can both be run with multiple versions.Inspired by voxpupuli/puppet-hyperglass#15 (comment)