Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More-idiomatic initialization of Steps #73

Merged
merged 9 commits into from
Jan 20, 2020
Merged

More-idiomatic initialization of Steps #73

merged 9 commits into from
Jan 20, 2020

Conversation

ErinCall
Copy link
Contributor

@ErinCall ErinCall commented Jan 17, 2020

For #67

The main thrust of this change is to use the go convention of NewTHING functions to initialize the structs in internal/run instead of constructing struct literals in plan.go. Unfortunately, it'ss a big honkin' diff that touches almost every source file in the repo. It's probably easier to read in two chunks:

  1. Initialize the various Steps with NewSTEPNAME functions
  2. Firm up the separation-of-concerns boundary between the run and helm packages

Alternatively, starting with the diffs for internal/helm/plan.go and internal/run/depupdate.go should give you a reasonably-clear overview of what's happened--plan.go shows how the run package's public interface has changed, while depupdate.go is a fairly short file that demonstrates the changes to the Steps.

Pre-merge checklist:

  • Code changes have tests
  • Any config changes are documented: (n/a)
    • If the change touches required config, there's a corresponding update to README.md
    • There's a corresponding update to docs/parameter_reference.md
    • There's a pull request to update the parameter reference in drone-plugin-index
  • Any large changes have been verified by running a Drone job

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.
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.
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.
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).
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.
(Just something I happened across while writing the previous commit)
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 a general-purpose cleanup commit; every step except InitKube had
the same six "add the --debug and --namespace flags if applicable" code.
@ErinCall ErinCall changed the title Godiomaticity More-idiomatic initialization of Steps Jan 17, 2020
@ErinCall ErinCall merged commit ee6d8d1 into master Jan 20, 2020
@ErinCall ErinCall deleted the godiomaticity branch January 20, 2020 19:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants