We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is it possible somehow to sort based on the number of lines taken up by children of a given key?
For example, this:
c: foo b: x: foo z: bar y: baz a: - foo: bar - bar: foo
would sort as:
c: foo a: - bar: foo - foo: bar b: x: foo y: baz z: bar
Although not shown here, it'd be helpful if this was supported recursively too.
The use case for this is to avoid putting small keys/values after large, extensively indented ones, like this:
apiVersion: batch/v1beta1 kind: CronJob metadata: name: some-cron namespace: my-namespace spec: concurrencyPolicy: Forbid failedJobsHistoryLimit: 1 jobTemplate: metadata: creationTimestamp: null spec: backoffLimit: 3 template: metadata: creationTimestamp: null spec: containers: - name: somecron image: some/image:1.2.3 imagePullPolicy: IfNotPresent args: - echo command: - Foo env: - name: ENVIRONMENT value: my_env - name: ALLOWED_HOST value: some.host.com resources: limits: cpu: 1 memory: 500M requests: cpu: 1 memory: 500M terminationMessagePath: /dev/termination-log terminationMessagePolicy: File dnsPolicy: ClusterFirst imagePullSecrets: - name: mysecrets restartPolicy: OnFailure schedulerName: default-scheduler terminationGracePeriodSeconds: 30 schedule: 10 * * * * # These keys should be moved above the huge 'jobTemplate' tree successfulJobsHistoryLimit: 3 suspend: false
The text was updated successfully, but these errors were encountered:
No branches or pull requests
Is it possible somehow to sort based on the number of lines taken up by children of a given key?
For example, this:
would sort as:
Although not shown here, it'd be helpful if this was supported recursively too.
The use case for this is to avoid putting small keys/values after large, extensively indented ones, like this:
The text was updated successfully, but these errors were encountered: