$dev_fqdn and $prod_fqdn behavior is confusing

[KevinMGranger]

While experimenting with opsweekly, one of the more confusing issues I faced was why the config for my team wasn't loading. I eventually realized that I had assumed $dev_fqdn and $prod_fqdn were optional (even though it doesn't say they are-- my mistake!), and didn't specify them -- causing the preg_replace to fail, and my $fqdn appear to be null!

I want to understand what the use case is for this feature. You hit opsweekly on a vhost for testing, which otherwise loads a team config for a different team, right? Doesn't this cause an issue for every single link that references $fqdn, because that will link away from the testing environment into prod?

I have a change in waiting that should:

• make this behavior clearer
• document it more
• make the _fqdns optional
• add unit testing for all of the above behaviors

but I want to make sure I understand the original inspiration first.

[lozzd]

Ah, that is interesting.

The use case is that the configuration ends up being shared between VMs (for development) and prod. As you say, these machines have different vhosts, so we want opsweekly to understand to listen for both the dev and prod FQDNs, especially because we have over 10 different weekly.domain.com instances, so our Apache vhost is a wildcard for *weekly.domain.com.

Looking back over the config it is slightly vague what those parts do. Documenting it better, making it optional (but keeping existing behaviour sane, happy to test that), and improving the error handling (if it ends up being null, that could probably just emit an error instead) all sound great.