how i fix this error ?

rpc error: code = Unknown desc = Manifest generation error (cached): `argocd-lovely-plugin` failed exit status 1: 2022/11/25 12:36:32 exit status 1: Error: no cached repository for helm-manager-daf1ee1308783e5bff6495f156b188a0ededf4f6125cc2a5c95c7274583672ee found. (try 'helm repo update'): open /tmp/.helm/cache/repository/helm-manager-daf1ee1308783e5bff6495f156b188a0ededf4f6125cc2a5c95c7274583672ee-index.yaml: no such file or directory

everything seems to be in working order when kustomization.yaml does not reference ../ but as soon as you include a base in the parent directory (at the same level at the directory polled by lovely plugin) everything breaks because lovely plugin does not copy all the resources like argocd kustomization support does. (kustomization including parent directory content for base works in native argocd)

Created this pr because i have some helm charts with conditions based on k8 version with this change i can add the param --kube-version to the helm tempalte command using an new optional environment variable

example export LOVELY_HELM_TEMPLATE_PARAMS="--kube-version 1.21"

Given a simple kustomization like

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../../../base/namespaces

and ArgoCD Application without lovely plugin, it works as expected, base is included and deployed properly.

However, when lovely plugin is included in the same Application:

apiVersion: argoproj.io/v1alpha1
kind: Application
...
spec:
  source:
    ...
    path: k8s/[omitted]/overlays/_cluster/namespaces
    plugin:
      name: argocd-lovely-plugin
...

an error is thrown:

rpc error: code = Unknown desc = Manifest generation error (cached):
 `argocd-lovely-plugin` failed exit status 1: 2022/10/13 15:19:41 
Error: accumulating resources: accumulation 
err='accumulating resources from '../../../../base/namespaces': 
evalsymlink failure on '/base/namespaces' : 
lstat /base: no such file or directory': 
evalsymlink failure on '/base/namespaces' : 
lstat /base: no such file or directory

Does lovely plugin support inclusion of base?

ArgoCD version: 2.4.12 Lovely version: 0.6.4 Kustomize version: 4.4.1

Hey, first of all I want to say thank you for this cool project.

Our OPA-Gatekeeper does not allow containers running as root user. The InitContainer argocd-lovely-plugin:0.4.1 is running as root user. I tried to create my own Dockerfile, but always getting the following InitContainer error as soon as I deploy with ArgoCD:

mv: can't remove 'argocd-lovely-plugin': Permission denied

With the Dockerfile, I tried to create my own user and change the owner of the /argocd-lovely-plugin file:

FROM ghcr.io/crumbhole/argocd-lovely-plugin:0.4.1

USER root

# Create a group and user
RUN addgroup -S app -g 1000 && adduser -S app -u 1000 -G app \
 && chown -R 1000:1000 /argocd-lovely-plugin

# Tell docker that all future commands should run as the appuser user
USER 1000

# the following commands are only for traceability
RUN id
RUN ls -l /
RUN ls -ln /argocd-lovely-plugin
RUN rm -rf /argocd-lovely-plugin

If I build the image and try to remove (rm) the "argocd-lovely-plugin" file, then I have the same problem:

Step 1/7 : FROM ghcr.io/crumbhole/argocd-lovely-plugin:0.4.1
 ---> 3256ecbe39ac
Step 2/7 : USER root
 ---> Running in cd434b201efe
Removing intermediate container cd434b201efe
 ---> c196c3018099
Step 3/7 : RUN addgroup -S app -g 1000 && adduser -S app -u 1000 -G app  && chown -R 1000:1000 /argocd-lovely-plugin
 ---> Running in c4d323e9e69c
Removing intermediate container c4d323e9e69c
 ---> 56dd65b7905e
Step 4/7 : USER 1000
 ---> Running in 8e9f994b894c
Removing intermediate container 8e9f994b894c
 ---> 114c8b9d36d9
Step 5/7 : RUN ls -l /
 ---> Running in 2866727819fe
total 14532
-rwxr-xr-x    1 app      app       14822201 Jul  5 10:44 argocd-lovely-plugin
drwxr-xr-x    2 root     root          4096 May 23 16:51 bin
drwxr-xr-x    5 root     root           320 Jul 22 23:20 dev
drwxr-xr-x    1 root     root          4096 Jul 22 23:20 etc
drwxr-xr-x    1 root     root          4096 Jul 22 23:20 home
drwxr-xr-x    7 root     root          4096 May 23 16:51 lib
drwxr-xr-x    5 root     root          4096 May 23 16:51 media
drwxr-xr-x    2 root     root          4096 May 23 16:51 mnt
drwxr-xr-x    2 root     root          4096 May 23 16:51 opt
dr-xr-xr-x  167 root     root             0 Jul 22 23:20 proc
drwx------    2 root     root          4096 May 23 16:51 root
drwxr-xr-x    2 root     root          4096 May 23 16:51 run
drwxr-xr-x    2 root     root          4096 May 23 16:51 sbin
drwxr-xr-x    2 root     root          4096 May 23 16:51 srv
dr-xr-xr-x   13 root     root             0 Jul 22 23:20 sys
drwxrwxrwt    2 root     root          4096 May 23 16:51 tmp
drwxr-xr-x    7 root     root          4096 May 23 16:51 usr
drwxr-xr-x   12 root     root          4096 May 23 16:51 var
Removing intermediate container 2866727819fe
 ---> 6f09a2a7cb8c
Step 6/7 : RUN ls -ln /argocd-lovely-plugin
 ---> Running in e17004972a4b
-rwxr-xr-x    1 1000     1000      14822201 Jul  5 10:44 /argocd-lovely-plugin
Removing intermediate container e17004972a4b
 ---> 25de8bbf2028
Step 7/7 : RUN rm -rf /argocd-lovely-plugin
 ---> Running in 8f9d8cfb7001
rm: can't remove '/argocd-lovely-plugin': Permission denied
The command '/bin/sh -c rm -rf /argocd-lovely-plugin' returned a non-zero code: 1

Adjusting the file permissions (e.g. 777) leads to the same behavior.

Do you have any idea what I'm doing wrong or is there a plan on the roadmap for a container that is "runAsNonRoot" compatible?

Using the latest stable version of argocd-lovely-plugin.

WIth a repo structure like the following: my-cluster (folder):

• chart (folder containing a Chart.yaml and values.yaml)
• d.yaml
• e.yaml
• kustomization.yaml

This works without issue.

However, if you have a repo like this:

my-cluster (folder):

• chart (folder containing a Chart.yaml and values.yaml)
• b.yaml
• e.yaml
• kustomization.yaml

It will ONLY render the b and e and it won't render the helm chart.

This PR contains the following updates:

| Package | Type | Update | Change | |---|---|---|---| | wangyoucao577/go-release-action | action | minor | v1.32 -> v1.33 |

Release Notes

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

• [ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate. View repository job log here.

Curious how you'd recommend adding additional args to kustomize such as --load-restrictor LoadRestrictionsNone? Attempting to install a chart from local, and can't get it to work unless the /chart is inside the kustomize directory. I see --helm-enabled is set here, and we're given the option to provide a path to a different kustomize binary. Would it be possible to use another plugin instead of pointing to a binary? Already have a kustomize plugin with the necessary options set. Otherwise maybe some way to use the argo-cm kustomize.buildOptions?

I'm using sed command in ARGOCD_ENV_LOVELY_PREPROCESSORS, as in one of the examples to replace contents of values.yaml.

Seems if sed returns error code due to eg. file not existing, lovely-plugin does not catch it, and happily just continues processing.

Instead, we should return error to argocd.

EDIT: seems my ENV variable name was wrong, LOVELY_PREPROCESSORS does work, however I still can't make it to find proper file. Following Application definition works, and replaces correctly:

  source:
    path: deploy/magento
    plugin:
      env:
      - name: LOVELY_PREPROCESSORS
        value: sed -i 's/<<environment>>/dev-lovely/g' values.yaml
      name: argocd-lovely-plugin

But if I try to target a directory above it, in order to include plain yaml files in another directory, I this fails:

  source:
    path: deploy
    plugin:
      env:
      - name: LOVELY_PREPROCESSORS
        value: sed -i 's/<<environment>>/dev-lovely/g' magento/values.yaml
      name: argocd-lovely-plugin

when using kustomize_patch as per below, anything attached to $ disappears from the render, there doesnt appear to be an escape key either to stop this from happening.

plugin:
  name: argocd-lovely-plugin
  env:
    - name: LOVELY_KUSTOMIZE_PATCH
      value: |-
        - op: replace
          path: /patches/0/patch
          value: |-
            - op: add
              path: /data/agent3.yaml
              value: $value

So in the above example the entire "$value" will disappear and leave it empty.

My use case is patching in configs for an prometheus that includes scraping configs that require variables such as "$1:$2" which are dropped and rendered as ":"

PR to add api versions and cluster versions to the helm template command there both available in the build environment variables

KUBE_VERSION = the version of kubernetes cluster KUBE_API_VERSIONS = the version of kubernetes APIs (csv formated string)

https://argo-cd.readthedocs.io/en/stable/user-guide/build-environment/

tested it in argocd and this works , i'm getting the correct cluster version and created a configmap with all api versions issue: https://github.com/crumbhole/argocd-lovely-plugin/issues/57

apiVersion: v1
kind: ConfigMap
metadata:
  name: lovely-test
  namespace: lovely-test
data:
  apiVersions.txt: |
    {{ .Capabilities.APIVersions }}

Because both charts are rendered with the same name (ARGOCD_APP_NAME), there are issues in most cases.

Provide a way to override this on a per chart basis. Can we do something automatically perhaps, like postpend the directory name?

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

⚠ Dependency Lookup Warnings ⚠

• Renovate failed to look up the following dependencies: nonexistent.

Files affected: test_errors/nonexistent_chart/Chart.yaml

This repository currently has no open or pending branches.

Detected dependencies

• [ ] Check this box to trigger a request for Renovate to run again on this repository

Context

I want to feed Helm with decrypted secrets, ideally without storing them to disk. My secrets are stored encrypted in the Git repository with SOPS. As a plain shell command it would look like this: sops --decrypt secrets.enc.yaml | helm template $name . -f -.

This would automatically pick up the values.yaml file in the directory but it would also pass the decrypted values in secrets.enc.yaml via stdin to helm, effectively merging the values together. Obviously the SOPS binary, configuration and keys would need to be in-place but that is not a concern for the plugin.

The problem

It seems that I cannot specify additional values files on disk for the Helm processor, let alone pass something to Helm via stdin. I need something to happen before the Helm command kicks off that generates values, which are then fed via stdin to Helm.

Options

I've looked at the options at my disposal.

ARGOCD_ENV_LOVELY_PREPROCESSORS

As far as I can see, this can only modify files on disk for further processing. My use-case is to not decrypt the secrets to disk. So the idea of a prepocessor is what I'm looking for, but it needs to be able to 'feed' the Helm command via stdin.

ARGOCD_ENV_LOVELY_HELM_MERGE

I do not know upfront what the contents of my secrets will be. Also, I'd rather not put it in ENV variables for additional security.

Plugins

Plugins seem to run after Helm/Kustomize which makes them useless for my use-case. All the magic is happening within the Helm chart. I don't want to patch/correct it afterwards. I don't want to dig into the Helm chart and see how they use the secret values to implement them on my own later in the 'pipeline'.

Since plugins implement the idea of Linux pipe, this is exactly what I need, only I need it to run before Helm kicks off. Passing the output of the previous plugins to Helm.

Next steps

Maybe I've overlooked/missed options that can work for my use case. Otherwise I'd be happy to collaborate on a design and help implement the code (I'm proficient in Go) if the added value is sufficient. I understand that we should probably design for the generic case, SOPS is just my implementation but others should be free to use whatever they want.

Dear all, I am working in MonoRepo<=>Multi-k8s-clusters environment. Here is my inventory repository structure my GitlabCI pipeline is browsing to build deployment manifests to be scrapped by Argo App.

I had in mind to move the process of my GitlabCI pipeline into Lovely plugin. Here are the main caveats I do experience

Vault interop

Vault Replacer plugin is configured as a plugin to lovely by the means of env variable ARGOCD_ENV_LOVELY_PLUGINS. As a result, Vault Replacer is gonna run in preprocessing step in order to resolve secret in these cases:

Deploy a helm chart in accordance with its values. One of the values will be taken from Hashicorp Vault.
Deploy a separate kubernetes secret, with the value being taken from Hashicorp Vault.
Deploy a kubernetes configmap using Kustomize. Some of the data within the configmap will be taken from Hashicorp Vault.

Vault Replacer does only support Kubernetes Auth method. This method is not supported by my central Vault server. As a workaround, I successfully interop lovely plugin with ArgoCD Vault plugin with approle authentication. ArgoCD Vault plugin takes the PATH of the yaml files to resolve and sends the result as the aggregate standard output i.e. we should iterate each yaml file to keep the directory tree like Vault Replacer which performs this process in the box. Vault plugin cannot do it out of the box along preprocessing step by the means of the basic ArgoCD configManagementPlugins syntax.

As a consequence, I trigger Vault Plugin once Lovely Plugin is processed. Hence, we support only here above use cases #2 and #3.

Overlays support

As detailed in ArgoCD Lovely plugin help page, overlays mechanisms are not supported:

• neither from an Helm value file perspective : --values (or -f) to specify a YAML file with overrides. This can be specified multiple times and the rightmost file will take precedence,
• nor from a Kustomize perspective.

However, application sets should be investigated furthermore to mitigate/tackle this caveat.

Environment variables

ArgoCD Lovely plugin does not support environnement variables. Helm value file or manifest file must be fully resolved prior to be processed. Also ArgoCD Lovely plugin does not enhance Kustomize processing which does build the manifests from files exclusively, and no information would come from runtime. In essence, no information can be loaded from the command-line arguments or environment variables during the manifest build phase.

This caveat could however be solved by the means of a preprocessor plugin which would browse the working application directory and envsubst the yaml files.

Thanks & Best Regards. Richard