Closed thomasjm closed 2 months ago
Hi @thomasjm. Thanks for your PR.
I'm waiting for a kubernetes-client member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test
on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test
label.
I understand the commands that are listed here.
Is anyone going to merge this?
I'm thinking about just publishing it on Hackage myself.
/approve /lgtm
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: jonschoning, thomasjm
The full list of commands accepted by this bot can be found here.
The pull request process is described here
/lgtm
@thomasjm: The following test failed, say /retest
to rerun all failed tests or /retest-required
to rerun all mandatory failed tests:
Test name | Commit | Details | Required | Rerun command |
---|---|---|---|---|
kubernetes-clients-haskell-unit-tests | a747f6fdc62d34c684709740422497d3c088f8d9 | link | false | /test kubernetes-clients-haskell-unit-tests |
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.
I'm thinking about just publishing it on Hackage myself.
I don't have access to the hackage repo, I think that's @akshaymankar
I noticed that when trying to use certain Kubernetes endpoints with this library (such as DELETE of a
Service
), the response would fail to parse.Looking into it, I found it's because
kubernetes-client-core
is currently generated against K8S release 1.20, which is rather old at this point. The K8S API is pretty stable, but not stable enough that such an old version will work flawlessly against a newer cluster (mine is 1.27).So, I decided to generate
kubernetes-client-core
for all versions from 1.20 through 1.30. These are now stored in the folders./kubernetes-1.xx
. I think it would be nice to publish all of these to Hackage using their version numbers, but for now it's easy to use in astack.yaml
like this:I also:
generate_all.sh
and it will generate all the versions, using Nix to obtain a pinned version of thegen
repo. This step formerly needed to be done by hand. Adding a new K8S version in the future should be a 1-line change.swagger.json
andopenapi.yaml
to.gitignore
, as these are only needed at generation time and not to use the library.I think the results are good. You can now easily choose the version of the K8S API you want to target. And a git clone is still plenty fast, with each autogenerated folder only contributing around 6MB uncompressed.
CC @jonschoning @akshaymankar @guoshimin