Support Typescript incremental build

🚀 Feature request
- [ ] new
- [x] build
- [x] serve
- [x] test
- [x] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc

Description
Support of Typescript incremental build https://devblogs.microsoft.com/typescript/announcing-typescript-3-4-rc/

3.4 is officially out. Out of curiosity may I ask what is currently causing this to be marked as "blocked"?

Angular itself needs to support a TS version before it can be integrated into the tooling.

@alan-agius4 @filipesilva Hi Guys! Congrats on the new release! Just wondering if there has been any development with this improvement since TS 3.4 is now supported.

since TS 3.4 is now supported.

@RicardoVaranda Angular 8.0.0 supports TypeScript 3.3, but not 3.4 (which introduced the incremental flag).
https://github.com/angular/angular/blob/master/CHANGELOG.md

add support for TypeScript 3.3

@MartinJohns Interestingly, 3.4 looks like it was merged into angular-8-beta-12: https://github.com/angular/angular/commit/ef853367194c77f505a0705e45f5670725873da1

Can confirm this, upon doing ng update it actually installed 3.4.2

Is important to note that 3.4 introduce a regression that make type checking in compilation pain slow in some scenarios.
Now 3.5 is out with this regression fixed: https://devblogs.microsoft.com/typescript/announcing-typescript-3-5/

Speed improvements
TypeScript 3.5 introduces several optimizations around type-checking and incremental builds.
Type-checking speed-ups
Much of the expressivity of our type system comes with a cost – any more work that we expect the compiler to do translates to longer compile times. Unfortunately, as part of a bug fix in TypeScript 3.4 we accidentally introduced a regression that could lead to an explosion in how much work the type-checker did, and in turn, type-checking time. The most-impacted set of users were those using the styled-components library. This regression was serious not just because it led to much higher build times for TypeScript code, but because editor operations for both TypeScript and JavaScript users became unbearably slow.

Angular version 8 supports (and requires) TypeScript 3.4.x. I haven't look at this again, but at the time the only problem I saw was https://github.com/angular/angular/pull/29872.
We have to try and figure out what else (if anything) is preventing the incremental cache from being used and written.
I'm not sure it can be used in the AOT compiler though, so keep that in mind. Maybe it works, maybe it doesn't.
If anyone is interested in having a look at this, here's a good way to get started:
git clone https://github.com/angular/angular-cli
cd angular-cli
yarn

Then open packages/angular_devkit/build_angular/test/browser/works_spec_large.ts and replace it( with fit(. Also remove the afterEach. Now whenever you run yarn test-large, only this test runs. The results for this test will be in a temporary folder in tests/angular_devkit/build_angular.
At this point you'd just have to hunker down and go figure out what the logic for incremental builds in TS is trying to do, and how to work with it. There's not a lot of docs around it. When I was looking into this, I just added a lot of logs to the TS source in node_modules/typescript.
We use a in-memory file system for TS in packages/ngtools/webpack. So even if the cache file is being written, if TS is writing it then it will stay in memory. It would have to be written there somewhere. Check the packages/ngtools/webpack/src/compiler_host.ts for the FS abstraction used by TS. Maybe log some stuff in the writeFile method.

From what I understand for incremental build to work and actually save time, files have to be emitted to outDir. If the incremental flag is true, there will be an extra tsconfig.tsbuildinfo file that holds hashes of involved files.
When we build with the CLI, outDir does not seem to be used. @filipesilva is this part also using in-memory file system during build? If it is virtualized, do you know if differential build reuses the same virtual FS or a new is created?
I am quite curious about this, for my little chrome extension (for e2e tests), if I run tsc command and pass project tsconfig, first build is ~15s, 2nd ~5s

@FDIM I think realistically what would happen is that we'd have to allow that file to be loaded between builds.
Maybe to make sure it's loaded it is enough to give it a custom path instead of the outDir default. But at the end of each build it would still need to be persisted to disk with custom logic.
I am not sure how much this would help for differential loading as each build does use different ES targets. At that point it depends on how much TS itself caches for those cases.
We don't use TS loader, mind you. We have our own loader tailored to the Angular AOT compiler. So I don't think ts-loader supporting it blocks us.

For reference, the incremental API issue on TS is https://github.com/microsoft/TypeScript/issues/29978.

My bad regarding ts-loader, I should have realized that when tinkering with the loader in CLI.
I am fairly sure that writing tsconfig.tsbuildinfo file to disk would not be enough, it also needs already built files from last time to avoid compilation. Anyway, I did manage to output build files to disk after running ng build, but tsbuildinfo was not part of the output - not sure why.

Typescript already finished their implementation, so it should be possible to try it here :)

Seems like there are no more roadblocks for Angular to support incremental builds.
Some related changes that happened since then:
Provide --build/--incremental APIs for build tools:
https://github.com/microsoft/TypeScript/issues/29978
Api for tsc --build and --incremental:
https://github.com/microsoft/TypeScript/pull/31432
Docs are in progress:
https://github.com/microsoft/TypeScript/issues/31849
TS 3.5 Release notes about speed improvements and fixed regression from 3.4:
https://devblogs.microsoft.com/typescript/announcing-typescript-3-5-rc/#speed-improvements

Seems like there are no more roadblocks for Angular to support incremental builds.

@pppdns Does this mean I just have to set "compilerOptions": { "incremental": true } in my tsconfig.json and it works or is there still something to do on the Angular-side?

@wottpal
hope it's simple as that

Unfortunately to improve cold start/initial compile, additional work is needed.
Api wise, new cache dir option should be enough, but it still need to be implemented.

@FDIM I may be reading this wrong, but doesn't this permit arbitrary compiler options?
If so, doesn't tsBuildInfoFile provide the ability to specify the location of build cache?

Anything new here ? Typescript 3.5 is now supported by Angular

would be nice to have support of incremental build for ngc

Also with incremental build it would be not nice but super duper to have support of composite projects. I think it would heavily help large projects to split their projects into smaller subprojects. As far as i know typescript created API for both incremental and "composite" build mode in 3.5.
Well i think it has to supported in compiler-cli first so maybe this issue should go to angular project?
:)

Any updates on this? Looking to implement this in a complex project that I recently upgraded to Angular 8.2. I added the incremental and tsBuildinfoFile properties but I don't see a difference (I dont even see any new files generated anywhere)

I am not sure what happened, but the API for incremental option/program is not available in TS 3.5, only in 3.6. It will soon be released though (23rd of August according to road map).
So for now I'd say this is blocked until angular packages depend on 3.6. Afterwards 2 solutions will be needed:

find a way to configure current build to emit compiled ts files and tsbuildinfo in cache/out dir (side note: Maybe ivy could use this to cache factories as well to further improve cold start time)
find a way to create incremental program that uses existing tsbuildinfo and feed that to current build. As far as I understand this program could be used as oldProgram (not sure though...)

As for cache dir @filipesilva , I guess it would be best to reuse outDir from ts config instead of adding new to angular.json? Currently angular compiler plugin is resetting this value and if it is set, build fails with a bit unclear message.

@FDIM Where did you hear that? The documentation for typescript seem to indicate this is available in 3.4:
https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-4.html

The functionality was available via tsc (the TypeScript command line interface) in 3.4.  What is needed here for it to be considered for inclusion is programmatic access.

@FDIM yes it is interesting about that API and version of typescript, because i followed release of 3.5 and fix was not present at time of release 3.5, but still they put it in changelog of 3.5 even thou i read some guy complaint that there is no API for incremental build available in 3.5, so it looks like some mess in release log, but it will be in 3.6 definitely :)

@aruballo I've tried to use the api to see how it works, only to realize that it is not there

How weird, I guess I'll have to wait for 3.6 before using this then. Thanks @FDIM

https://devblogs.microsoft.com/typescript/announcing-typescript-3-6-rc/
Well it looks like it is finally coming for real to typescript, i would love to see it in angular compiler, both --build and --incremental support :)

https://devblogs.microsoft.com/typescript/announcing-typescript-3-6/
🔥🔥🔥

Any movement here? Or probably this is waiting for release of 9th version and there is primary focus for that now, probably. :)

I should set expectations regarding the potential usefulness of supporting TS's --incremental functionality right now. As a recap, this functionality from TS allows a typescript compilation to reuse artifacts from a previous compilation in order to be faster. This doesn't apply to watch mode. It only applies to whole new compilations (e.g. calling the command from the console again).
In an Angular CLI context this would mean that some calls to ng build, ng serve and ng test might be faster after the first call. Ideally you'd want your slowest builds, usually the production builds, to get faster by using this new typescript functionality. But there are a lot of caveats here.
First and foremost is that the typescript compilation is only one part of building an app, and not necessarily what takes longer. Then there's the fact that AOT compilation is not just a Typescript compilation, there's many other things happening there that have nothing to do with compiling TS. Another thing to take into consideration is that CI builds wouldn't use this either unless you were very careful in managing the TS cache.
Realistically, this means that production builds wouldn't see any improvement because they use AOT and a big chunk of the time is spent in bundle optimization. JIT development builds are what would benefit from TS's --incremental functionality. But with Ivy it's already preferable to develop in AOT, so no benefit again.
I feel this feature looks very desirable because it sounds like it would make all builds much faster. But the reality is that it would make some of the faster builds a bit faster, while the others would remain the same. Notably rebuilds on watch mode are entirely unaffected, because this functionality isn't related to watch mode.

Thanks for clarification. What about composite projects ? For me this would be more beneficial than incremental, because this allows split big projects into "smaller" parts.
BTW ts-loader managed to use incremental api somehow https://github.com/TypeStrong/ts-loader/issues/913, but i do understand that one thing is angular compilation and different thing is typescript compilation.

@kukjevov we don't have any support for composite projects at the moment so I don't think that would be a factor here. I'm not sure how it would work in the app case anyway... within the app rebuilds are already incremental, and outside the apps there are only libs, and libs need their own build process that also involves AOT.
AOT means "Ahead of Time" and is used in contrast with JIT, which means "Just in Time". Template compilation happens in the browser when you are not doing AOT compilation (e.g. you are in JIT). This means your app is loaded on the browser, then it reads all the templates (html and css), and then converts them into JS code to be used by Angular.
This increases the app startup time and also needs the compiler needs to be bundled with your application. When you do AOT compilation, you compile templates when you build your app locally, and then you don't have to bundle the compiler at all or spend time in the browser compiling things.
The difference between AOT compilation and TS compilation is that AOT compilation also compiles your templates in addition to doing TS compilation. The AOT compiler is usually referred to as ngc because that's the binary that @angular/compiler-cli exposes for AOT compilation.

Hi @filipesilva, thx for your answer :).
I know how is AOT working and what it means :). Well i would like to explain you my case.
I have one bigger project. It has parts that are not changed often and are not dependent on many other files. These files, or better said this directory is ideal canditate for reference project. Because it has not dependencies outside of this directory and is not often changed. So if you use composite project, it will store build output information and reuse them for next compilation. Which is great because it saves resources. I have few directories that could be turned into this type of reference project. This is project which is using JIT, so it is compiled only using plain Typescript. So far i have been using awesome typescript loader, but i would like to try ts-loader which looks like already have support for incremental and composite projects (ts-loader team somehow managed to implement also watch api with composite and incremental api).
I plan to migrate it to angular 9 with ivy as soon as possible :). I believe it will be faster, because i already have small projects running angular 9.0.0-next.9 with aot and ivy and it is total brutal fast, but project is smaller. So maybe this will not be necessary if i migrate to ivy and 9, but still it would be awesome to have some option to split projects into smaller parts and dependent parts would reuse metainfo or something from last compilation so typechecking, template compilation and other stuff does not have to be done everytime, but maybe this is solved in ivy already, because as i said those smaller projects are insanly fast.
Still everything is awesome i just asking if something like that is planned :).

@filipesilva is correct that composite projects are not supported currently. There is no strong technical reason for this, it's just not been a priority since there are other ways Angular users split up compilations (e.g. nx workspaces, Bazel) and we need to ensure the compiler does a good job for these circumstances first. Once the general multi-project story is in a good place, it will make sense to implement the TS layer.
The same is true for the incremental build cache. One of the big requirements is having strong incremental rebuild semantics under --watch. We have a roadmap for this that we're part of the way through implementing.
It's very important that we get the semantics right when we move to an incremental cache. Right now under --watch we have a safety net: if the compiler has a bug and does not handle an incremental change correctly, the user will just kill the --watch compilation (e.g. by killing ng serve) and rerun it. This safety net doesn't exist with an incremental build cache - if we process a change incorrectly, the mistake will persist until you turn off incremental compilation. Therefore I want to move slowly and deliberately when implementing this feature. I'd rather err on the side of not supporting it until we're absolutely sure our semantics are perfect.

Just dropping in a use-case here for composite project support.
We have a typescript monorepo of which one of the packages is the main front-end angular app and which consumes a number of other application-like packages in a yarn workspace (and those packages have other dependencies in the repo, such as a core ECS package, a general service interaction layer etc). Building any one of these applications will auto-build any composite dependencies it needs (and their dependencies and so on), so conceptually we only need to run a build on any one top-level application a developer's working on.
For the angular frontend we have to first build all packages it depends on and get a build watcher going on each application a developer is working on. These are better than nothing but pretty slow and sometimes unreliable. It's also just generally a bit of a pain for devs to get an environment set up. So in our case it's not so much the incremental build cache (though that would be nice!) but the ability to allow typescript to recognise other composite projects in the repo with the build flag that we're really interested in.

I have a different use case regarding composite projects where I only have non angular related code in separate projects under a yarn workspace.
I was expecting to be able to use @ngtools/webpack with a tsconfig that defines the reference and enables composite mode, but it looks like it doesn't work properly, and doesn't build referenced projects. The separate projects output their compiled js to directories such as /lib underneath them, and everything is resolved through package.json references.
As a workaround, I need to build the referenced projects manually before starting the main angular webpack build.
I'm wondering if @ngtools/webpack could be updated to support this minimal scenario of composite projects until full AOT support is added.

Any updates on this?


Doesn't appear to be working - TLS bad certificate

I just deployed this into my kubernetes cluster that is running k3s 1.26.1 and calico cni 3.25 with ebpf/dsr
Helm values
    controllers:
      image:
        repository: quay.io/enix/kube-image-keeper
    proxy:
      image:
        repository: quay.io/enix/kube-image-keeper
    registry:
      image:
        repository: public.ecr.aws/docker/library/registry
      persistence:
        enabled: true
        storageClass: ceph-filesystem
        size: 20Gi

Resources
❯ k get po -n kube-system | rg kube-
kube-image-keeper-0                                     1/1     Running   0               39m
kube-image-keeper-controllers-6ddc99bfb9-7c2t4          1/1     Running   0               39m
kube-image-keeper-controllers-6ddc99bfb9-vrv4h          1/1     Running   0               39m
kube-image-keeper-proxy-8hszk                           1/1     Running   0               39m
kube-image-keeper-proxy-9p2cw                           1/1     Running   0               39m
kube-image-keeper-proxy-gzdvx                           1/1     Running   0               39m
kube-image-keeper-proxy-l64nh                           1/1     Running   0               39m
kube-image-keeper-proxy-ntrt8                           1/1     Running   0               39m
kube-image-keeper-proxy-r62cf                           1/1     Running   0               39m

❯ k get cachedimages -A
No resources found

❯ k get certificates -A
NAMESPACE               NAME                                     READY   SECRET                                   AGE
kube-system             kuik-serving-cert                        True    webhook-server-cert

Logs
I notice when I try to restart any pod or deploy a new one these errors happen..
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:05:07.813Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:05:07.814Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:06:15.900Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:06:15.901Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023/02/03 14:06:47 http: TLS handshake error from <IP_ADDRESS>:34158: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:07:32.832Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:07:32.832Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023/02/03 14:07:50 http: TLS handshake error from <IP_ADDRESS>:52718: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:08:52.861Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:08:52.862Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:09:58.798Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:09:58.799Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:11:08.860Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:11:08.861Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:12:20.916Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:12:20.917Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:13:22.915Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:13:22.915Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:14:31.927Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:14:31.928Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:15:54.815Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:15:54.816Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023/02/03 14:17:15 http: TLS handshake error from <IP_ADDRESS>:45374: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023/02/03 14:17:15 http: TLS handshake error from <IP_ADDRESS>:45384: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023/02/03 14:17:16 http: TLS handshake error from <IP_ADDRESS>:45390: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023/02/03 14:17:16 http: TLS handshake error from <IP_ADDRESS>:45398: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:17:16.856Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:17:16.856Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023/02/03 14:17:49 http: TLS handshake error from <IP_ADDRESS>:47174: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023/02/03 14:17:49 http: TLS handshake error from <IP_ADDRESS>:47176: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:18:19.858Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:18:19.858Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:19:42.904Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:19:42.904Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:20:59.841Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:20:59.842Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023/02/03 14:21:40 http: TLS handshake error from <IP_ADDRESS>:41622: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:21:45.054Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:21:45.054Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:22:15.854Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:22:15.855Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:23:12.017Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:23:12.018Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:23:33.792Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:23:33.793Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023/02/03 14:23:42 http: TLS handshake error from <IP_ADDRESS>:46590: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:24:21.961Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:24:21.961Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:24:43.812Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:24:43.813Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:25:31.030Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:25:31.031Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:26:10.861Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:26:10.861Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-0 kube-image-keeper time="2023-02-03T14:26:16.098319022Z" level=info msg="PurgeUploads starting: olderThan=2023-01-27 14:26:16.098137541 +0000 UTC m=-603059.989528036, actuallyDelete=true"
kube-image-keeper-0 kube-image-keeper time="2023-02-03T14:26:16.098560456Z" level=info msg="Purge uploads finished.  Num deleted=0, num errors=0"
kube-image-keeper-0 kube-image-keeper time="2023-02-03T14:26:16.098602693Z" level=info msg="Starting upload purge in 24h0m0s" go.version=go1.16.15 instance.id=4ef434ec-57d5-4cda-b732-c77407757e00 service=registry version="v2.8.1+unknown"
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:26:38.059Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:26:38.059Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:27:16.814Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:27:16.814Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate

Let me know if there's any other information you need.

More logs
❯ k -n kube-system logs kube-image-keeper-0
Defaulted container "kube-image-keeper" out of: kube-image-keeper, setup-dirs (init), garbage-collector (init)
time="2023-02-03T13:57:16.09727591Z" level=warning msg="No HTTP secret provided - generated random secret. This may cause problems with uploads if multiple registries are behind a load-balancer. To provide a shared secret, fill in http.secret in the configuration file or set the REGISTRY_HTTP_SECRET environment variable."   Num deleted=0, num errors=0"
time="2023-02-03T14:26:16.098602693Z" level=info msg="Starting upload purge in 24h0m0s" go.version=go1.16.15 instance.id=4ef434ec-57d5-4cda-b732-c77407757e00 service=registry version="v2.8.1+unknown"

❯ stern -n kube-system kube-image-keeper-controllers
+ kube-image-keeper-controllers-6ddc99bfb9-7c2t4 › cache-manager
+ kube-image-keeper-controllers-6ddc99bfb9-vrv4h › cache-manager
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager I0203 13:57:15.008588       1 request.go:655] Throttling request took 1.029788011s, request: GET:https://<IP_ADDRESS>:443/apis/image.toolkit.fluxcd.io/v1beta1?timeout=32s
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T13:57:15.573Z	INFO	controller-runtime.metrics	metrics server is starting to listen	{"addr": ":8080"}
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T13:57:15.574Z	INFO	controller-runtime.webhook	registering webhook	{"path": "/mutate-core-v1-pod"}
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T13:57:15.574Z	INFO	setup	starting manager
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager I0203 13:57:15.576299       1 leaderelection.go:243] attempting to acquire leader lease kube-system/a046788b.kuik.enix.io...
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T13:57:15.576Z	INFO	controller-runtime.manager	starting metrics server	{"path": "/metrics"}
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T13:57:15.678Z	INFO	controller-runtime.webhook.webhooks	starting webhook server
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T13:57:15.678Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T13:57:15.678Z	INFO	controller-runtime.webhook	serving webhook server	{"host": "", "port": 9443}
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T13:57:15.679Z	INFO	controller-runtime.certwatcher	Starting certificate watcher
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T13:57:16.029Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T13:57:16.030Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T13:58:34.885Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T13:58:34.886Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T13:59:59.830Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T13:59:59.830Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023/02/03 14:00:00 http: TLS handshake error from <IP_ADDRESS>:45446: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023/02/03 14:00:04 http: TLS handshake error from <IP_ADDRESS>:45460: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023/02/03 14:00:10 http: TLS handshake error from <IP_ADDRESS>:50334: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:01:19.767Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:01:19.768Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:02:33.823Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:02:33.824Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:03:50.913Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:03:50.914Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:05:07.813Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:05:07.814Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:06:15.900Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:06:15.901Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023/02/03 14:06:47 http: TLS handshake error from <IP_ADDRESS>:34158: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:07:32.832Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:07:32.832Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023/02/03 14:07:50 http: TLS handshake error from <IP_ADDRESS>:52718: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:08:52.861Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:08:52.862Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:09:58.798Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:09:58.799Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:11:08.860Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:11:08.861Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:12:20.916Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:12:20.917Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:13:22.915Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:13:22.915Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:14:31.927Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:14:31.928Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:15:54.815Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:15:54.816Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023/02/03 14:17:15 http: TLS handshake error from <IP_ADDRESS>:45374: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023/02/03 14:17:15 http: TLS handshake error from <IP_ADDRESS>:45384: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023/02/03 14:17:16 http: TLS handshake error from <IP_ADDRESS>:45390: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023/02/03 14:17:16 http: TLS handshake error from <IP_ADDRESS>:45398: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:17:16.856Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:17:16.856Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023/02/03 14:17:49 http: TLS handshake error from <IP_ADDRESS>:47174: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023/02/03 14:17:49 http: TLS handshake error from <IP_ADDRESS>:47176: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:18:19.858Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:18:19.858Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:19:42.904Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:19:42.904Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:20:59.841Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:20:59.842Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:22:15.854Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:22:15.855Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:23:33.792Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:23:33.793Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023/02/03 14:23:42 http: TLS handshake error from <IP_ADDRESS>:46590: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:24:43.812Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:24:43.813Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:26:10.861Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:26:10.861Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:27:16.814Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:27:16.814Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:28:46.939Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:28:46.939Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:29:54.843Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:29:54.843Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:31:08.873Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:31:08.874Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:32:11.812Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:32:11.812Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:33:22.913Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:33:22.914Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:34:27.878Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:34:27.879Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:35:43.893Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:35:43.893Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:36:54.824Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:36:54.824Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:38:05.898Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:38:05.899Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:39:07.882Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:39:07.882Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:40:31.797Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:40:31.798Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:41:53.777Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-7c2t4 cache-manager 2023-02-03T14:41:53.778Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager I0203 13:57:14.594389       1 request.go:655] Throttling request took 1.030109139s, request: GET:https://<IP_ADDRESS>:443/apis/objectbucket.io/v1alpha1?timeout=32s
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T13:57:15.148Z	INFO	controller-runtime.metrics	metrics server is starting to listen	{"addr": ":8080"}
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T13:57:15.148Z	INFO	controller-runtime.webhook	registering webhook	{"path": "/mutate-core-v1-pod"}
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T13:57:15.148Z	INFO	setup	starting manager
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager I0203 13:57:15.149127       1 leaderelection.go:243] attempting to acquire leader lease kube-system/a046788b.kuik.enix.io...
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager I0203 13:57:15.160270       1 leaderelection.go:253] successfully acquired lease kube-system/a046788b.kuik.enix.io
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T13:57:15.250Z	INFO	controller-runtime.webhook.webhooks	starting webhook server
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T13:57:15.250Z	INFO	controller-runtime.manager	starting metrics server	{"path": "/metrics"}
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T13:57:15.250Z	INFO	controller-runtime.manager.controller.pod	Starting EventSource	{"reconciler group": "", "reconciler kind": "Pod", "source": "kind source: /, Kind="}
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T13:57:15.250Z	INFO	controller-runtime.manager.controller.cachedimage	Starting EventSource	{"reconciler group": "kuik.enix.io", "reconciler kind": "CachedImage", "source": "kind source: /, Kind="}
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T13:57:15.251Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T13:57:15.251Z	INFO	controller-runtime.webhook	serving webhook server	{"host": "", "port": 9443}
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T13:57:15.251Z	INFO	controller-runtime.certwatcher	Starting certificate watcher
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T13:57:15.252Z	INFO	controller-runtime.manager.controller.pod	Starting EventSource	{"reconciler group": "", "reconciler kind": "Pod", "source": "kind source: /, Kind="}
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T13:57:15.352Z	INFO	controller-runtime.manager.controller.cachedimage	Starting Controller	{"reconciler group": "kuik.enix.io", "reconciler kind": "CachedImage"}
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T13:57:15.352Z	INFO	controller-runtime.manager.controller.cachedimage	Starting workers	{"reconciler group": "kuik.enix.io", "reconciler kind": "CachedImage", "worker count": 1}
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T13:57:15.352Z	INFO	controller-runtime.manager.controller.pod	Starting Controller	{"reconciler group": "", "reconciler kind": "Pod"}
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T13:57:15.352Z	INFO	controller-runtime.manager.controller.pod	Starting workers	{"reconciler group": "", "reconciler kind": "Pod", "worker count": 1}
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T13:57:15.646Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T13:57:15.646Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T13:58:34.041Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T13:58:34.042Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T13:59:56.079Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T13:59:56.079Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023/02/03 14:00:00 http: TLS handshake error from <IP_ADDRESS>:48946: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023/02/03 14:00:00 http: TLS handshake error from <IP_ADDRESS>:48948: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023/02/03 14:00:00 http: TLS handshake error from <IP_ADDRESS>:48960: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023/02/03 14:00:00 http: TLS handshake error from <IP_ADDRESS>:48962: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023/02/03 14:00:00 http: TLS handshake error from <IP_ADDRESS>:48976: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023/02/03 14:00:08 http: TLS handshake error from <IP_ADDRESS>:42916: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:00:58.022Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:00:58.022Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:02:12.111Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:02:12.112Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:03:25.113Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:03:25.113Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:04:45.980Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:04:45.980Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:05:47.092Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:05:47.092Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023/02/03 14:06:47 http: TLS handshake error from <IP_ADDRESS>:43428: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023/02/03 14:06:47 http: TLS handshake error from <IP_ADDRESS>:43432: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023/02/03 14:06:47 http: TLS handshake error from <IP_ADDRESS>:43446: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023/02/03 14:06:47 http: TLS handshake error from <IP_ADDRESS>:43448: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:06:52.041Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:06:52.041Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023/02/03 14:07:47 http: TLS handshake error from <IP_ADDRESS>:55936: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023/02/03 14:07:47 http: TLS handshake error from <IP_ADDRESS>:55948: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023/02/03 14:07:50 http: TLS handshake error from <IP_ADDRESS>:55964: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023/02/03 14:07:50 http: TLS handshake error from <IP_ADDRESS>:55972: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:08:02.070Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:08:02.070Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:09:22.040Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:09:22.041Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:10:39.124Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:10:39.125Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:12:08.058Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:12:08.058Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:13:27.021Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:13:27.021Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:14:28.058Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:14:28.058Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:15:58.047Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:15:58.047Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023/02/03 14:16:49 http: TLS handshake error from <IP_ADDRESS>:60066: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023/02/03 14:16:49 http: TLS handshake error from <IP_ADDRESS>:60078: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023/02/03 14:16:49 http: TLS handshake error from <IP_ADDRESS>:60088: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023/02/03 14:16:49 http: TLS handshake error from <IP_ADDRESS>:60096: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023/02/03 14:16:49 http: TLS handshake error from <IP_ADDRESS>:60100: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023/02/03 14:16:49 http: TLS handshake error from <IP_ADDRESS>:60112: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:17:06.966Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:17:06.966Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023/02/03 14:17:24 http: TLS handshake error from <IP_ADDRESS>:57806: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:18:16.002Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:18:16.002Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:19:22.078Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:19:22.078Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:20:42.032Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:20:42.032Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023/02/03 14:21:40 http: TLS handshake error from <IP_ADDRESS>:41622: remote error: tls: bad certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:21:45.054Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:21:45.054Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:23:12.017Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:23:12.018Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:24:21.961Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:24:21.961Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:25:31.030Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:25:31.031Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:26:38.059Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:26:38.059Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:27:45.004Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:27:45.004Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:28:50.094Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:28:50.094Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:30:02.032Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:30:02.033Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:31:15.049Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:31:15.049Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:32:39.016Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:32:39.016Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:33:50.029Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:33:50.029Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:35:12.983Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:35:12.983Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:36:21.010Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:36:21.010Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:37:22.969Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:37:22.969Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:38:39.993Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:38:39.993Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:39:54.067Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:39:54.067Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:41:02.045Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:41:02.046Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:42:03.033Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
kube-image-keeper-controllers-6ddc99bfb9-vrv4h cache-manager 2023-02-03T14:42:03.034Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate

Hi @onedr0p , we'll try to reproduce.
Can you confirm the kuik version you installed ? 1.0.1 ?
Also can you confirm that cert-manager is installed ? (i think so according your first snippet)

I am using 1.0.1 of the helm chart, my deployment is actually open. You can see it here
Cert-manager is also installed as seen here.

I'm not able to reproduce on a fresh k3s cluster.
My thought is that there is something wrong when the webhook is called.
I suggest you to check if the secret webhook-server-cert exists and that you don't have anything that can prevent the CA to be used to call the webhook (https://github.com/enix/kube-image-keeper/blob/main/helm/kube-image-keeper/templates/mutatingwebhookconfiguration.yaml#L5). Maybe kubectl get events can help to debug.

The secret appears to be there:
❯ k -n kube-system get secrets | rg webhook
external-secrets-webhook                             Opaque               4      29d
snapshot-validation-webhook-tls                      kubernetes.io/tls    3      29d
webhook-server-cert                                  kubernetes.io/tls    3      29d

As so does the mutatingwebhook:
❯ k get mutatingwebhookconfigurations -A
NAME                                                       WEBHOOKS   AGE
actions-runner-controller-mutating-webhook-configuration   4          19d
cert-manager-webhook                                       1          29d
cnpg-mutating-webhook-configuration                        3          29d
inteldeviceplugins-mutating-webhook-configuration          9          29d
kube-prometheus-stack-admission                            1          29d
kuik-mutating-webhook-configuration                        1          2d23h

Events has some interesting output:
6s                        Warning   BadConfig            CertificateRequest/kuik-serving-cert-sb7vw                 Certificate will be issued with an empty Issuer DN, which contravenes RFC 5280 and could break some strict clients
6s                        Normal    cert-manager.io      CertificateRequest/kuik-serving-cert-sb7vw                 Certificate request has been approved by cert-manager.io
6s                        Normal    WaitingForApproval   CertificateRequest/kuik-serving-cert-sb7vw                 Not signing CertificateRequest until it is Approved
6s                        Normal    WaitingForApproval   CertificateRequest/kuik-serving-cert-sb7vw                 Not signing CertificateRequest until it is Approved
6s                        Normal    WaitingForApproval   CertificateRequest/kuik-serving-cert-sb7vw                 Not signing CertificateRequest until it is Approved
6s                        Normal    WaitingForApproval   CertificateRequest/kuik-serving-cert-sb7vw                 Not signing CertificateRequest until it is Approved
6s                        Normal    WaitingForApproval   CertificateRequest/kuik-serving-cert-sb7vw                 Not signing CertificateRequest until it is Approved

Hi,
I really think that the issue is caused by the Certificate/Secret. Usually, we always deploy Kuik into its own namespace.
You installed it into kube-system which seems already contains a secret named webhook-server-cert (which is too much generic, we will update it in a next release as well as some other object name) and i think there is a conflict with that secret. -> The secret is 29d old.
You probably have an other apps deployed in kube-system that create this secret ?

That could very well be it and I'll go ahead and try deploying this in its own namespace to confirm. I'll post back later today, thanks!

Looks like that has fixed the issue but then leads into another one. :/
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  99s                default-scheduler  Successfully assigned default/zigbee2mqtt-0 to k8s-0
  Warning  Failed     84s (x2 over 97s)  kubelet            Failed to pull image "localhost:7439/ghcr.io/koenkk/zigbee2mqtt:1.30.1": rpc error: code = Unknown desc = failed to pull and unpack image "localhost:7439/ghcr.io/koenkk/zigbee2mqtt:1.30.1": failed to resolve reference "localhost:7439/ghcr.io/koenkk/zigbee2mqtt:1.30.1": failed to do request: Head "http://localhost:7439/v2/ghcr.io/koenkk/zigbee2mqtt/manifests/1.30.1": dial tcp <IP_ADDRESS>:7439: connect: connection refused
  Warning  Failed     84s (x2 over 97s)  kubelet            Error: ErrImagePull
  Normal   Pulling    84s (x2 over 97s)  kubelet            Pulling image "localhost:7439/ghcr.io/kpetremann/mqtt-exporter:1.0.4"
  Warning  Failed     84s (x2 over 97s)  kubelet            Failed to pull image "localhost:7439/ghcr.io/kpetremann/mqtt-exporter:1.0.4": rpc error: code = Unknown desc = failed to pull and unpack image "localhost:7439/ghcr.io/kpetremann/mqtt-exporter:1.0.4": failed to resolve reference "localhost:7439/ghcr.io/kpetremann/mqtt-exporter:1.0.4": failed to do request: Head "http://localhost:7439/v2/ghcr.io/kpetremann/mqtt-exporter/manifests/1.0.4": dial tcp <IP_ADDRESS>:7439: connect: connection refused
  Warning  Failed     84s (x2 over 97s)  kubelet            Error: ErrImagePull
  Normal   BackOff    72s (x3 over 96s)  kubelet            Back-off pulling image "localhost:7439/ghcr.io/koenkk/zigbee2mqtt:1.30.1"
  Warning  Failed     72s (x3 over 96s)  kubelet            Error: ImagePullBackOff
  Normal   BackOff    72s (x3 over 96s)  kubelet            Back-off pulling image "localhost:7439/ghcr.io/kpetremann/mqtt-exporter:1.0.4"
  Warning  Failed     72s (x3 over 96s)  kubelet            Error: ImagePullBackOff
  Normal   Pulling    58s (x3 over 97s)  kubelet            Pulling image "localhost:7439/ghcr.io/koenkk/zigbee2mqtt:1.30.1"

I'll go ahead and open another issue with more details.

No, instead I'm using spegel.
https://github.com/spegel-org/spegel


TypeORM - Simple-array doesn't work

Hello,
I want to use FilterableField with a simple-array (typeorm), exemple :
  @FilterableField(() => [RolesEnum])
  @Column({
    type: 'simple-array',
    enum: RolesEnum,
    name: 'roles',
    default: [RolesEnum.CUSTOMER],
  })
  roles: RolesEnum[];

But i have this error :
Error: Unable to create filter comparison for [{"DEVELOPER":"DEVELOPER","ADMIN":"ADMIN","CUSTOMER":"CUSTOMER"}].
Same error when changing from [RolesEnum] to [String]
If you have a solution for me, I'm interested, thank you!
Thank's !
PS : Is it possible to create a typeorm querybuilder to customize the query as I see fit?
I want to use postgis SQL statements

Interesting, I have the feeling it is because everything "array" is seen as a relation and @FilterableField does not handle that, could you add this case to an example (basic for example)? Than I can check it out.

Thank you for your responsiveness and for explaining it to me. It's a project with users who can have multiple roles in the app: artisan, client, admin, etc. So, I use the role to handle this, and I put it in an array to simplify the app and easily include it in the JWT.
When I want to retrieve a list of users, I use
  @Query(() => UserConnection, {
    nullable: true,
    description: `Liste des artisans`,
  })
  // @UseGuards(GqlAuthGuard)
  getArtisans(
    @Args() query: UserQuery,
    @Args('extra') extraSearch: ExtendSearchArtisanInput
  ): Promise<ConnectionType<User>> {
    return this.usersService.indexArtisans(query, extraSearch);
  }

  @Query(() => UserConnection, {
    nullable: true,
    description: `Liste des artisans`,
  })
  getArtisans(
    @Args() query: UserQuery
  ): Promise<ConnectionType<User>> {
    return this.usersService.indexArtisans(query);
  }

  async indexArtisans(data: UserQuery) {
    return UserConnection.createFromPromise(
      (q) => this.usersQueryService.query(q),
      { ...data, ...{ filter: data.filter } },
      (filter) => this.usersQueryService.count(filter)
    );
  }

But I encounter the aforementioned error.
I would have liked to use a query builder and be able to utilize your GraphQL return because it's very convenient, but I couldn't retrieve a query builder with your library, or at least I couldn't find one. 😬

Can you give me an example ?

Here are some docs on how to create a custom service, in the constructor:
super(repo, {
      filterQueryBuilder: CustomFilterQueryBuilder
})

Closing as it's (I think?) the same as #233


Remove unnecessary casting to prevent a crash

Fixes this crash: https://gist.github.com/jeremiahwinsley/96a5bf3e5f052103bb4443b5c7e88ea0
because arrows are not a LivingEntity. Additionally cleans up some other unnecessary casting for the entity being damaged.

I am seeing this same crash consistently. Came here to report the issue, but I see this pull would fix it.
I recommend taking this change.


Add terminal_check_js.go file, for compatibility with GopherJS

This allows logrus to compile with GopherJS.
The test suite still doesn't work with GopherJS, due to the use of runtime.Caller() in the test-specific getPackage() method.
If running the test suite against GopherJS is desirable, I suggest doing that in a separate PR (and probably adding it to .travis.yml, too).  I'm happy to take on that task, if it would be considered useful.

Do you think it would make sense to add a GOOS=js (or is js an GOARCH?) run to the travis testing matrix?

It's probably a good idea, but it's not nearly as trivial as this PR, as it requires setting up a test environment with nodejs, etc.
It would also be good to target Go/WASM in the CI pipeline. Also should probably be a separate PR.

SGTM


Broken link on balena-cli/#os-configure-image

Docs page where broken link appears: https://www.balena.io/docs/reference/balena-cli/#os-configure-image
Sentence containing broken link:
The --system-connection (-c) option can be used to inject NetworkManager connection profiles for additional network interfaces, such as cellular/GSM or additional WiFi or ethernet connections. This option may be passed multiple times in case there are multiple files to inject. See connection profile examples and reference at: https://www.balena.io/docs/reference/OS/network/2.x/ https://developer.gnome.org/NetworkManager/stable/nm-settings.html
Broken url: https://developer.gnome.org/NetworkManager/stable/nm-settings.html

PR generated here https://github.com/balena-io/balena-cli/pull/2235

Closing in favor of https://github.com/balena-io/balena-cli/pull/2235


Debug running Plugin

Hi
How can I breakpoint and debug when ./gradlew runIde - At the moment it just runs the IDE with the plugin installed but I want to debug it and stop on breakpoints etc.
I thought maybe it could be done with the remote debugger but I can't find anywhere to put the jvm args for the remote debugger in the gradle config

If you create a Gradle run configuration within your IntelliJ IDEA project that just runs the runIde Gradle task you can run it in debug mode as usual.

runIde is just a JavaExec task, see documentation to know how to pass arguments there.
It's easier to use IDE for debug, though: https://github.com/JetBrains/gradle-intellij-plugin/issues/9#issuecomment-139237985

ah ok thanks - I  right clicked the runIde task in the gradle side panel in intellij and used the debug option there - I didn't know that existed! thanks again :)


options not available on android ?

Hi,
The plugin works well until i put options.
This code works perfectly
        window.PKVideoThumbnail.createThumbnail (entry.nativeURL, name + '.png',function(prevSucc) {           return prevImageSuccess(prevSucc);         }, fail);
This code does not work.
        window.PKVideoThumbnail.createThumbnail (entry.nativeURL, name + '.png', {resize: {width: 512, height: 384}} ,function(prevSucc) {           return prevImageSuccess(prevSucc);         }, fail);
Maybe, i made a mistake.
Regards

Are you using version 2.x of the plugin?
Can you post any error messages you might be getting? (If you can, see what adb logcat generates as well)
Also, what version of Android are you testing on?

I used a version 1.x.
After an update, it woks well :+1:


Jahstreet kubernetes support initial

Include changes picked from:

[LIVY-702]: Submit Spark apps to Kubernetes #249
[LIVY-703] Show SparkUI link on Livy UI when running on Kubernetes #252

Sorry, it was a mistake


Many crash in TWTRAPIClient

I cannot reproduced the issue, but I got +5k crash reports in this past few hours from our app.
Seems the crash is happened inside of TWTRAPIClient.
- (NSURLRequest *)URLRequestWithMethod:(NSString *)method URLString:(NSString *)URLString parameters:(nullable NSDictionary *)parameters error:(NSError **)error;

My code
private let client: TWTRAPIClient

func friendIds() -> Promise<[String]> {
    Promise { resolver in
        let request = client.urlRequest( // <-- Crashed here
            withMethod: "GET",
            urlString: "https://api.twitter.com/1.1/friends/ids.json",
            parameters: ["stringify_ids": "1"],
            error: nil
        )
        client.sendTwitterRequest(request) { (_, data, error) in
            guard let data = data else {
                let error = error.flatMap {
                    TwitterError(error: $0 as NSError)
                } ?? TwitterError.illegalStateError
                resolver.reject(error)
                return
            }
            do {
                let response = try self.decoder.decode(FriendIdsResponse.self, from: data)
                resolver.fulfill(response.ids)
            } catch {
                resolver.reject(TwitterError(error: error as NSError))
            }
        }
    }
}

Does anyone have same issue?

We have the same issue. 1K crashes in one hour. I will be watching tracking this post and adding any updates from our side 👍

My findings:
TWTRGuestAuthRequestSigner.m#L31
[mutableRequest setValue:session.guestToken forHTTPHeaderField:TWTRGuestTokenHeaderField];

^ From the crash report we can tell that session.guestToken is a NSNumber when it should be an NSString.
Chasing the guestToken through many files, we get to its source: It's retrieved from Twitter's servers which provide a JSON response that's deserialized here:
TWTRAuthenticationProvider.m#L38
json = [NSJSONSerialization JSONObjectWithData:data options:0 error:&jsonError];

Meaning Twitter changed the token it returns from string to number.
The recommended fix would be something like this:
TWTRGuestSession.m#L47
- NSString *guestToken = sessionDictionary[TWTRGuestAuthOAuthTokenKey];
+ NSString *guestToken = nil;
+ id rawToken = sessionDictionary[TWTRGuestAuthOAuthTokenKey];
+ if ([rawToken isKindOfClass:NSNumber.class]) {
+     guestToken = [(NSNumber *)rawToken stringValue];
+ } else {
+     guestToken = (NSString *)rawToken;
+ }

(assuming Twitter's API accepts their token as a string in later requests)
We have not tried/confirmed the fix yet since we cannot reproduce the crash.
If you're able to reproduce it, please give it a try.

I was able to reproduce this using a jailbroken device and modifying (NSURLRequest *)signedURLRequest:(NSURLRequest *)URLRequest session:(TWTRGuestSession *)session at runtime:
%hook TWTRGuestAuthRequestSigner

+(NSURLRequest *)signedURLRequest:(NSURLRequest *)URLRequest session:(TWTRGuestSession *)session {
    NSLog(@"request");
    NSMutableURLRequest *mutableRequest = [URLRequest mutableCopy];

    \\here is where I replaced the guestToken with an NSNumber
    [mutableRequest setValue:[NSNumber numberWithInt: 0123123] forHTTPHeaderField:TWTRGuestTokenHeaderField];

    NSString *appToken = [NSString stringWithFormat:@"Bearer %@", session.accessToken];
    [mutableRequest setValue:appToken forHTTPHeaderField:TWTRAuthorizationHeaderField];
    return mutableRequest;
}
%end

Above is the crash in Xcode. It is exactly the same as I've been seeing in my logs.
It is in fact due to guestToken not being of type NSString since NSNumber doesn't have a length method.

Twitter seems to have fixed their mistake since our crashes have basically stopped.
We still have zero acknowledgment of the issue from Twitter though.

Twitter seems to have fixed their mistake since our crashes have basically stopped.
We still have zero acknowledgment of the issue from Twitter though.

Same in my project. It's stoped about 10 hours ago.


allow to handle error loading and loaded script

Here is a workaround to handle when gtm throw error when loading script and handle when it's loaded.
What do you think about it ?
SImply handle it with window.addEventListener("gtm_loading_error", func) and window.addEventListener("gtm_loaded", func)

@alinemorelli Can we have this PR merged? I also need these changes because sometimes it can fails silently and that causes missing analytics data


Serialization Failure Behavior in Async Daemon

Today we let the projections break on serialization failures, but record "dead letter events" during rebuilds. The question for the future is what do we want to do? @oskardudycz pointed out that our existing behavior is probably backward from what it should be. And either way, we can make it user configurable in both usages.
From Discord:
Hey all, I'm looking hard into the async daemon this week as part of (hopefully) finishing V7. Question for folks, today we potentially stop async projection handling if a projection encounters serialization errors in normal function. But when rebuilding projections, we shove serialization errors off to the side into a "dead letter event queue" so the rebuild won't fail. My question today is "what do we want that to do in the future?"
Jeremy Miller — Today at 10:55 AM
I think the rebuild behavior makes sense, but what about the normal mode? And there's a separate question about how to handle unknown event types, with my thought being that you should have the choice to either ignore or throw.
Oskar Dudycz — Today at 10:57 AM
I think that for rebuild it actually makes sense to stop more than in real usage
In real you want to continue operating, as you always can rebuild it later
When you’re rebuilding then when you faced an error, you can fix the code and restart
Jeremy Miller — Today at 10:58 AM
And next question, take this to a GitHub issue, or leave it here?
And that makes complete sense to me
Oskar Dudycz — Today at 10:58 AM
Sounds like GH issue to me
I think that for both cases it’d be good to make it configurable
Jeremy Miller — Today at 10:58 AM
Yeah, I'd buy that too

In real you want to continue operating, as you always can rebuild it later
When you’re rebuilding then when you faced an error, you can fix the code and restart

👍🏻
(side note: the quoting authors are shuffled around)

"Fixed" in my branch such that serialization errors go to the dead letter events and get skipped when running async, but by default, fail rebuilds immediately


Versioned URL document

Hey @ssibrahimbas ,
Versioned urls document contains this comment line http://localhost:3000/product/v2/123
Can it be like this  http://localhost:3000/v2/product/123 ?

For versioning, the version must be in a subdomain. For example, if there is a versioning for products, it should be products/v1 or products/v2.
But this can be solved with a global router. For example, you can get the result you want with a code like this:
import { createRouter, Request, Response } from "@galatajs/http"

const v2Router = createRouter({ prefix: 'v2', onlyVersion: true })

const productRouter = createRouter({ prefix: 'products' })
v2Router.use(productRouter)

productRouter.get(':id', (req: Request, res: Response) => {
  return res.success(`get product for: #${req.params.id}`)
})

// http://localhost:3000/v2/products/123

@ssibrahimbas  Thank you for your clarification. I will research on this topic.


Iox #751 create unnamed semaphore

Pre-Review Checklist for the PR Author

[ ] Code follows the coding style of CONTRIBUTING.md
[ ] Tests follow the best practice for testing
[ ] Changelog updated in the unreleased section including API breaking changes
[ ] Branch follows the naming format (iox-#123-this-is-a-branch)
[ ] Commits messages are according to this guideline

[ ] Commit messages have the issue ID (iox-#123 commit text)
[ ] Commit messages are signed (git commit -s)
[ ] Commit author matches Eclipse Contributor Agreement (and ECA is signed)

[ ] Update the PR title

Follow the same conventions as for commit messages
Link to the relevant issue

[ ] Relevant issues are linked
[ ] Add sensible notes for the reviewer
[ ] All checks have passed (except task-list-completed)
[ ] Assign PR to reviewer

Notes for Reviewer

Checklist for the PR Reviewer

[ ] Commits are properly organized and messages are according to the guideline
[ ] Code according to our coding style and naming conventions
[ ] Unit tests have been written for new behavior

[ ] Each unit test case has a unique UUID

[ ] Public API changes are documented via doxygen
[ ] Copyright owner are updated in the changed files
[ ] PR title describes the changes

Post-review Checklist for the PR Author

[ ] All open points are addressed and tracked via issues

References

Closes TBD

@elBoberido @FerdinandSpitzschnueffler For the sake of small PR I created this PR without having tests. The implementation is complete, could you please take a look at the overall design and when you agree with it I would add the tests and documentation to the proposed classes.


Exclude copy button from notebook cell numbers

Because of the way nbsphinx renders notebook cells and the way that Sphinx-copybutton targets code blocks, the line numbers next to notebook cells were getting the copy button, as the following screenshot shows:

This PR changes the copy button selector to exclude the notebook cell line numbers.
Note: the default copy button selector is div.highlight pre

As I was about to merge, I thought, that since the change is in docs/conf.py (our documentation site configuration file this will only fix the issue for our docs.
Shall we add a note in our docs aimed at users so they know that if they are using notebooks to generate content like this they have to add this configuration to their own config.py file?

Oh, that's a good catch. Will need to give this a rethink

In the short term, I decided to add a note to the docs for end users.
For the longer term, I will look into filing an issue or pull request with nbsphinx. For our end users, the ideal situation is for things to "just work" so they don't have to do extra config to make nbsphixn and Sphinx-copybutton play nicely together.

Agree! I think this short-term fix should suffice for now but ideally this will be something that just works for users long-term


No flowers

Nadeko Flowers don't work on my server, no matter what I do, everyone has 0.
I tried awarding, I tried winning trivia, and I've looked for ways to set it up, but no results. Pls halp.

You can get free 100 flowers from flower events in the Nadeko support server if you are not there already. At the moment this is the only way to get free flowers. Type -h in server where you have Nadeko or in Nadeko bot DM to get the invite link to there.


[CR] Add ShareLaTeX provider

Hello,
we're developing a provider for ShareLaTeX (www.sharelatex.com) and have copied the code from s3, made the needed changes, and got it working for serving the project list and folder strutcture of a project for OSF using the code in this pull request plus the code on this link for the osf side: https://github.com/CenterForOpenScience/osf.io/compare/develop...danielneis:sharelatex
We have some doubts about the automated tests.
Since the strutuct of each plugin is somewhat different we would like to get some advices before assuming an approach or another.
What are the minimum requirements for testing a new provider?
We look at several of the tests files and found that the figshare (https://github.com/rafaeldelucena/waterbutler/blob/add-sharelatex/tests/providers/figshare/test_provider.py) may be the best start point, is it ok to follow that code style for tests?
Kind regards,
Daniel

@danielneis sorry, I did not see this until just now.
All the provider tests should be in approximately the same style.
Any of them would be fine to pull style from.
From my quick look over, everything looks great.
I have a couple comments that I'll add as line comments.
Please let me know if there's anything I can do to help out :+1:

Hello, @chrisseto
we've done a lot of progress on tests and other things.
Would you please take another look at the current state of the code?
Kind regards,
Daniel

Hey @danielneis,
I'll be following up on this, but I have a couple of other providers to CR first.  I'll see if I can get to it next week.  Thanks for your effort on this!
Cheers,
Fitz

hello @felliott
would be nice to have your review on that =)
kind regards,
daniel

Hey @danielneis,
Sorry for the long delay, I'll start looking at this today.  IIRC, last time I looked at this, sharelatex.com didn't yet provide API keys and I needed to run a local copy of sharelatex.  Is that still the case?
Also, as a heads up, WB is undergoing a bunch of code churn at the moment.  We're trying to add throttling to our requests and there's a conversion to Python 3.5 that we want to get merged in the near future.  The 3.5 conversion will probably affect you the most, but it should mostly be a matter of syntax updates.  yield from will become await, and the @asyncio.coroutine decorator will be replaced by async def.   The current work is in the feature/python-3.5 branch.  Please let me know if you have any questions!
Cheers,
@felliott

The code looks pretty good, but I'd like to run it locally before doing anything.  Can you ping me when you fix this issue on the OSF side?  Thank you!

Does ShareLaTeX have a concept of folders?  And will this be a read-only provider (at least for now)?

Also, are there docs describing the structure of the API in your web-sharelatex API PR?  Something like http://waterbutler.readthedocs.org/en/latest/api.html?

@danielneis, I'm pausing this CR for now.  The WB code looks pretty good!  This and @kwierman's Dryad provider might have some overlap since they're both currently read-only providers.  I'll be reviewing his tomorrow, so I might have some more feedback for you.  In the meantime, can you update this PR for the feature/python-3.5 branch, and address my comments on the OSF PR and the web-sharelatex PR?  Again, I'm sorry it's taken so long to get to these.  I'll be on the Slack channel regularly if you have any questions.
Cheers,
@felliott

@felliott  thanks for your review!
I've talked to the other guys on my team and tomorrow we'll work on the issues you raised.
kind regards,
daniel

Closing this, as ShareLaTex lacks the pieces needed to integrate.  But the code shall live on in the feature/sharelatex-integration branch.


fix path joining

path.join shouldn't have any separators in the strings

Don't know why I didn't catch this before...


Change to br2

Hi,
This change is related to https://github.com/Tiago-Harmonic/tiago_harmonic/pull/1, and is a change to use a custom world package
Best

Sorry, this PR was not here


Crash on Effort plugin

I noticed a crash in the Effort plugin (indigo) :
[ WARN] [1432914059.915302803]: Message from [/lwr_sim/joint_state_publisher] has a non-fully-qualified frame_id [world]. Resolved locally to [world].  This is will likely not work in multi-robot systems.  This message will only print once.

Program received signal SIGSEGV, Segmentation fault.
0x00007fff9829ccc7 in rviz::EffortVisual::EffortVisual(Ogre::SceneManager*, Ogre::SceneNode*, boost::shared_ptr<urdf::Model>) ()
   from /opt/ros/indigo/lib/libdefault_plugin.so

It's when I select a valid joint state topic with a wrong Robot Description value :

Joint States topic is /lwr/joint_states
Robot description is at /lwr/robot_description (not at /robot_description)

This order cause the crash. Seems like boost::shared_ptrurdf::Model is null.
If I first input the correct Robot Description (/lwr/robot_description), then I select the joint state topic, it's working fine.

The naive thing to do would be to check the state of the model before trying to use it here:
https://github.com/ros-visualization/rviz/blob/indigo-devel/src/rviz/default_plugin/effort_visual.cpp#L34
But the real issue maybe that the urdf_model should never be null.


Fixes issues with Alerts and Status

@bipuladh LGTM
can u squash the commits ?
also, there is a lint warning (introduced by one of my PRs) for TopologyNavigation.tsx, can u plz pass the controller to the dependency list as well ?

LGTM
cc @alfonsomthd (for further reviews)

/lgtm

/cherrypick release-4.13

/cherrypick release-4.13-compatibility

/reopen


Navbar Is Transparent On Mobile Devices

Describe the bug
Navbar is Transparent In Sign Up page . Can't see options.
To Reproduce
Steps to reproduce the behavior:

Go to 'https://igboapi.com/'
Switch To Mobile View. e.g Pixel 5
Click on 'Get an API Key' you will redirected to "https://igboapi.com/signup"
Open Navbar
See Issue

Screenshots

Expected behavior

check in the source code, and set the text-color

I just viewed the web view and if you noticed the text-color is set to white, just change it to any color of you choice but not white
or
you set the media screen in css and @mediascreen mobile screen size, set the color to maybe green, or your preferred color

Hello @ijemmao I'd love to work on this issue.
I've forked the repo and cloned it too. While running yarn build, I run into an error that I can't seem to get past. Can I get some community support to help resolve that? Thanks.
Here is the yarn build error faced:
failing command
shx cp -r ./src/dictionaries/ig-en ./dist/dictionaries/ig-en && shx cp -r ./src/dictionaries/en-ig ./dist/dictionaries/en-ig
error
cp: cannot create directory './dist/dictionaries/ig-en': No such file or directory

@pauluzo thanks for taking this on ✨ this is definitely not the solution, but can you create a directory called dist in the top level of the project directory and then run the build command again?
Let me know if that works or not so I can update either our getting started docs or our build scripts

@ijemmao thanks for having me on. I tried your solution, but still got the same error. I'm highlighting some of the things I noticed:

The build command deletes any current dist folder (the one I created) and then creates another one during the build process.
I watched the dist folder during the build process and realized that new files/folders were being copied into the folder successfully before that particular command failed
The two previous commands that ran successfully are: shx cp -r ./src/pages/assets/ ./dist/assets and shx cp -r ./src/public/fonts/ ./dist/fonts so it seems that the issue with this command is because the ./dist folder does not have a "dictionaries" subfolder yet, so second level copying is not working, while first level copying seems to have no issue. (not certain about this).

@pauluzo that's an interesting bug since I thought I thought I fixed it and this error doesn't occur in our CI pipeline. Just to confirm, what OS are you using?

@ijemmao my PC runs on a windows 10

yeah, i believe there's an npm script that doesn't run well on windows - you can create a separate bug ticket so another person can help fix it!

Hi @ijemmao, is this issue already assigned or can I jump on it?

@Ebugo it's been assigned to you! feel free to ask questions

@ijemmao Okay, will dive right in.. I'll def reach out if I encounter a blocker, thanks.


Add automatically generated change log file.

Hi. As I can see, you are careffuly fill tags and labels for issues in your repo.
I created a github_changelog_generator, that generate change log file based on tags, issues and merged pull requests (and split them to separate lists according labels) from GitHub issue tracker.
This Change Log was automatically generated by this script.
It helps to easily found what and when was fixed and implemented.
You can easily update this file by running gem: github_changelog_generator Mozharovsky/CVCalendar
I hope you find this commit as useful.

Hello @skywinder,
Your software is really nice. I was thinking of keeping all changes and with Changelog Generator it's going to be very easy.
I'll merge this pull request once a new release comes out into master branch.
Regards,
Eugene

I accidentally delete the PR's branch. I can create another PR's or you can run this script locally by yourself, and get up-to-date version of changelog whenever you want.