jenkins-x-plugins / jx-gitops Goto Github PK

The module path github.com/h2non/gock found in your /go.mod doesn't match the actual path gopkg.in/h2non/gock.v1 found in the dependency's go.mod.

Updating the module path in your go.mod to gopkg.in/h2non/gock.v1 should resolve this issue.

View the update logs.

Dependabot can't resolve your Go dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

go: github.com/jenkins-x/[email protected]: reading github.com/jenkins-x/jx-apps/go.mod at revision v0.0.1: unknown revision v0.0.1

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

The module path github.com/h2non/gock found in your go.mod doesn't match the actual path gopkg.in/h2non/gock.v1 found in the dependency's go.mod.

Updating the module path in your go.mod to gopkg.in/h2non/gock.v1 should resolve this issue.

View the update logs.

Dependabot can't resolve your Go dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

vbom.ml/[email protected]: unrecognized import path "vbom.ml/util" (parse https://vbom.ml/util?go-get=1: no go-import meta tags ())

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

The module path github.com/h2non/gock found in your go.mod doesn't match the actual path gopkg.in/h2non/gock.v1 found in the dependency's go.mod.

Updating the module path in your go.mod to gopkg.in/h2non/gock.v1 should resolve this issue.

View the update logs.

Overriding helm values for applications installed with Jenkins X is getting confusing. There are lots of places where helm values exists, taking tekton for example you can configure values in the main chart

https://github.com/jenkins-x-charts/tekton/blob/master/tekton/values.yaml

or look for the right version stream configured for your cluster and check the chart template values

https://github.com/jenkins-x/jxr-versions/blob/master/charts/jenkins-x/tekton/template-values.yaml

or the app template values

https://github.com/jenkins-x/jxr-versions/blob/master/apps/jenkins-x/tekton/values.yaml.gotmpl

and also possibly the boot config repo where we would recommend folks override values

i.e. apps/tekton/values.yaml

or to be able to use jxRequirements.yaml as parameters we can also use a gotmpl file

apps/tekton/values.yaml.gotmpl

Note this is different to a Helmfile gotmpl file as only jxRequirements are supported template options.

https://github.com/roboll/helmfile#templating which again could cause confusion.

Its kinda hard to grok whats needed and which way we should go. Right now we are working on a different boot config repos, one for Vault another for GSM, we are changing each of them a bit to tailor them for their specific needs, we need to somehow sync or share changes between boot config repos.

Folks will likely be overwhelmed by all the options and find it hard to navigate around the repos. It would be good to see if we can find a way to cut down on all the values override options so that it's easier for users to grok and simpler examples to follow, hopefully having a single place where people can look?

The module path github.com/h2non/gock found in your go.mod doesn't match the actual path gopkg.in/h2non/gock.v1 found in the dependency's go.mod.

Updating the module path in your go.mod to gopkg.in/h2non/gock.v1 should resolve this issue.

View the update logs.

The module path github.com/h2non/gock found in your go.mod doesn't match the actual path gopkg.in/h2non/gock.v1 found in the dependency's go.mod.

Updating the module path in your go.mod to gopkg.in/h2non/gock.v1 should resolve this issue.

View the update logs.

this relates to #32 and #35

it would be nice if all the configuration, versions, values files & templates were stored in the single git repository rather than be spread around (eg in the version stream)

It would be nice to have a command (say) jx gitops apps resolve to resolve the version stream stuff up front...

• add any missing version numbers from the version stream (or have an upgrade mode to upgrade them if they are different in the version stream)
• copy any values.yaml(.gotmpl) files from the version stream if missing (using kpt to keep them in sync
• add the values.yaml(.gotmpl) files into the jx-apps.yml file so it’s explicit what files will be passed into helm template

Eg if you start with a jx-apps.yml file like this in a mostly empty repository...

apps:
- name: jenkins-x/tekton
- name: jenkins-x/jxboot-helmfile-resources
- name: bitnami/external-dns
  namespace: foo

and ran jx gitops apps resolve it'd modify the file to something like:

apps:
- name: jenkins-x/tekton
  version: 1.2.3
  values:
  - helm-values/jenkins-x/tekton/values.yaml.gotmpl
- name: jenkins-x/jxboot-helmfile-resources
  values:
  - helm-values/jenkins-x/jxboot-helmfile-resources/values.yaml.gotmpl
  version: 4.5.6
- name: bitnami/external-dns
  namespace: foo
  version: 2.3.4

and it would create those values files on the local filesystem - grabbing them from the version stream - e.g. for helm-values/jenkins-x/tekton/values.yaml.gotmpl.

We're using a folder per chart to contain the values.yaml / values.yaml.gotmpl files so that we can easily use kpt to create the directory + grab the values files from the associated version stream folder.

then after the resolve has been done everything is local, declarative and clear & there’s no magic. Its obvious from the jx-apps.yml file all the values files/templates that will be used; what versions will be used etc

This would then simplify the jx gitops apps template command since it literally just iterates through the file and doing helm template with the given values files etc (evaluating any go templates before passing them into helm)

so make it easier to understand what apps are in what namespace & to more easily configure namespace specific values (ingress / image pull secrets etc) we should probably move to a helmfile per namespace for staging / production / secrets-infra etc. Then each helmfile can reference its own namespace specific environment yaml for ingress domains etc

e.g. a cluster repository could have a layout like this:

helmfiles/
  namespaces/
    jx/
      helmfile.yaml
    jx-staging/
      helmfile.yaml

then its just usually 1 helmfile to look at in a specific namespace to see whats in staging or whatever.

If needed folks could add an OWNERS file in a particular namespace to have team specific review/approvers for different namespaces.

We could also support composite apps being deployed to a namespace by allowing a custom app helmfile to be deployed. e.g. my-system.helmfile.yaml could contain N charts of different versions and be deployed into helmfiles/namespaces/jx-staging/my-system.helmfile.yaml via jx promote?

The module path github.com/h2non/gock found in your /go.mod doesn't match the actual path gopkg.in/h2non/gock.v1 found in the dependency's go.mod.

Updating the module path in your go.mod to gopkg.in/h2non/gock.v1 should resolve this issue.

View the update logs.

similar to #278 it would be nice to create a step to process all the sources in config-root to find all the image tags in every Deployment / Pod etc and create a YAML file with all the images (and which resources they are referenced from)

this would help folks grok what images are needed; what registries are used, what versions are used etc

folks could use this data to then make further tools such as:

• ensuring all images are accessible
• mirroring / replicating images to other registries to support air gapped on premise type repositories or to work around locations which cannot access specific registries. e.g. in China its often hard to access gcr.io

right now each namespace shares the same jx-values.yaml file to default the jxRequirements.ingress.* values meaning staging and production use the same ingress hosts.

We should create a namespace specific jx-values.yaml file and pass that into each namespace when running jx gitops helmfile template so that we get unique host names for similar services in different namespaces

Dependabot can't resolve your Go dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

code.gitea.io/sdk/[email protected]: reading code.gitea.io/sdk/gitea/gitea/go.mod at revision gitea/v0.13.0: unknown revision gitea/v0.13.0

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

to avoid kpt pkg update failing later on.

we should be able to use the gitclient.HasChanges(gitClient, dir) function: https://github.com/jenkins-x/jx-helpers/blob/master/pkg/gitclient/helpers.go#L224 to check if there are local changes

The module path github.com/h2non/gock found in your /go.mod doesn't match the actual path gopkg.in/h2non/gock.v1 found in the dependency's go.mod.

Updating the module path in your go.mod to gopkg.in/h2non/gock.v1 should resolve this issue.

View the update logs.

The module path github.com/h2non/gock found in your /go.mod doesn't match the actual path gopkg.in/h2non/gock.v1 found in the dependency's go.mod.

Updating the module path in your go.mod to gopkg.in/h2non/gock.v1 should resolve this issue.

View the update logs.

Right now the CRDs are inside chart folders in namespace folders - it would be better to move them to a separate directory tree. This will make it easier to kubectl apply all the CRDs up front before creating instances on initial installs to avoid errors

Eg move CRD files from config-root/namespaces/vault-infra/extsec/foo-crd.yaml => config-root/cluster/crds/vault-infra/extsec/foo-crd.yaml

we should add CLI arguments to allow the registry prefix on image strings to be modified for Deployments / Jobs.

Eg

jx gitops image —from-registry gcr.io —to-registry my-registry-host

would then replace any files in content-root/**.yaml which have a container image like gcr.io/myorg/myimage => my-registry-host/myorg/myimage

also it would be nice to be able to add a —arch arm64 argument to modify the image to reference the arm64 architecture

Dependabot can't resolve your Go dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

vbom.ml/[email protected]: unrecognized import path "vbom.ml/util" (https fetch: Get https://vbom.ml/util?go-get=1: EOF)

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

right now there's way too much magic in the jx gitops jx-apps template command around:

• templating/finding values.yaml / values.yaml.gotmpl files
• finding helm charts
• running helm template and copying the files into git

Folks shouldn't have to learn lots of CLI tools or magic - it'd be nice to make things more self-evident.

e.g. we already have a simple git repostory layout.

I wonder if we should try decouple the step in this command so there's an easier to grok intermediate format?

e.g.

• template the yaml files + fetch the charts and output the results somewhere. e.g. something like...

./build/
  helm/
    charts/
      myprefix/
        mychart/
          Chart.yaml
          values.yaml
          templates/
              deployment.yaml
        ...
          # generated/copied values.yaml files to be applied
          overrides/
             values.yaml
             another-values.yaml
          # shell script which runs `helm template --values overrides/values.yaml --values/another-values.yaml releasename myprefix/mychart
          # then copies the values to a canonical place...
          helm-template.sh

     # top level script which invokes all the ./charts/myprefix/mychart/helm-template.sh scripts
     helm-template.sh

Then if someone wanted to tinker with a specific chart they could do something like...

cd build/helm/charts/myprefix/mychart

## todo edit overrides/values.yaml by hand...

./helm-template.sh

everything is then self-documenting; you can see all the values files passed into the template myprefix/mychart by looking in the files at build/helm/charts/myprefix/mychart/overrides/*.yaml or looking at the command line at build/helm/charts/myprefix/mychart/helm-template.sh

so that we can run a command if there are any un committed git changes. Then we can do something like this in the Makefile:

commit:
	git add $(OUTPUT_DIR) src *.yml
	jx gitops condition --uncommitted -- git commit -m "chore: regenerated"

instead of the current workaround:

commit:
	git add $(OUTPUT_DIR) src *.yml
	# lets ignore commit errors in case there's no changes and to stop pipelines failing
	-git commit -m "chore: regenerated"

The module path github.com/h2non/gock found in your /go.mod doesn't match the actual path gopkg.in/h2non/gock.v1 found in the dependency's go.mod.

Updating the module path in your go.mod to gopkg.in/h2non/gock.v1 should resolve this issue.

View the update logs.

The module path github.com/h2non/gock found in your go.mod doesn't match the actual path gopkg.in/h2non/gock.v1 found in the dependency's go.mod.

Updating the module path in your go.mod to gopkg.in/h2non/gock.v1 should resolve this issue.

View the update logs.

The module path github.com/h2non/gock found in your /go.mod doesn't match the actual path gopkg.in/h2non/gock.v1 found in the dependency's go.mod.

Updating the module path in your go.mod to gopkg.in/h2non/gock.v1 should resolve this issue.

View the update logs.

if folks know they don't have any local changes it'd be nice if they could do... jx gitops upgrade --strategy force-delete-replace so that they don't get any kind of merge conflicts

Dependabot can't resolve your Go dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

vbom.ml/[email protected]: unrecognized import path "vbom.ml/util" (https fetch: Get https://vbom.ml/util?go-get=1: EOF)

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

Dependabot can't resolve your Go dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

gomodules.xyz/jsonpatch/[email protected]: unrecognized import path "gomodules.xyz/jsonpatch/v2" (parse https://gomodules.xyz/jsonpatch/v2?go-get=1: no go-import meta tags ())

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

The module path github.com/h2non/gock found in your go.mod doesn't match the actual path gopkg.in/h2non/gock.v1 found in the dependency's go.mod.

Updating the module path in your go.mod to gopkg.in/h2non/gock.v1 should resolve this issue.

View the update logs.

The module path github.com/h2non/gock found in your go.mod doesn't match the actual path gopkg.in/h2non/gock.v1 found in the dependency's go.mod.

Updating the module path in your go.mod to gopkg.in/h2non/gock.v1 should resolve this issue.

View the update logs.

The module path github.com/h2non/gock found in your /go.mod doesn't match the actual path gopkg.in/h2non/gock.v1 found in the dependency's go.mod.

Updating the module path in your go.mod to gopkg.in/h2non/gock.v1 should resolve this issue.

View the update logs.

sometimes folks can't see a chart repository as its down. It would be nice to be able to exclude a chart repository, by prefix, from the upgrade command.

e.g.

jx gitops upgrade --ignore bitnami

which would then ignore the charts in that prefix in the helmfile.yaml when performing the upgrade

The module path github.com/h2non/gock found in your go.mod doesn't match the actual path gopkg.in/h2non/gock.v1 found in the dependency's go.mod.

Updating the module path in your go.mod to gopkg.in/h2non/gock.v1 should resolve this issue.

View the update logs.

Dependabot can't resolve your Go dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

vbom.ml/[email protected]: unrecognized import path "vbom.ml/util" (https fetch: Get https://vbom.ml/util?go-get=1: EOF)

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

The module path github.com/h2non/gock found in your go.mod doesn't match the actual path gopkg.in/h2non/gock.v1 found in the dependency's go.mod.

Updating the module path in your go.mod to gopkg.in/h2non/gock.v1 should resolve this issue.

View the update logs.

Hi guys,

it seems that cluster-repo is missing OWNERS file, so accepting PR isn't working as expected (I cannot approve PR that was created by me with my-jx-bot)

Or is OWNERS file missing be design?

Dependabot can't resolve your Go dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

go: github.com/jenkins-x/[email protected]: reading github.com/jenkins-x/jx-apps/go.mod at revision v0.0.1: unknown revision v0.0.1

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

we currently have been using helm templating to inject GKE project ID / AWS account ID data into charts to enable IAM roles on kubernetes service accounts like this...
https://github.com/jenkins-x/jxr-versions/blob/ea2a49ac197c0763b7d01166b15e259e111ee33c/charts/jenkins-x/tekton/values.yaml.gotmpl#L18

its maybe more secure to have terraform generate the annotations we need on ServiceAccounts into a Secret which we can then read to enrich the service accounts without having to check the account ID / annotations into git.

e.g. maybe Terraform could generate a Secret in the default namespace called something like jx-service-acount-annotations

which can contain the annotations to add to the ServiceAccounts something like....

apiVersion: v1
kind: Secret
metadata:
  name: jx-service-account-annotations
  namespace: default
data:
  tekton-bot: |-
     eks.amazonaws.com/role-arn: arn:aws:iam::$accountID:role/$clusterName-$namespace-tekton-bot
  controllerbuild: |-
     eks.amazonaws.com/role-arn: arn:aws:iam::$accountID:role/$clusterName-$namespace-controllerbuild

then we can have a step in the boot pipeline to detect this Secret and apply any additional annotations to the ServiceAcount resources before they get applied?

This would simplify the need for conditional helm values file templating in the version stream / charts too

Hi,

version: 0.0.380

The output of jx gitops pr get is going to stderr. Shouldn't it be to stdout?

A secret-mapping.yaml file can contain invalid elements, we should validate against the schema when loading https://github.com/jenkins-x/jx-gitops/blob/c5c74644d2d493f5947fb98f5d6427f1190b14eb/pkg/secretmapping/helpers.go#L53

if you create a promotion PR (e.g. adding a new chart to jx-apps.yml or changing a version) - the PR pipeline should run make pr and regenerate the YAML and push the commits to the PR branch so that folks can review the changes to the actual k8s resources

Dependabot can't resolve your Go dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

The module path github.com/h2non/gock found in your go.mod doesn't match the actual path gopkg.in/h2non/gock.v1 found in the dependency's go.mod.

Updating the module path in your go.mod to gopkg.in/h2non/gock.v1 should resolve this issue.

View the update logs.

which works like jx-gitops helm template and generates a similar directory tree (reusing the same split + ExternalSecrets logic) - using a folder per namespace in the output. e.g. so the output looks something like this...

$ jx-gitops helmfile template --dir config-root

config-root/
  namespaces/
    nginx/
       nginx-ingress/
          deployment.yaml
          ...
     jx/
        tekton/
          deployment.yaml
          ...
        lighthouse/
          deployment.yaml
          ...

so that if you want to create your own local schedulers they don't suffer merge issues with kpt when upgrading clusters

The module path github.com/h2non/gock found in your /go.mod doesn't match the actual path gopkg.in/h2non/gock.v1 found in the dependency's go.mod.

Updating the module path in your go.mod to gopkg.in/h2non/gock.v1 should resolve this issue.

View the update logs.

The module path github.com/h2non/gock found in your go.mod doesn't match the actual path gopkg.in/h2non/gock.v1 found in the dependency's go.mod.

Updating the module path in your go.mod to gopkg.in/h2non/gock.v1 should resolve this issue.

View the update logs.

We should add some better error handling around jx gitops upgrade to improve the UX, if it gets run twice then an error is given but that may not be an issue if we are on the latest.

Also we should probably check at the start of the command that the git branch is clean with no local changes etc too.

The module path github.com/h2non/gock found in your go.mod doesn't match the actual path gopkg.in/h2non/gock.v1 found in the dependency's go.mod.

Updating the module path in your go.mod to gopkg.in/h2non/gock.v1 should resolve this issue.

View the update logs.

Right now Vault is assumed the default backend, this should be configurable, let's allow GSM so we can host JX3 own dogfooding infra with it integrated.