crd-model-gen:v1.0.6 hasn't been updated in three years

[misterikkit]

trafficstars

Describe the bug The container ghcr.io/kubernetes-client/java/crd-model-gen:v1.0.6 is 3 years old and makes use of a similarly aged KiND version, v0.11.1. Some security tools are flagging these old files as vulnerable. e.g.

$ docker run --rm -it --entrypoint kind ghcr.io/kubernetes-client/java/crd-model-gen:v1.0.6 version
kind v0.11.1 go1.16.4 linux/amd64

Continuing to use this for java codegen may become impossible in environments where I cannot control what security scans run or their strictness.

[brendandburns]

You can always regenerate the image as needed using the script here: https://github.com/kubernetes-client/java/blob/master/scripts/publish-crd-model-gen-image.sh

and the Dockerfile here: https://github.com/kubernetes-client/java/blob/master/client-java-contrib/Dockerfile

We'd welcome a PR updating the version of kind that is used.

Most people don't need to use this script unless they are generating their own CRD code.

[misterikkit]

@brendandburns Thanks for the quick reply.

You can always regenerate the image

I must be misunderstanding, as I surely don't have push permissions to that container repo. Or git tags in this repo.

We'd welcome a PR updating the version of kind that is used.

I'd be glad to bump this to a v1.0.7 but would need coordination with a maintainer to get appropriate tags in place, etc.

Most people don't need to use this script unless they are generating their own CRD code.

We are using this workflow so that java clients can interact with golang controllers. (CRD yaml is generated from golang structs)

[misterikkit]

Oh it seems that HEAD is currently meant to use KiND v0.17.0 due to some improvements from @kozjan

As for publishing a new image, I found two scripts, neither of which seem to ever run. (one is hard-coded to v1.0.0 and the other v2.0.0)

https://github.com/kubernetes-client/java/blob/master/scripts/publish-crd-model-gen-image.sh https://github.com/kubernetes-client/java/blob/master/client-java-contrib/publish-gen-image.sh

[brendandburns]

You can push the image to your own registry and then modify the workflow that you referenced to point to your image, instead of the ghcr one.

If you want to add this parameterization to those scripts, we'd be happy to take those PRs.

[misterikkit]

Much obliged. Parametrization proposed per pull petition https://github.com/kubernetes-client/java/pull/3716

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.