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.
The goal with these changes was to give users a clearer, more readable
interface, so we should present that interface up front and only
document the aliases as a backward-compatibility option.
I've renamed the envconfig tags to reflect the switch, but I left the
actual field names the same. I think they're sufficiently meaningful
inside the code, and leaving them unchanged avoids making a bunch of
churn in the rest of the code.
This includes a refactor to the way aliases are processed. I had been
thinking in terms of locking down the aliases names pretty tightly, in
order to provide an error if there are conflicts. After discussion with
@josmo, though, it seems like we can do it the same way we do for
"PLUGIN_"/non-prefixed variables, i.e. quietly override them.
I don't love the mismatch between the helm.Config field (CleanupOnFail)
and the setting name (cleanup_failed_upgrade). I do think the setting
name should contain "upgrade" since it's specific to the upgrade command,
but if I make the config field CleanupFailedUpgrade, it becomes the new
longest field name, and gofmt creates a bunch of churn. Is that a good
enough reason...?
Just something I noticed while resolving a merge conflict. The "write
some docs" and "implement prefix" branches happened concurrently and
didn't get re-coordinated.
Helm2's --timeout took a number of seconds, rather than the
ParseDuration-compatible string that helm3 uses. For backward-
compatibility, update a bare number into a duration string.
We'd like to support it eventually, but the current state of affairs
doesn't justify the effort.
Also removed some vestigial code that was copy-pasta from the kubeconfig
in drone-helm.
These comments were a reasonable attempt at ensuring the documentation
matched reality, but the checkbox in the pull request template is much
more likely to produce results.
As I skimmed through that section I noticed it wasn't immediately clear
whether a line of text was referring to the example above it or the one
below it.
It seems like this needs more information, like why you'd want to put
something in one stanza or the other, but I don't really know enough
about drone to give useful advice.
Erin CallandGitHub