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

Dependabot can't resolve your Go dependency files.

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

The error Dependabot encountered was:

gonum.org/v1/[email protected]: unrecognized import path "gonum.org/v1/gonum": parse https://gonum.org/v1/gonum?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.

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.

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.

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.

now that v3 supports multiple namespaces per cluster, we should have more sophisticated support for promoting apps to different clusters & namespaces.

e.g. for a given app cheese we may want to deploy that to the my-cheese namespace in clusters staging, prod-1 and prod-2 but in prod-3 we want to use a different namespace.

We don't want to have to encode every possible cluster's namespace use in every app's repository. e.g. the cheese git repository does not need to concern itself with what namespaces prod-1 and prod-2 want to use - let those git repositories and teams configure that.

So how about we modify the jx promote logic to:

• allow jx-promote to pass in an --default-app-namespace which is the default namespace used when promoting to remote clusters for the first time only. e.g. in the above example we'd use jx promote --app cheese --default-app-namespace my-cheese ... in the cheese release pipeline

• when promoting to local environments we'd use the local environments namespace configured in the jx-requirements.yml file for the dev cluster

• when promoting to remote clusters we'd use whatever namespace(s) the app is deployed in by looking at the remote clusters helmfile.yaml file in its git repository.

• if the app has been deployed in the remote cluster then use whatever namespace(s) are defined in the remote cluster's helmfile.yaml

• if the app has not been deployed to this cluster before, default to use the --default-app-namespace value for the namespace. If the --default-app-namespace value is empty, default to the cluster.namespace value from the remote clusters jx-requirements.yml file.

Then by default cheese would promote to my-cheese in all remote clusters; unless someone modifies the helmfile.yaml file in a remote cluster to use a different namespace (or different namespaces).

a promote PR can get merge conflicts (e.g. production if using a single cluster for staging + production)

it would be awesome to be able to auto-rebase any promotion PRs if they get rebase/merge conflicts

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 first environment only gets an env/ label. But additional environments also have do-not-merge/hold which essentially makes them non-auto even though their promotionStrategy is Auto

env specs:

apiVersion: jenkins.io/v1
kind: Environment
  labels:
    env: staging
    gitops.jenkins-x.io/pipeline: namespaces
    team: jx
  name: staging
  namespace: jx
spec:
  kind: Permanent
  label: Staging
  namespace: jx-staging
  order: 100
  promotionStrategy: Auto

apiVersion: jenkins.io/v1
kind: Environment
  labels:
    env: qat1
    gitops.jenkins-x.io/pipeline: namespaces
    team: jx
  name: qat1
  namespace: jx
spec:
  kind: Permanent
  label: Qat1
  namespace: jx-qat1
  order: 500
  promotionStrategy: Auto
  remoteCluster: true
  source:
    ref: master
    url: https://github.com/org/env-org-qat1.git

apiVersion: jenkins.io/v1
kind: Environment
  labels:
    env: qat2
    gitops.jenkins-x.io/pipeline: namespaces
    team: jx
  name: qat2
  namespace: jx
spec:
  kind: Permanent
  label: Qat2
  namespace: jx-qat2
  order: 500
  promotionStrategy: Auto
  remoteCluster: true
  source:
    ref: master
    url: https://github.com/org/env-org-qat2.git

The PR on qat1 & qat2 has labels like:

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 http://vbom.ml/util/?go-get=1: redirected from secure URL https://vbom.ml/util?go-get=1 to insecure URL http://vbom.ml/util/?go-get=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.

Dependabot can't resolve your Go dependency files.

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

The error Dependabot encountered was:

Cannot detect VCS for code.cloudfoundry.org/gofileutils. Attempted to detect VCS because the version looks like a git revision: v0.0.0-20170111115228-4d0c80011a0f

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:

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:

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.

This is something that jx-promote used to do. It was added in #216.

I am yet to track down when/how this was lost. But the newer versions don't seem to do that

With jenkins-x v1 we really enjoyed being able to take the requirements.yaml and update the values from staging in one file in an understandable PR for our product team and BA's to review.

Understandably this has changed and is more difficult to do. But promoting services one at a time takes a long time and if you have dependencies it could break them.

We think it would be nice to have the ability to update multiple services at once into production with a batch process.

Something like

user@machine: jx promote --batch-mode
Services to promote (Use space to select and enter to proceed)
[] Product-Service
[x] Payment-Service
[x] User-Service
[] Time-Service

2 services selected

Promoting....

(Side note: We've discussed within our team and think we will be able to dedicate some time to this. We just wanted to start discussion and work out how you guys would like it done/if it's something you'd like to do.)

The environment spec looks like:

spec:
  kind: Permanent
  label: Qat1
  namespace: jx-qat1
  order: 500
  promotionStrategy: Auto
  remoteCluster: true
  source:
    ref: master
    url: https://github.com/org/env-org-qat1.git

But promotion PR to env-org-qat1 always uses the namespace jx

- chart: dev/jx3-node-demo-app
  version: 1.0.6
  name: jx3-node-demo-app
  namespace: jx

I am trying to run jx promote command I am getting error: failed to lazy load the EnvironmentContext: no dev environment in namespace foo.

Do a need unique environments for each namespace I am deploying applications to? Do I need to edit jx requirements to add a different namespace, or the .jx/gitops/source-config.yaml file?

Some examples or more info is appreciated. I read through the documentation for jx promote, and I am confused a bit by the helmfile examples as well, and I am wondering if using a helmfile or other configuration would help.

I am running

jx promote -e dev -n apps --timeout 1h --no-poll --interactive -a jx-python-demo -v 0.0.2

My environments (which I think I need to change)

$ k get environments.jenkins.io
NAME         NAMESPACE       KIND          PROMOTION   ORDER   GIT URL                                          GIT BRANCH
demo         jx-demo         Permanent     Manual      500     https://gitlab.com/foo/foo-demo.git    master
dev          jx              Development   Never               https://gitlab.com/foo/foo-dev.git     master
production   jx-production   Permanent     Manual      500     https://gitlab.com/foo/foo-prod.git    master
staging      jx-staging      Permanent     Manual      100     https://gitlab.com/foo/foo.git   master

Can I run different environments off of the same repo? Also dev, demo, stage and production are on different clusters.

Hi,

Is there an option to promote to a remote cluster on a specific namespace?
Currently the --namespace argument is used to search for the specified environment and not used to change destination namespace like help says:

I have tried promoting an application to 3 envs:

• staging
• qat1
• qat2

The lables applied on each environment:

• staging: env/staging
• qat1: env/qat1
• qat2: env/qat2

When trying jx promote inside a project repository, the command fails with the following error:

➜ jx promote
? Are you sure you want to promote the application named: quickstart-node-http? Yes
about to run: git clone https://<old-github-bot-username>:<old-token>@github.com/<my-org>/jx3-azure-terraform.git /var/folders/m4/ytp3wjnn1hlbrxt27d64jc3c0000gn/T/jx-git-440220957 in dir /var/folders/m4/ytp3wjnn1hlbrxt27d64jc3c0000gn/T
Cloning into '/var/folders/m4/ytp3wjnn1hlbrxt27d64jc3c0000gn/T/jx-git-440220957'...
remote: Repository not found.
fatal: repository 'https://github.com/<my-org>/jx3-azure-terraform.git/' not found
error: failed to lazy load the EnvironmentContext: failed to clone URL https://<old-github-bot-username>:<old-token>@github.com/<my-org>/jx3-azure-terraform.git: failed to clone repository https://<old-github-bot-username>:<old-token>@github.com/<my-org>/jx3-azure-terraform.git to directory: /var/folders/m4/ytp3wjnn1hlbrxt27d64jc3c0000gn/T/jx-git-440220957: failed to run 'git clone https://<old-github-bot-username>:<old-token>@github.com/<my-org>/jx3-azure-terraform.git /var/folders/m4/ytp3wjnn1hlbrxt27d64jc3c0000gn/T/jx-git-440220957' command in directory '/var/folders/m4/ytp3wjnn1hlbrxt27d64jc3c0000gn/T', output: 'Cloning into '/var/folders/m4/ytp3wjnn1hlbrxt27d64jc3c0000gn/T/jx-git-440220957'...
remote: Repository not found.
fatal: repository 'https://github.com/<my-org>/jx3-azure-terraform.git/' not found'

The command is using the github username and token of a previously used bot for jx2, whereas I used a new github bot for the new jx3 installation I've made, and where the current project is integrated.

The old bot doesn't have acces to the jx3 repository, nor this project repository.

It should use the new github username and token I've specified with jx admin operator
 

jx version : 3.0.338

jx upgrade plugins :

checking binary jx plugin project version 0.0.99 is installed

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.

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.

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.

Dependabot can't resolve your Go dependency files.

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

The error Dependabot encountered was:

go: helm.sh/helm/[email protected] requires
	github.com/deislabs/[email protected] requires
	github.com/docker/[email protected]: invalid version: unknown revision

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:

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.

folks can get x509: certificate signed by unknown authority' errors when using a chartmuseum over https.

a workaround is to always use the k8s service name over http instead of https.

so we should add a configuration so we can ignore the ingress for chart museum

it looks like jx promote is ignoring the env.spec.namespace setting and assuming the jx-$envName namespace

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.

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.

In an example where I have the helmfile (with unnecessary fields removed)

releases:
- chart: dev/myapp
  name: myapp
- chart: dev/myapp
  name: myapp-beta

And I promote like so
jx promote --release myapp-beta with the version 1.0.0

The helmfile will be wrongly edited so the resulting helmfile would look like so

releases:
- chart: dev/myapp
  name: myapp
  version: 1.0.0
- chart: dev/myapp
  name: myapp-beta

The correct helmfile should look like

releases:
- chart: dev/myapp
  name: myapp
- chart: dev/myapp
  name: myapp-beta
  version: 1.0.0

Pullable PR to play around with (if you require it)
#388

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.

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/jenkins-x-plugins/jx-gitops found in your go.mod doesn't match the actual path github.com/jenkins-x/jx-gitops found in the dependency's go.mod.

Updating the module path in your go.mod to github.com/jenkins-x/jx-gitops 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.

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.

Following a discussion at the jx office hours - https://youtu.be/zv0Dn9RYzwE?t=2603

How about changing the promotion "workflow" for jx v3, and always create a PR:

• for the environments in "auto" promotion, either merge the PR or set an "approved" label (so that lighthouse will merge it automatically)
• for the environments in "manual" promotion, create a PR, either in "draft" mode (github) or with specific labels so that it won't be merge automatically

the advantages of such a workflow:

• deploying to prod (which is an env in manual promotion mode) only requires to merge an existing PR. No need to run the jx promote cmd again.
• people can discuss the deployment in the PR
• people can add commits to the PR - for example extra values that might be required by the new version

we've been using this workflow at Dailymotion for a while now, and really like it. Here's how we're creating/updating the "prod" PRs:

• we use a specific label to identify the PR for a specific application in the prod-env git repo - such as update-my-app
• if there is no opened PR with such a label, create a new branch/PR with the update (and the changelog of the release in the body of the PR - this really helps)
• if there is an existing PR with such as label, checkout its branch, and update it with the new version, and push the branch - so we just update the existing PR. We also update the PR body to prepend the changelog for the new version, and we update the title to use the latest version
• these PRs are created in draft mode (in github)

the advantage of updating the existing PR/branch is that the following use-case works well:

• new version 1.2.3
• someone adds a commit to add a helm value for example
• new version 1.2.4
• merge => the new helm value is not lost
  (previously we've been force-pushing the branch and erasing all previous commits, but it means that if you don't merge right away you might lose some changes)

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.

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 couldn't parse the go.mod found at /go.mod.

The error Dependabot encountered was:

go: writing go.mod cache: write /opt/go/gopath/pkg/mod/cache/download/gopkg.in/check.v1/@v/v1.0.0-20141024133853-64131543e789.mod39383461.tmp: no space left on device
go: failed to write version list: write /opt/go/gopath/pkg/mod/cache/download/gonum.org/v1/netlib/@v/list260061626.tmp: no space left on device

View the update logs.

if OCI is enabled when promoting we should also set the oci: true in the modified helmfile

e.g.

repositories:
- name: dev
  url: harbor-jx.jx3.XXX/omvp-upstream
  oci: true
releases:
- chart: dev/ghttp
  version: 0.0.3
  name: ghttp
templates: {}
renderedvalues: {}

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.

Dependabot couldn't parse the go.mod found at /go.mod.

The error Dependabot encountered was:

go: failed to write version list: write /opt/go/gopath/pkg/mod/cache/download/golang.org/x/oauth2/@v/list479678498.tmp: no space left on device

View the update logs.