- In ResMap, drop concept of internal Id to Resource
map. The ResMap is now (just) a list, allowing only
very particular edits.
- Resources should now be maintained in the order
loaded. A later PR can adjust tests to remove the
internal legacy sorting, and confirm order-out is
predictable from order-in. The PR would suppress
the sort in tests, and reorder the output to make
all tests pass again, and confirm that the new order
matched depth-first input traversal. The FromMap
fixture function was removed from all test inputs to
establish a predictable input order.
- Resources now have two 'Ids', OriginalId and
CurrentId. The former is fixed as
GVK-name-namespace at load time, the latter changes
during transformations. The latter can be used to
narrow name references when the former maps to
multiple resources. We allow bases to be loaded
more than once in a build (a diamond pattern), so
the OriginalId is not unique across the resources
set. The CurrentId is (and must be) unique, but is
constantly mutating. Failing to make this
distinction clear, and attempting to maintain a
mapping from a single mutating Id to a resource was
making the code too complex.
- Drop prefix/suffix from ResId - the ResId is now
immutable. A later PR can remove the distinction
with ItemId.
- This PR increases coverage of ResMap is since this
is a large refactor. Higher level tests didn't need
much change outside reordering of results at the
resource level.
Do a longstanding TODO to remove kustomizationerror.
It wasn't used much, and it wasn't used consistently,
because it's complicated to decided when it's worth
proceeding to accumulate errors when one already knows
that one has a fatal error in the kustomization. Its
use was blocking refactoring for simplicity and making
tests harder to write.
Removing it lets us reinstate the cyclomatic complexity
check in KustTarget.
Also added more info to the affected error messages.
Fixes#366
To reproduce #366, add
```
bases:
- .
```
to `examples/helloWorld/kustomization.yaml`, attempt to build it, and enjoy the stack overflow.
This PR fixes this by adding history to file loaders,
allowing one to avoid cycles in overlay->base
relationships. To make entry points clearer, this PR
exposes only two public ways to make a fresh
(no-history) loader
* rooted at `/`
* rooted at the process's current working directory.
When making a new loader from an existing loader,
retaining history along an overlay trace, the only
allowed use is to go deeper into a file hierarchy, or
go up and over to a never before visited sibling. This
fix can probably be defeated by devious symbolic links.
