I definitely thought this rule was already in effect--I had a
`build/.gitignore` that contained just `*`. Unfortunately, that makes
git ignore the .gitignore file itself, so it was never added to the
repo...
It was never supposed to be part of the repo, and currently accounts for
at least half of the .git directory's size. We need to nip it in the bud
before `git clone` times become unmanageable!
While testing this I discovered the secrets are revealed anyway, since
the lint/upgrade jobs' debug output includes the command they generated.
Might as well make the code a little simpler.
This should be a more flexible option since certificates aren't likely
to be part of the actual workspace and may be environment-dependent. It
also mirrors the kube_certificate, which is nice.
Followup to discussion on #75. The important part is to have them
consistent, and I like the lowercase a little better since it matches
the casing in parameter_reference.md (and the code doesn't yell at me
:))
This fixes the run package's leaky abstraction; other packages no longer
need to know or care that run.Config even exists.
Note that since the various Steps now depend on having a non-nil pointer
to a run.Config, it's unsafe (or at least risky) to initialize them
directly. They should be created with their NewSTEPNAME functions. All
their fields are now private, to reflect this.
This is the first step toward removing run.Config entirely. InitKube was
the only Step that even used cfg in its Execute function; the rest just
discarded it.
Now that the InitKube initialization happens inside its own package, the
private .values field can be populated at the same time, rather than
having to wait for Prepare().
Also clarified the config/template filename fields (configFile vs.
ConfigFile was particularly ambiguous).
Now that InitKube, AddRepo, and UpdateDependencies are initialized with
NewSTEPNAME functions, the helper functions in plan.go are
unnecessary--they do too little to be a useful abstraction, and they
aren't complex or frequently-used enough to be worth extracting.
This seems to be be a more natural separation of concerns--the knowledge
of which config fields map to which parts of a Step belong to the Step,
not to the Plan.
I'd like to be able to make calls like NewUpgrade(cfg) rather than
Upgrade{...}.Prepare, but I wouldn't be able to define a NewUpgrade
function while Config is in the helm package; there would be a circular
import when Plan tried to import run.
While writing docs in the previous commit, I noticed that we'd been
inconsistent in the naming scheme. Wikipedia's back-compat article
redirects from "backwards" to "backward", so I figure that's a
reasonable source of authority for which form to use.
