Support for jsonnet-bundler & jsonnet flags (like -J to include library paths)

[ghost]

Summary

This is a request to support jsonnet-bundler and jsonnet flags like -J which adds libraries to the "paths" for where import looks for files.

Motivation

My jsonnet files have external library dependencies that I don't want to check into my git repo. I use jsonnet-bundler in order to pull down those dependencies locally before calling jsonnet with-J vendor to automatically look for relevant libraries within the vendor directory.

In order to use ArgoCD I would need the same functionality.

Proposal

In an abstract way, it might be nice to support some sort of custom "post-clone"/"pre-sync" job/command.

Such that it might look like:

git clone...
<something here to generate files>
sync...

[gaurav517]

Did you find a workaround for this @wmcnamee-tunein ? We have a similar issue where our base jsonnet libraries are in different repo (shared by many other repos).
One idea is to keep all app manifest files in one repo only.. but we don't prefer that.

Also I got confused by prefixed by repoRoot in --jsonnet-libs stringArray Additional jsonnet libs (prefixed by repoRoot). Which repoRoot? library-repo-root? or app-repo-root?
Thanks.

[jessebye]

@wmcnamee-tunein @gaurav517 I have this working using a plugin. In addition to the plugin I had to add jb to a custom docker image for argo.

In our case, we're using jb and tanka, and got it to work like this:

Dockerfile:

FROM argoproj/argocd:v1.7.6

USER root
ADD https://github.com/jsonnet-bundler/jsonnet-bundler/releases/download/v0.4.0/jb-linux-amd64 /usr/bin/jb
ADD https://github.com/grafana/tanka/releases/download/v0.12.0/tk-linux-amd64 /usr/bin/tk
RUN chmod +x /usr/bin/jb /usr/bin/tk

USER argocd

Argo config:

    configManagementPlugins: |
      - name: tanka
        init:
          command: ["/bin/sh", "-c"]
          args: ["jb update"]
        generate:
          command: ["/bin/sh", "-c"]
          args: ['tk show environments/"$ENVIRONMENT" --dangerous-allow-redirect']

Then you can create an Argo app like this:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: test
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: infrastructure
  source:
    repoURL: git@github.com:<org>/<repo>.git
    targetRevision: dev
    path: test
    plugin:
      name: tanka
      env:
        - name: ENVIRONMENT
          value: default
  destination:
    server: https://kubernetes.default.svc
    namespace: default

I also got this working for private git repos by using HTTPS instead of SSH to authenticate and providing a PAT that had permission to reach both the GitOps repo as well as our jsonnet library repo.

[ghostsquad]

where does ENVIRONMENT var get set from?

[jessebye]

@ghostsquad it's set in the Argo Application (I gave a full example in my previous comment):

...
spec:
  source:
    plugin:
      name: tanka
      env:
        - name: ENVIRONMENT
          value: default

[ghostsquad]

@jessebye thanks, ya I totally missed that! :)

[ghostsquad]

any idea why --dangerous-allow-redirect exists?

[jessebye]

@ghostsquad
"Redirection of the output of tk show is discouraged and disabled by default. Run tk show --dangerous-allow-redirect to enable."

The idea is that tanka users should use its built-in kubernetes context management, and using tk show bypasses that. Piping the output (as Argo CD does when it runs a generate) is disabled and you have to pass the --dangerous-allow-redirect flag to enable output. This is fine since Argo is handling the kubernetes context anyway.

See also grafana/tanka#3

[ghostsquad]

thank you. This makes sense.

[Geethree]

@wmcnamee-tunein @gaurav517 I have this working using a plugin. In addition to the plugin I had to add jb to a custom docker image for argo.

In our case, we're using jb and tanka, and got it to work like this:

Dockerfile:

FROM argoproj/argocd:v1.7.6

USER root
ADD https://github.com/jsonnet-bundler/jsonnet-bundler/releases/download/v0.4.0/jb-linux-amd64 /usr/bin/jb
ADD https://github.com/grafana/tanka/releases/download/v0.12.0/tk-linux-amd64 /usr/bin/tk
RUN chmod +x /usr/bin/jb /usr/bin/tk

USER argocd

Argo config:

    configManagementPlugins: |
      - name: tanka
        init:
          command: ["/bin/sh", "-c"]
          args: ["jb update"]
        generate:
          command: ["/bin/sh", "-c"]
          args: ['tk show environments/"$ENVIRONMENT" --dangerous-allow-redirect']

Then you can create an Argo app like this:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: test
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: infrastructure
  source:
    repoURL: git@github.com:<org>/<repo>.git
    targetRevision: dev
    path: test
    plugin:
      name: tanka
      env:
        - name: ENVIRONMENT
          value: default
  destination:
    server: https://kubernetes.default.svc
    namespace: default

I also got this working for private git repos by using HTTPS instead of SSH to authenticate and providing a PAT that had permission to reach both the GitOps repo as well as our jsonnet library repo.

FWIW: Since @deleted and I had a simple app without pulling in other jsonnet libraries - i.e. no jsonnet lock file. The jb update was failing with

geethree@footop:~/blah/tanka-hello-world$ ../jb update
jb: error: failed to load lockfile: open /home/blah/jsonnetfile.lock.json: no such file or directory

So we just return the appropriate exit code in jb update - i.e.

    - name: tanka
      init:
        command: ["/bin/sh", "-c"]
        args: ["jb update || true"]
      generate:
        command: ["/bin/sh", "-c"]
        args: ['tk show environments/"$ENVIRONMENT" --dangerous-allow-redirect']

[moustafab]

Argo config:

    configManagementPlugins: |
      - name: tanka
        init:
          command: ["/bin/sh", "-c"]
          args: ["jb install"]
        generate:
          command: ["/bin/sh", "-c"]
          args: ['tk show environments/"$ENVIRONMENT" --dangerous-allow-redirect']

FWIW, jb update will update your dependencies, so to use the pinned versions from your lock file you should probably use jb install when setting up the repo

[pmorch]

@jessebye writes:

I also got this working for private git repos by using HTTPS instead of SSH to authenticate and providing a PAT that had permission to reach both the GitOps repo as well as our jsonnet library repo

One thing with jsonnet-bundler/jb that tends to get overlooked is when a dependency inside jsonnetfile.json refers to a private git repo. Then a simple jb update is not going to suffice.

Is that one of the situations you got working? How?

If PAT is a "personal access token", then one way I've got it working with bash for HTTPS tokens is:

mkdir /tmp/home
set +H # to avoid exclamation point triggering history expansion...
HOME=/tmp/home git config --global credential.helper "!f() { echo \"username=gitlab-ci-token\\npassword=${GITLAB_TOKEN}\"; }; f"
HOME=/tmp/home jb update
rm -rf /tmp/home

My vote would be that if jsonnet-bundler should be supported, it needs to support both SSH and HTTPS credentials for dependencies stored as secrets somehow elegantly too.