kubesphere-sigs / ks-releaser Goto Github PK

This is the error log output:

     50     message: 'failed to mark as done: failed to clone repository: https://github.com/kubesphere-sigs/ks-versions,
     51       error: failed to pull git repository ''&{%!s(*filesystem.Storage=&{0xc001101900
     52       0xc000242700 {{false false 0} 0xc000dddfb0 0xc000242700 map[[17 130 228 110
     53       206 145 194 116 60 238 194 62 160 63 232 174 50 84 162 83]:0xc000fb2000 [83
     54       132 137 219 16 231 186 20 249 218 97 143 227 131 63 99 45 26 116 28]:0xc000fb2d80
     55       [104 221 84 78 69 78 222 23 149 43 145 99 137 33 200 206 182 97 184 15]:0xc000fb3b00
     56       [110 204 23 59 190 194 151 167 48 16 128 123 78 12 134 147 218 213 144 177]:0xc000fb4880
     57       [189 166 6 116 107 118 190 31 63 127 191 79 150 22 45 134 255 38 10 196]:0xc000fb5600]
     58       [] 0 map[]} {0xc000242700} {0xc000242700} {0xc000242700} {0xc000242700} {0xc000242700}})
     59       map[] %!s(*chroot.ChrootHelper=&{0xc0005b4540 /home/nonroot/tmp/kubesphere-sigs/ks-versions})}'',
     60       error: non-fast-forward update'

The potential upstream issues is jenkins-x/go-scm#306

/kind bug

Background

For a big team, they can put many projects into one GitOps repository. But it's not good to let many people have the access to merge all PRs.

The good news is that you can use something like Prow to let the different small team manage their own release request.

Potential solution

The potential solution might be letting ks-release support load the requesting file (CR of releaser) from different directories.

Clues

If you are interested in this feature, this is might be a good start point.

/good-first-issue

Below is a regular kustomize YAML file:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- manager.yaml

images:
- name: ghcr.io/kubesphere-sigs/ks-releaser
  newName: ghcr.io/kubesphere-sigs/ks-releaser
  newTag: v0.0.13

configMapGenerator:
- files:
  - controller_manager_config.yaml
  name: manager-config

I'd like to suggest having a feature to promote the latest release to a particular environment. Such as, if ks-releaser project just released v0.0.14, then create a PR to bump the version from v0.0.13 to v0.0.14.

Such as, we can have the following CRD:

kind: Promote
spec:
  releaser: xxx
  git: xxx
  environments:
  - name: int
     path: int
     policy: automated | pr

Let assume, you put all Releaser resource files into a git repository, and manage it via Argo CD. In this case, it's great to do the resource spec validation against a Pull request.

What to do

• Provide a webhook endpoint to receive the SCM events from a git provider (such as Github, Gitlab, etc.)
• Add a comment to a PR to show the validation result

There are two use cases:

• Users can only provide the resource file without the version, the release controller can calculate the next release version
• Provide a CLI to generate the resource file
  • Such as: release generate linuxsuren/cgit

Background

If there is a way that we don't need to check the log of ks-releaser controller from the Kubernetes Cluster when something is going wrong, it would be wonderful. For GitOps users, people focus on the git repository.

Suggestion

We can have a new controller to watch the status of a Releaser CR, it can create an issue on the target GitOps repository once there are some errors found. So, people can know what happened from the issues.

Some metrics might be very helpful for the monitor purpose. Such as:

• release count of a particular git repository
• TODO

Katacoda is a pretty awesome interactive learning platform. People can give this project a try without a real Kubernetes cluster.

What to do

You don't need to write any Golang code lines. Basically, you just need to understand JSON and YAML.

Then try to learn from the existing scenario.

/good-first-issue