This commit rewrites the `GitRepositoryReconciler` to new standards,
while implementing the newly introduced Condition types, and trying
to adhere better to Kubernetes API conventions.
More specifically it introduces:
- Implementation of more explicit Condition types to highlight
abnormalities.
- Extensive usage of the `conditions` subpackage from `runtime`.
- Better and more conflict-resilient (status)patching of reconciled
objects using the `patch` subpackage from runtime.
- Proper implementation of kstatus' `Reconciling` and `Stalled`
conditions.
- First (integration) tests that solely rely on `testenv` and do not
use Ginkgo.
There are a couple of TODOs marked in-code, these are suggestions for
the future and should be non-blocking.
In addition to the TODOs, more complex and/or edge-case test scenarios
may be added as well.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This likely happened because the byte buffer response was already
being read by the chart loader, making it empty by the time the
artifact was written to storage.
As an alternative, and because it makes the code a tiny bit less
obnoxious: write the data to a temp file first, and later decide
what file to copy over and use as an stored artifact.
Signed-off-by: Hidde Beydals <hello@hidde.co>
Adds a test that loads the helmChart from the updated resource and
verifies that `testOverride` (the value overrode in the test fixtures)
changes from `false` to `true`.
Signed-off-by: Dylan Arbour <arbourd@users.noreply.github.com>
As part of the feature implementation to support helm chart
dependencies, the functionality for allowing values files overwriting
from any location scoped to the same source was altered. This should fix
the problem by allowing users to load files from any arbitrary location
as long as it's in the context of the same source from where the helm
chart itself is loaded.
Signed-off-by: Aurel Canciu <aurelcanciu@gmail.com>
It looks like the use of chartutil.ProcessDependencies in the HelmChart
Controller was not correct, this method seems to be used in Helm only
during install/upgrade. The intention was to load the dependencies but
this seems to not be needed as it's already done through the loaders
(loader.Load).
The use of this method caused a regression where Chart.yaml files would
be overwritten and registered subcharts that had aliases would be
renamed using the alias name. While this is an expected behaviour of
chartutil.ProcessDependencies it is not what the controller should do
to the chart during (re)packaging.
Signed-off-by: Aurel Canciu <aurelcanciu@gmail.com>
Non-packaged charts that don't have their dependencies present in
charts/ will now have these dependencies built using the
DependencyManager. The idea behind it is to replicate the logic
implemeneted in Helm's downloader.Manager with the support for already
existing HelmRepository resources and their chart retrieval capabilities.
Signed-off-by: Aurel Canciu <aurelcanciu@gmail.com>