* feat: Helmfile V1 mode
We add a new "V1 mode" to Helmfile so that you can seemlessly upgrade Helmfile from the current v0.x to the upcoming v1.0.
The idea is that we build both v0 and v1 binaries from the same tagged commit within the main branch, with different defaults for the "V1 mode"- the V1 mode is disabled by default for v0.x binaries, while it is enabled by default for v1.x binaries.
The V1 mode can be overrode at runtime via envvar. That is, even after upgrading the binary to v1, you will not see any backward-incompatible changes while you explicitly set an envvar, `HELMFILE_V1MODE=true`, at runtime.
Signed-off-by: Yusuke Kuoka <ykuoka@gmail.com>
Signed-off-by: yxxhero <aiopsclub@163.com>
* Enhance `make fmt` to cover running gci for golangci-lint compat
I have been using `make fmt` for formatting code before submitting a pull request. It turned out not to work in some cases where you added a new import because the default go-fmt obviously do not organize imports as the golangci-lint and gci expect.
This fixes that, by adding a gci command to the `make fmt` target.
Please note that this does not cover installing gci. If you need, please submit another pull request to add something like a `make install-gci` and make the `make fmt` depenedent on that target, so that one can get automatic gci installation when running `make fmt` for first time.
Signed-off-by: Yusuke Kuoka <ykuoka@gmail.com>
* We don't need running gci via make on CI as we already run it as part of golangci-lint run
Signed-off-by: Yusuke Kuoka <ykuoka@gmail.com>
Signed-off-by: Yusuke Kuoka <ykuoka@gmail.com>
It turned out that Helmfile has never had support for release template on `needs`.
This adds that, along with the new end-to-end test suite to verify helmfile template output with snapshot testing involving a real `helmfile build` command.
Ref #2098
- Add debian image based on `stable-slim`, desire for this is largely
around my use case using Azure DevOps which makes it challenging to
use images which are not glibc based.
- Drop support for helm2 in the docker images. This is a tricky one but
given that I was having errors during the docker build for helm2 and
the fact that it has been EoL for a long time now made me think that
this was the correct move.
- As a "while I'm in here" I've upgraded kubectl and helm. I've popped
on the most current patch of the last release (v1.20.3) to give a
slightly broader support for different Kubernetes versions.
- Reworked CI to support pushing a debian and alpine base, and dropped
support for the helm2 versions.
Summary of changes:
* Output any error from Mkdir in `helmfile template`
* Add failing test for .Release.Name interpolation
* Add golden files for testing
* Parse resources with kustomize to compare them structure by structure
* Decode resources into plain maps
The RNode type from kustomize uses yaml.Node under the hood,
which carries extra information like line numbers, which
become noisy when comparing with deep.Equal.
Adds the Dockerfile for Helm v3(Dockerfile.helm3) that contains both Helmfile and Helm v3(currently 3.0.0-rc.2).
Changes the CircleCI workflow to include a job to build the v3 image on every PR. The release job is enhanced to build and push the image with a tag prefixed with `helm3-`. So the resulting image should be available via e.g. `quay.io/roboll/helmfile:helm3-v0.90.5`.
* feat(report): display summary of upgraded, deleted and error releases
* feat(#502): adds dep target in makefile
* feat(#502): removes vendor and fixes pristine in makefile
* use golang 1.10.1 images everywhere
* introduce a `static-linux` target to build a statically linked 64-bit binary only
* use that binary for the official image and the circle build and tests
* use a multi-stage dockerfile for a consistent build environment
yxxhero
Lavi Blumberg
Yusuke Kuoka
yxxhero
Bernhard M. Wiedemann
austin ce
Quan TRAN
Micah Huber
Jake Hill
astorath
Andrey Tuzhilin
James Strachan
ento
刘相轩
sgandon
Patrick Valsecchi
Cedric Meury