Proposal: Allow templating in values.yaml

Hello Helm Team,
I would like to propose adding limited template rendering capabilities to the values.yaml file. I believe this would be a valuable feature for interacting with subcharts.
For example, lets say I am defining a Chart for a web application deployment and it has a simple values file as such:
image:
    repository: xyz
    tag: latest
    pullPolicy: Always
port: 80

And then I wanted to bundle this service alongside the nginx-ingress controller, so I add the dependency and a few settings, including one which tells the kubernetes-incubator/external-dns controller how to route traffic to the nginx service:
image:
    repository: xyz
    tag: latest
    pullPolicy: Always
port: 80

nginx-ingress:
    enabled: true
    controller:
        service:
            annotations:
                external-dns.alpha.kubernetes.io/hostname: {{ .Release.Name }}.example.com

As it stands today, this is impossible to accomplish automatically. A user is required to helm upgrade <release-name> chart-name --set nginx-ingress.controller.service.annotations.external-dns.alpha.kubernetes.io/hostname=<release-name>.example.com after the initial installation because the release name is not accessible at installation as a top-level variable.
In my mind the variables available at this level would be extremely limited, but include some of the common variables in .Chart and .Release
I would be happy to participate in adding this functionality to helm should the proposal be accepted.

Are you proposing interpolating the literal values from this hypothetical values.yaml file into the chart's templates, and then interpolating those whole templates again to expand the release name (to use your example), or do you imagine interpolating the values.yaml file first, and then treating its expanded form as the input for interpolating the rest of the chart's templates?

This has been discussed at length before, and for a variety of technical reasons it is problematic. But a far less problematic solution would be to support expansion of things that look and behave like environment variables.
So, for example, you'd be able to do myval: ${RELEASE_NAME}.foo.bar in your values.yaml.
On the Golang side, it should be as simple as calling os.Exand() with a custom list of variables that should be expanded.
To @seh's point, it is a little tricky to decide when you want to run the expansion. I would think you'd want to do it after the values are coalesced, but before the values are sent into the template engine. That would bring with it the caveat that variables would have to be represented as well-formed YAML. But I think that is workable

@seh I personally imagined it as something closer to the first option, wherein the literal values are placed into the template before rendering.
@technosophos given that, I think what you are suggesting sounds like a good solution.

One challenge with systems that work like this is that simple interpolation is often not enough. The replacement value has to come in as a lexically valid replacement, which then leads to wanting some functions available transform the supplied value into something suitable.
I'm not arguing against the idea just yet; we just need to be suspicious that the simple substitutions to which @technosophos alluded above will turn out to be enough.

But if it is coming in through the values.yaml file, the transformation and validation can still happen in the templates, right? For example: myPort: ${port} can still be accessed in the template like this: {{ .myPort | int }}.
The bigger constraint is that the values.yaml file MUST always be a valid YAML file.

It's that constraint I had in mind: What happens if the "port" variable holds the value

"a

or some other sequence that makes for invalid YAML? As you said, there are syntactic constraints to keep in mind, though one can work around them:
myport: '${port}'

Right, so the values would have to be escaped or quoted in some way, eg in values.yaml:
portValue: "{{ .myPort | int }}"

Based on the cases where I have wanted this so far, I suspect full templating is required, not just simple interpolation.
The idea of interpolating the literal values from values.yaml into the templates, and then interpolating the templates again in case the literal values were actually templates is interesting, but seems like it would be dependent on how the templates are written. e.g. this isn't going to work as expected:
values.yaml:
otherServiceName: "{{ .Release.Name }}-my-service"

deployment.yaml
otherService: {{ .Values.otherServiceName | lower }}

Are there problems with interpolating values.yaml first (obviously without access to .Values) and then using the resulting values.yaml to interpolate the other templates?

@braedon Yes, there are several problems:

The values.yaml file MUST be valid YAML in its unparsed state. This places interesting limitations on template directives.
Values are merged in stages, and some stages do not have access to the template subsystem (namely, --set resolution, requirements.yaml constraints, and -f merge operations.)
All values must be computed before certain parts of the template system can be initialized. Otherwise, {{ define }} and {{ include }} do not work predictably, and {{ template }} doesn't either.

Essentially, an env var syntax is easy enough to embed in values.yaml that we could do it without introducing much complexity. But using full-fledged templates is a major undertaking, and even if successful it would result in an interminable series of bug reports filed when people hit the edge cases.
But I must be missing something... I don't understand your example above. What is being proposed is:
values.yaml
otherServiceName: "${RELEASE_NAME}-my-service"

deployment.yaml
otherService: {{ .Values.otherServiceName | lower }}

The order of operations would have values.yaml rendered after the Release object is created, but before the templates are compiled or rendered. If the Release name is FOO, the outcome of the above would be otherService: foo-my-service.

@technosophos I was envisioning running the templating engine on the values.yaml files before any other parsing/coalescing/etc. of the files was done (if this feature doesn't make it, I've considered running a separate templating system to generate the values.yaml files to then pass into Helm).
It seems like that should avoid issues 1 and 2, and be a pretty intuitive system to grok? I have no idea how hard that is to implement in Helm's codebase, however, and 3 would still be an issue (not sure how limiting disallowing those functions would be?).
My examples were in reference to the solution @seh and @benjigoldberg were discussing, rather than your proposal.
In their proposal (assuming I understood it correctly) my example would result in this after the first pass:
otherService: {{ .release.name }}-my-service

(i.e. the raw value of otherServiceName from values.yaml would be passed to deployment.yaml, and lowercased)
Which then wouldn't run as intended on the second pass.

What I was thinking is:
If a /templates/values.yaml file exists, then the logic is to read variables from /values.yaml to render the template, and then the rendered values.yaml takes over completely, before all other templates are rendered. In other words, /values.yaml bootstraps the template.

I have also run into a use case that I think would benefit from this. I suspect it might be similar to @braedon's otherService example.
The problem I am running into is that it's currently not possible to include the .Release.Name when overriding a service's name via values.yaml. The use case for this is when building completely decoupled charts that can then be wired together using a parent chart.
For example, an elasticsearch chart could have a serviceNameOverride value in its values.yaml file that would allow the user to override the service name. Similarly, a kibana chart could have an elasticsearch.host value in its values.yaml file that the user can use to set the location of the elasticsearch cluster. These charts know nothing about each other's implementation details. They are independent and would allow a user to, for example, deploy kibana to monitor an existing elasticsearch cluster that was not deployed with helm.
Ideally, these independent charts can also be used as building blocks for creating a parent "elasticsearch-kibana" chart that "wires" them together via subcharts. The parent chart would connect the services together by setting the following in values.yaml:
elasticsearch.serviceNameOverride: {{ .Release.Name }}-elasticsearch
kibana.elasticsearch.host: {{ .Release.Name }}-elasticsearch

Currently it's possible to do this without including the {{ .Release.Name }} in the values, but it's inconvenient as it would prevent the user from installing multiple "parent" charts in the same namespace without changing the values file for each installation.

@alexbrand You could use the tpl function to render values that contain variables:
values.yaml
elasticsearch.serviceNameOverride: {{ .Release.Name }}-elasticsearch
kibana.elasticsearch.host: {{ .Release.Name }}-elasticsearch

template.yaml:
name: {{.Values.elasticsearch.serviceNameOverride | quote | tpl }}

@eicnix To do that requires having control of the template.yaml in the subchart, and wanting to explicitly add support for this wherever it is required.
What I'm after is a way to write parent charts that do this kind of thing while treating the subcharts as black boxes. I think that's what @alexbrand was saying as well?

Someone above has already referred to the tpl function that was fairly recently added. I may be misunderstanding some complexities that are involved here, but for my use case and some others described above, all that seems to be required is an implicit pass over values evaluating them via tpl or equivalent, prior to rendering templates. (I guess you would potentially need to keep doing passes until no changes are made, to cope with recursive references.) I suppose you might want to require this to be enabled via, say, an --expand-values argument on the command line, but is there any other issue with such a solution?

@eicnix Thanks for the suggestion!
I was unable to get the pipeline in template.yaml working but the below workerd for me (with values.yaml above):
template.yaml
name: {{ tpl .Values.elasticsearch.serviceNameOverride . }}

I think that this and #2133 are the same issue, BTW. (Not sure which one is best to keep open though.)

We seem to be OK in 2.6.1 of Helm server (but not in 2.3.0)

@obriensystems can you elaborate on that thought just a bit more? :)
What seems to be OK about this proposal for v2.6 but not in v2.3? Perhaps you are referring to another ticket?

I like the approach proposed by @travishaagen and @braedon . I could also imagine using multiple -f values.yaml arguments, e.g.

helm install -f raw_values.yaml -tf values_rendered_with_templating.yaml ...

First it would read raw_values.yaml which would have to be valid yaml. Then helm would read values_rendered_with_templating.yaml and run this through the template engine which has access to the variables in raw_values.yaml. The rendered template is then fed to the next stage and so on.
I've used tf in the command line above to signal that it's a values file that should be rendered with templates before being used. The file structure proposed by @travishaagen would be the default setup.
This issue along with #2399 are quite big blockers that really affect composing parent charts from child charts. As things are right now, helm does not allow composition of charts for anything non-trivial. I wonder if there is a better solution for composing charts that would solve the issue at hand as well as #2399.

/remove-lifecycle stale

I guess we don't necessarily complicate helm to do this. For example, a simple tool like https://github.com/roboll/helmfile can be used for templating in values.

@mumoshu I ran into a couple of cases where I'd need access to the release name in values.yaml (most recently the Kafka chart which can be set up not to use the Zookeeper Chart as a requirement, but then needs a Zookeeper location as a Value, which in our deployments is based on the release name...). I'd however like not to require yet some extra tooling and enforce it on our users to achieve this :smile:

@NicolasT Thanks for sharing your use-case 👍
You may already know but for anyone not there yet - you can name your Zookeeper release a concrete name by helm install incubator/zookeeper --name myzookeeper and then reuse that name as a value of Kafka release.
And your use-case doesn't seem to be supported by solutions suggested in this thread. Sry if I'm not following you, but you can't access another release's name from an another, independent release, right?
Yours seems to be more about "extending what can be referenced from templates" rather than "allow templating in values".

I'd however like not to require yet some extra tooling and enforce it on our users to achieve this 😄

I can't agree more 😄
An all-in-one tool to support everyone's use-cases would really a godsend.
Actually, I once wished if helm could integrate with a declarative workflow manager with dynamic service dependency resolution(your use case) feature like atlassian/smith.
Imagine an integrated solution of Helm CRD + Smith - would hopefully elegantly solve your issue?
However, on the other hand, I feel like that integrating/implementing a serious workflow engine like that into a tool for other purposes would be nightmare in regard to maintenance.
So, I rather wish helm core to remain simple and the helm plugin system is extended somehow to support an extension point like "values transformer" which is able to modify values.yaml before passed from one to another. Hmm, that sounds like almost smith though!

My primary use case is #2506. In the general case, I need a parent chart to be able to pass its own values down to a subchart without having to know those values at package time.

But why not let helm generate a default random value ?

Hi! How would you like to achieve that?
For me, templating in values.yaml doesn't seem to solve it. What if you had an IMAGINARY values.yaml like:
ui_secret: "{{ randAlpha 8 }}"

and you run helm upgrade --install yourrelease yourchart -f values.yaml multiple times?
For me, there seems no way for helm/tiller when to do/dont generate the ui_secret.
So, I believe you should just provide a pregenerated secret via --set like you noted, regardless of this proposal is accepted or not.
Instead, would it be possible for you to just generate a random value inside a k8s secret?
So that all the pods created via your helm chart could refer the secret by its name.

@mumoshu for the upgrade scenario:

if ui_secret is set in values.yaml, then no impact;
else helm should retrieve existing values.yaml from somewhere (probably Tiller), then merge this existing values.yaml with the '-f values.yaml'

helm should be self-contained for generating random salt/password/ca_certificate/certificate_pair, and do not requires the end user to generate outside helm. This provides much better usability.
"generate a random value inside a k8s secret" is doable, but not straightforward comparing to 'ui_secret: {{ randAlpha 8 }}'

else helm should retrieve existing values.yaml from somewhere (probably Tiller), then merge this existing values.yaml with the '-f values.yaml'

Not really offending but it seems to introduce more edge cases.
How would helm/tiller differentiate the value is already set or not, and when to override if from --set or -f values.yaml or not, given your values.yaml always contain ui_secret: {{ randAlpha 8 }}?

"generate a random value inside a k8s secret" is doable, but not straightforward comparing to 'ui_secret: {{ randAlpha 8 }}'

Agree. But anyway, templating doesn't seem to be a solution for me.
You'd need a workflow engine like https://github.com/atlassian/smith to deal with service dependencies(with ability to pass values to be consumed by consequtive, dependent helm installs).
I guess you can submit a feature request to helm for supporting this use-case(workflow engine, service dependency management). However, I don't know whether that's feasible in scope of helm/tiller.

when installing the chart, '--set' > '-f values.yaml' > values.yaml in the chart
when upgrading the chart, '--set' > '-f values.yaml' > generated values.yaml for the installed chart
What I proposed is implemented in BOSH https://bosh.io/docs/variable-types.html. BOSH supports explicit variable type definition, while values.yaml in helm chart supports plain yaml. So it would be great to support template function in values.yaml, e.g. 'ui_secret: {{ randAlpha 8 }}'.

While this would provide better usability for some users it would also bloat up helm.
My recommendation of dealing with any kind of secrets in combination in helm is to manage them in a secret storage(kube secrets, vault, etc.) and just reference them from the chart.

What I proposed is implemented in BOSH https://bosh.io/docs/variable-types.html. BOSH supports explicit variable type definition, while values.yaml in helm chart supports plain yaml

I've reviewed Bosh's documentation about Variable Interpolation. It turns out to me that Bosh doesn't support both (1) populating variables from outputs of your k8s objects created by helm/tiller, and (2) generating a persistent value via template. See the notion of -v internal_ip=<IP_ADDRESS> in https://bosh.io/docs/cli-int.html.
Even Bosh doesn't seem to support your use-case out of box.
Then, my best guess is still that you need something like a workflow engine as I've explained previously.
Or am I still missing something..?

@johngmyers Hi! Sorry to say but your use-case seems to be not supported by templating alone.
Not only templating, helm/tiller also needs to manage coordination of charts and its releases, out/in propagations from precedent release(s) to dependent chart(s).
AFAICS, what's not helm/tiller is currentlyaware of. Doing it in the scope of helm/tiller would considerably bloat up it, as @eicnix pointed out.
To separate discussions, I can suggest you to submit a another issue. But on the other hand, honestly, I don't have a feasible way to implement it inside helm/tiller without bloating it.
So your best bet would be investigating into an another workflow engine like atlassian/smith(i'm not paid by authors of smith. please tell me if there's any alternative 😉) + probably upcoming helm CRD.

@mumoshu I believe my use case is adequately described by #2506. I don't see how submitting another issue helps.
I don't see how templating values.yaml doesn't handle my use case. Helm supports subcharts, which are coordinated by either requirements.yaml or embedding the subchart in the charts directory. The parent chart could pass down the value with something like:
subchart:
  serviceName: {{.Chart.Name}}
  serviceVersion: {{.Chart.AppVersion}}

Of course, templating values.yaml isn't the only way to implement allowing a chart to pass values not known at package time to a subchart. But if it's "bloating" Helm, then adding pretty much any feature would be "bloating" Helm.

Maybe we can add a limited value rendering before the templating process. I would only allow access to .Chart and .Release in order to avoid for example cyclic references between values. But this would still solve a lot of usecases where people want to reference the release or chart instance from the values.

I have a use case where I need a parent chart to pass down a value sourced from its .Values. This allows separation of concerns into subcharts without the parent exposing the fact that it is implemented using a subchart.
For example, we would have a "platform" subchart which encapsulates common stuff needed by services implemented in our inner platform library. It would want to have a value "platform.oauthClient" which the service chart would pass in to indicate whether the service needs to be configured to be an OAuth client. The implementation of that might be to pass that .Values.oauthClient down to a subchart of the "platform" subchart. In the future we might want to change that implementation of that feature of the "platform" chart to something else.

The templated values might want to live somewhere other than the top-level values.yaml so that they don't appear to be part of the parent chart's external API. That could also address the cyclic references issue.

@johngmyers The parent chart values should also be available in the child chart. I believe the method I proposed earlier would also solve your issue. You could create a templated value in the parent chart like you described in earlier and let it be passed to the child chart.

FYI, my PR that's already associated (ie. #3252) implements this feature and I think probably satisfies these various use cases. We have been using it internally for a while, and passing parent values to child charts is one of the problems we solve with it.
The PR hasn't made much progress so far. Any feedback, either on the PR itself or from trying out the feature in a build, is obviously very welcome.

@eicnix The Helm documentation states:

But lower level charts cannot access things in parent charts, so MySQL will not be able to access the title property. Nor, for that matter, can it access apache.port.

so that doesn't seem possible.

@johngmyers Child charts cannot access parent values but the parent chart can pass values to the child chart. Assuming you have a child chart called mychild you can pass to it values from the parent values.yaml this way:
mychild:
  overridenValue: true

Does Helm Team be aware of this issue/proposal?  It was created on May 25, 2017, 10 month ago. There has been a lot of discussion here, and several duplicated/similar issues created.
This issue is not assigned to anyone yet.
We're seeing comments 'it will bloat up helm'. So which solution does not bloat up?  Could Helm Team provides a plan and ETA for this proposal and at least give a reasonable workaround/solution ?
Seems the PR https://github.com/kubernetes/helm/pull/3252 can support templating in values.yml. If Helm Team thinks so, please speed up on merging it.
Thanks.

@mparry's solution in https://github.com/kubernetes/helm/pull/3252 seems to handle my use case elegantly. It'd be amazing if it could be merged!

It doesn't look like the pull request related to this issue has been accepted yet, but I've just published a package that takes away the pain points I was seeing that led me to this issue. It's called Mercator and can be found here. I know it doesn't fit all these use cases, but hopefully someone might find it useful!

/remove-lifecycle stale

@johngmyers Did you ever find a good solution for https://github.com/helm/helm/issues/2492#issuecomment-370895073?  I'm running into the same encapsulation issue.  I really would like to avoid writing a wrapper for helm to recursively pre-render my templated values into the values.yaml files.

I do not have a good solution. I have a workaround which uses a private build of Helm with #3471 applied, allowing me to (redundantly) pass parent chart name and version to subcharts.
This and the poor merge support are basically blocking me from doing any reasonable encapsulation. I'm hoping Helm 2's use of LUA will help with this issue.

For various technical and design reasons behind how Tiller's template rendering engine works, we do not intend to support pre-processing values.yaml as a Go template for either Helm 2 or Helm 3. However, we highly encourage the community to write wrappers or Helm plugins that support this feature for their use case! One such example we've heard from users is gomplate, but we'd love to see other pre-processors that can provide this functionality prior to running helm install.
To re-iterate a previous comment in this thread: adding support for expanding environment variables in values.yaml would be an easy problem to tackle without introducing much complexity to the rendering engine, but using full-fledged templates would be a major undertaking.
Even if we were able to support this feature, it would result in a sizable increase of bug reports filed when people eventually hit the edge cases. Given the current volume size of the issue queue and the limited number of maintainers and community members chipping in to help weigh in on issues, we simply do not have the human resources to support this undertaking.
We apologize for the inconvenience, and thank you for understanding!

@bacongobbler -- I originally opened this issue before I think I actually fully understood how to effectively use helm in my workflow. I completely agree with the decision to close the ticket. I left it open primarily because there ended up being a good amount of community discussion on the issue. In the time since I opened this ticket and I learned more "standard" workflows, I dont actually think I've ever found myself wanting for this particular feature. So, in any case, 👍

@nuwang in that type of scenario we would typically use a top level umbrella chart as you have described, create a secret at the top level, and then have each of the child charts use that secret to access the credential. Hopefully that helps -- its also possible I misunderstood your description. Let me know!

@dtshepherd we've definitely run into those issues -- in those scenarios we've forked the helm charts repo and contributed the option back upstream and then used our own forked chart until the change is merged (then we migrate back to the main repo's chart). There are moving parts, but these days it doesn't happen that much anymore. The main charts repo has matured quite a bit and a lot of charts have this flexibility out of the box.

Yes, but most 3rd party charts templates things just fine. However, if i have a wrapper chart to encapsulate those 3rd party charts, I can’t normalize on some common variable without putting tpl in the 3rd party charts.

@dtshepherd you can control the name of the variable/secret from that top level values file and then push it down to the subcharts, right?

In the Elasticsearch/Kibana case, the service name is derived from the release name. But it's not equal to the release name. Can someone suggest how to pass the resulting service name to Kibana just using variable renaming?

@benjigoldberg Yes, but that breaks encapsulation since the top level chart will need to know the variable names in the 3rd party chart. The chart in the middle should be the abstraction layer, but can’t be without templated values.yaml file.

@benjigoldberg Thanks for reply. The reason that we could not use a secret, is because the secret name must be passed to the subcharts as a single variable. However, since the values file doesn't support templating, you have to pass a hard-coded, global name, without the release name prefixed to it (since the release name is a variable, naturally, that needs to be templated). This means that you can only have a single instance of the chart installed per namespace, which is an unacceptable restriction for us. That pretty much eliminates the use of secrets as an option, and we fall back into the trap of having to modify a third party chart that we do not control, or individually passing in the password three times in our case, fully exposing the implementation details of the umbrella chart.
So one way or the other, this either breaks encapsulation, breaks unique releases, breaks DRY, and often, a combination of all of the above.
A few more we ran into that come to my mind:

Persistent volume claims that need to be shared among multiple subcharts, but must also support multiple releases.
A shared variable that a user provides, which needs to be pushed to several subcharts.

This inability of Helm to encapsulate is a major pain point for us. Just the other week I warned a large cloud services company off of Helm over this issue.
This ticket is a bit overconstrained. The requirement is to permit a parent chart to pass a value to a subchart where the value is not known at package time, but derived from the parent chart's own .Value, .Chart, and/or .Release. I believe templating is required, but it does not have to be in values.yaml.
My proposal above of a templates/_values.yaml might be one way to achieve this without the edge conditions and complexity of #2133. The maintainers have stated they will not support templating of values.yaml, but it is unclear whether they would consider such an alternative values templating proposal.

There has been a lot of good comments around this issue. I wanted to provide some more clarity around this decision and try to amalgamate all of the information that is spread across various issues and PRs. First off, I completely get that this would solve some painful use cases. Not only am I a maintainer of Helm, but I write a lot of charts and have run into this problem before. However, there are several big reasons we do not want to implement this:
The tl;dr
At its most simple, the reason behind not wanting to do this is you don’t template the file that provides the values that you template with. Furthermore, this feature will be made obsolete by Helm 3
Rendering order and logic
If you template the file you provide values with, it introduces a large amount of complexity in rendering order, circular value dependencies, and logic bugs/failures. When you start adding full logic blocks to values, that is yet another point of failure when trying to render a manifest. This makes things much harder to debug and diagnose (hence the comment about the number of bugs it would produce). It also makes the templates harder to write because you have to account for the variability that a templated values file introduces
Backwards compatibility
Templating values files introduces non-YAML syntax into a YAML file. This is likely to break existing templating solutions that generate values.yaml. Speaking from experience, I have used  generated values files where having non-YAML in the file would have broken our workflow. Given that many people already have tooling around Helm values, this would make a templated values file a backward compatibility break. I’ll admit we haven’t been perfect with maintaining backward compatibility, but for the most part we have done a decent job at maintaining it, and a feature such as this would most definitely break existing workflows
Language complexity
A templated values file will require a custom dialect of go-templates because the YAML itself cannot be a template when it is passed as part of the release. This also introduces the complexity of creating a specialized context to evaluate the template before other steps.
Obsolete by Helm 3
In Helm 3 as part of the eventing/hook system, we will allow Lua-based modification of values in a much easier way than having to template them out. Seeing as we are well underway with development for Helm 3, adding a feature with all of the drawbacks mentioned above would cause more churn than the value added. So we aren’t rejecting this outright, but are implementing it (albeit in a different way) for Helm 3
Hopefully this clarifies it some more for everyone!

Thanks for the detailed clarification @thomastaylor312 , that clears up this decision a lot better.
In any case, I think the core issue is one of separating the external interface of a chart, from its internal implementation details. That would appear to require some simple mechanism to separate what the chart exposes as the external values file, from how those values are transformed and distributed to third-party subcharts, even in Helm 3. Lua event hooks may well be the answer, or perhaps that will be too complicated for what should perhaps be an innate feature, but it's hard to evaluate that from my position of ignorance.  So please consider this a feature request for Helm 3 and thanks for all the hard work that's going into Helm - it's a pleasure to use!
xref: https://github.com/helm/community/blob/master/helm-v3/002-events.md

Thanks for the great feedback @nuwang! We'll make sure to take that into account with all of the Helm 3 work

Here is a workaround for this.
Just writing some template expression in values.yaml as plain yaml string.
like.
helloworld: Hello World!!
sometemplate: '{{ .Values.helloworld }}'

And using tpl to evaluate sometemplate in the template file.
{{ $global := . }}
{{ tpl (trimAll "\"'" .Values.sometemplate) $global }}

The output will be

Hello World!

@wpc009 yes, that works, the only inconvenience is that tpl evaluates the string only once which is not a bad thing but something what you sould keep in mind:
publicHost: "{{ .Release.Name }}-{{ .Release.Namespace }}-paymentgw.{{ .Values.global.publicDomain }}"
callbackUrl: "{{ .Values.global.publicDomainSchema }}://{{ .Release.Name }}-{{ .Release.Namespace }}-paymentgw.{{ .Values.global.publicDomain }}/validate" # this will work
# callbackUrl: "{{ .Values.global.publicDomainSchema }}://{{ paymentgw.publicHost }}/validate" # this will not

That's true. the value be referenced  must be a constant.
Or you will need to writing a nestedtpl.

@eicnix Tried {{ .Values.labels | quote | tpl | toYaml | indent 4 }}, but got this error: executing "financial-accounting/templates/worker-deployment.yaml" at <tpl>: wrong number of args for tpl: want 2 got 0.
values.yaml
labels:
  revision: revision-{{ .Release.Revision }}-{{ .Release.Revision | quote | b64enc }}

development.yaml
  labels:
{{ .Values.labels | quote | tpl | toYaml | indent 4 }}

I got it working with:
values.yaml
dbName: test_{{ .Release.Namespace }}

deployment.yaml
env:
  - name: DB_NAME
    value: {{ tpl .Values.dbName . | quote }}

I'm using fabric8.io expose controller, which gives a default URL to the exposed service. Now I want to create a custom URL based on the namespace, Something like
fabric8.io/exposeUrl: https://{{ tpl .Release.Namespace }}.jx.org.co, something which the expose controller is going to pick, so I don't have an option to use {{ tpl ... }}. Is there a way such that the name resolution can be done in the values.yaml itself?

Couple of workarounds that others have pointed out in the various sub-threads:

use Helm global values to pass variables from parent to child (ref).
use YAML anchors to improve DRYness within your values.yaml file (ref, thanks @szwed).

These don't cover all the use cases, nonetheless they're nice to have in your tool belt.

I too want to template in my values.yml Mostly to stack complexity and specific configuration using charts. So I start with the generic chart, build my own chart on top having most configuration and leaving some final details to be defined when deploying. YAML anchors are not sufficient: they cannot replace inside YAML values (like a multiline configuration-file string), and lack the Helm dependency logic like subchart values.
I believe we need more powerful features for layering charts without changing the underlying charts to build the Helm chart community. The upstream community charts are now required to enable all the various use-cases in complex logic, rather than in layering. And this logic requires upstream changes to enable much features, wheres layering would require far less upstream changes. Just look at all the properties exposed in most community charts, the inconsistency in these properties and workings, and the duplication in the _helpers.tpl files. And worst of all each community chart is required to explicitly enable these settings on its own. Such a waste of effort.

@nicorikken Sry for the shameless plug but I'd suggest trying helmfile for templating values and layering templated helm releases and helm-x for modifying charts without forking, and even the combination of helmfile + helm-x.
I agree that we need something to deal with issues you've mentioned. On the other hand I don't want to scope-creep helm. That's why I started maintaining the two out-of-tree projects myself.

@mumoshu Thanks for the plug. I saw it mentioned earlier as a potential solution. I'll have a look at it. It will bring the cost of additional tooling, which we might have to integrate with Argo-CD as well (is that even possible?). For now I've forked the repo and parameterized the namespace, and make a PR to the upstream stable charts repo. Let's see what the maintainers make of it.

@nicorikken Thanks for replying!
I think I understand the cost of additional tooling. But on the other hand I'm questioning myself - if there was a huge tool that covers all the helm + helmfile + helm-x use-cases, would it be easy to learn/use?
IMHO it's almost documentation issue. If the additional tool has good-enough documentation to integrate it with the upstream tool and third-party tool(helm and argo cd in this specific case), it is comparable to an in-tree solution.

is that even possible?

Yep :) helmfile template plays nicely with argo-cd's "config management plugin" feature.

For the specific use-case of specifying the namespace, I've made an upstream PR to the Jenkins Helm chart https://github.com/helm/charts/pull/15202 This adds an namespaceOverride parameter. I hope this pattern will be adopted more broadly, to enable cluster-wide Helm chart deployments.
I'll have to take some time to look more into Helmfile. It certainly seems to fill our requirement by enabling advanced cluster-wide templating on top of upstream charts, and integrating with Argo-CD.

Does anyone know how to do this when setting something for an affinity rule? For example, on the NGINX Ingress chart at stable/nginx-ingress, I want to set the controller.affinity value to be the following:
controller:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 5
        podAffinityTerm:
          topologyKey: "kubernetes.io/hostname"
          labelSelector:
            matchLabels:
              app: {{ template "nginx-ingress.name" . }}
              component: "{{ .Values.controller.name }}"
              release: {{ .Release.Name }}

If I just use {{ tpl .Values.controller.name }} for the component section it works, but I also need the app and release portions.

@sc250024 Hey! Where do you define the nginx-ingress.name template in your values.yaml template?
It needs to be defined beforehand with {{define ... as explained in https://golang.org/pkg/text/template/#hdr-Actions

Also - {{.Release.Name}} works only within strings under releases[].values in helmfile.yaml.
This should work:
releases:
- ...
  values:
  - {{`{{.Release.Name}}`}}/values.yaml

This doesn't work:
releases:
- ...
  values:
  - foo: {{`{{.Release.Name}}`}}/values.yaml

I think it worth a dedicated feature request if you need one of those.

@mumoshu it's not defined in my values file, it's something that's included in the NGINX Helm chart located at stable/nginx-ingress. That's my point actually, I'm trying to use that template that's already in that chart.
For the record, I'm not using stable/nginx-ingress as a subchart in a chart I'm developing; I'm just using it directly to deploy NGINX ingress.

it's not defined in my values file, it's something that's included in the NGINX Helm chart located at stable/nginx-ingress. That's my point actually, I'm trying to use that template that's already in that chart.

Unfortunately It's impossible as Helmfile (values) templates works independently from Helm (chart) templates, and nginx-ingress.name is a template defined within the Helm chart for use in chart templates.
Probably the only way would be to copy the {{define "nginx-ingress.name"}} block defined in the nginx chart into your helmfile values template values.yaml?

I am not sure if it would be helpful to anyone, But I have thought about a workaround about this issue and I made it. It may be bad practice but I will share it just in case. You can put a placeholder in the text that you want to template and then replace that placeholder with the template that you would like to use in yaml files in the template. So here is an example:
In values.yaml:
keys:
  - name: key_for_test
    value: CHANGEFORRELEASE-my-value

And I will use this in a secrets yaml:
secrets_kv.yaml:
---
apiVersion: v1
kind: Secret
metadata:
  name: {{ .Release.Name }}-test-kv
  annotations:
    description: Key/Value pairs to save in test datastore
  labels:
    app: test
    tier: backend
    vendor: test
    support: {{ template "supportMethod" . }}
    chart: "{{ .Chart.Name }}-{{ .Chart.Version }}"
    release: "{{ .Release.Name }}"
    heritage: "{{ .Release.Service }}"
type: Opaque
data:
  {{- $var := .Release.Name }}
  kv.yaml: {{ toYaml .Values.keys | replace "CHANGEFORRELEASE" $var | b64enc | quote }}

I hope that it will be helpful to someone.

This is the first thread I ran into, than also comment here...
:) Thankfully, latest Helm manual says how to achieve this.
https://helm.sh/docs/howto/charts_tips_and_tricks/#using-the-tpl-function
The trick is enclosing variable in " or in a yaml block |-, and than referencing it in a template as {{ tpl .Values.variable . }}
This seems to make Helm happy.
Example:
$ cat Chart.yaml | grep appVersion
appVersion: 0.0.1-SNAPSHOT-d2e2f42

$ cat platform/shared/t/values.yaml | grep -A2 image:
image:
  tag: |-
    {{ .Chart.AppVersion }}

$ cat templates/deployment.yaml | grep image:
          image: "{{ .Values.image.repository }}:{{ tpl .Values.image.tag . }}"

$ helm template . --values platform/shared/t/values.betradar.yaml | grep image
          image: "docker-registry.default.svc:5000/namespace/service:0.0.1-SNAPSHOT-d2e2f42"
          imagePullPolicy: Always
      image: busybox

Otherwise there is an error thrown..
$ cat platform/shared/t/values.yaml | grep -A1 image:
image:
  tag: {{ .Chart.AppVersion }}

1 $ helm template . --values platform/shared/t/values.yaml | grep image
Error: failed to parse platform/shared/t/values.yaml: error converting YAML to JSON: yaml: invalid map key: map[interface {}]interface {}{".Chart.AppVersion":interface {}(nil)}

For now, what I've done in the CI job is run helm template on the values.yaml file. It works pretty well atm.
cp values.yaml templates/
helm template $CI_BUILD_REF_NAME ./ | sed -ne '/^# Source: beam\/templates\/values.yaml/,/^---/p' > values.yaml
rm templates/values.yaml

helm upgrade --install ...

This breaks if you have multiple -f values.yml files, but I'm thinking of writing a small helm wrapper that runs essentially runs that bash script for each values.yaml file.

For now, what I've done in the CI job is run helm template on the values.yaml file. It works pretty well atm.
cp values.yaml templates/
helm template $CI_BUILD_REF_NAME ./ | sed -ne '/^# Source: templates\/values.yaml/,/^---/p' > values.yaml
rm templates/values.yaml

helm upgrade --install ...

This breaks if you have multiple -f values.yml files, but I'm thinking of writing a small helm wrapper that runs essentially runs that bash script for each values.yaml file.

There is a use case where you would need to pass deployment name to dependency charts where you have no control.
For example I am trying to set podAffinity for zookeeper. And I have an application helm chart which sets zookeeper as a dependency. In this case, I am passing pod antiaffinity to zookeeper via values. So in my apps values.yaml file I have a zookeeper.affinity section. If I had the ability to get the release name inside the values yaml I would just set this as default and be done with it.
But now for every deployment I have to override this value, which is a big problem.

@thomastaylor312 and others:
I've read through numerous related issues on this general topic, and it seems the notion of templating values.yaml is impractical, non-trivial, etc.
Would it be reasonable to instead support some additional intermediate phase during chart templating/deployment/etc. where some arbitrary (i.e. user-provided) script (i.e. Python, BASH, Lua, etc.) receives a copy of the static values.input.yaml (aka values.yaml) and has access to various variables (i.e. .Release.*), and the script can be responsible for dynamically creating a "final" values.output.yaml file (which is actually directly used by the rest of the chart templates)? If Helm is able to supply the "hooks" for this, it seems like it might be a viable compromise, i.e. "here's all the data and a hook to trigger your script to create values.output.yaml, have fun!".
The one thing of concern that comes to mind that is if this approach could properly handle sub-charts and the scope/meaning of . changing, so I'd have to defer to the Helm maintainers to decide if that's solvable or just another can of worms (i.e. would this phase need to be triggered recursively for sub-charts).
I currently do something like this right now, but it requires me to provide a "launcher" script for my charts, so downstream consumers can't simply "helm install" my charts (somewhat similar use case to helmfile). This arose from a need to templatize values for third-party charts/containers (which I cannot modify for technical and legal reasons). In these charts, I have hard-coded values equating to .Release.Namespace appearing literally everywhere (inside URI/URL strings for the in-cluster FQDN for K8S services, arrays of host names, env vars, etc.). Every time I need to deploy the top-level chart to a different namespace, if it weren't for my helper script, I'd have to modify roughly 30 entries in values.yaml. If there were some way to standardize on this (even if it isn't via the implementation I described above), it would be helpful.

@IAXES Would the new post-render stuff possibly help solve this?

@thomastaylor312 In my own specific use case, definitely yes. In the use cases others have described (i.e. that are non-trivial and require some degree of dynamic generation of the values.yaml file, as well as access to deploy-time variables such as .Release.Namespace, etc.), I strongly suspect it could solve those problems too (would require some additional feedback from others that want/need the original feature described at the top of this thread/issue).
While I'm not versed in the Helm code base, I could potentially chip in or provide design/testing support (or chip away at this as a proof-of-concept if I could ping the collaborators/maintainers for advice on where to inject my code snippets to create the "hook" system).

If this is something deemed worth exploring, it might also be a good idea to +CC the helmfile maintainers/owners, as it might be possible to hook in an existing solution for proof-of-concept. If one could setup these hooks and have any arbitrary solution step in for "filling in the blanks", and the final consumer/user still just has to execute helm install (plus maybe apt/yum/apk install some dependencies), that would be awesome!

@benjigoldberg @fsniper Would the use case I described above potentially address your use cases in a reasonable manner?

@IAXES If I understand correctly you are suggesting, helm providing hooks to external applications and then using the output of them as statics.
This is an interesting idea to explore, at the same time it's already possible without the help of helm at all. You already admit you have been using this process. And I believe all the interested parties could have implemented this themselves.
Considering helm including a templating engine which is more than capable enough to do this, I am not really happy with this approach. First this requires having external applications setup and integrated into probably already running processes, like CI/CD, and second more importantly requires an out of process templating, which is not well defined. As I stated before this definition, and standardization is already in place with helm. So why not using this in helm and provide the means for already requested feature?
Or implementing the already discussed and documented lua scripting could be used for this. Of course it is not available either.
Currently my approach is using helmsman values file environment value substitution. It's limited, but usable with some hops.

This issue makes it more challenging to use blue-green deployments with a parent helm chart for all your apps, at least if any of your values are environment-specific URLs or database connections. For now I'm going to try @leox-phq's workaround.

I also wonder if creating a templates/values.yaml file instead of a values.yaml file could be used as a convention to tell Helm to do value substitutions...not sure if this would this would help address some of the problems with implementing this natively in Helm that were mentioned...

Update: @leox-phq's workaround can be improved to avoid the need for a replacement using sed by using the --show-only option of helm template:
helm template . --show-only templates/values.yaml > values.yaml

I am looking for a way to use Chart.yaml appVersion in values.yaml files. Not sure if there already is a solution, or this issue is required.

@nodesocket It already exists in .Chart! https://docs.helm.sh/docs/chart_template_guide/builtin_objects/

@thomastaylor312 I thought you can only use .Chart.Version inside of templates not in values.yaml files?

Ah sorry, I missed that part. Yes, there is no templating of values files due to the reasons mentioned here.

After reading about templating in values.yaml and trying out different solutions it seems that this are the cleanest solutions for the time being (in terms of being most readable by not having to look into too many places):

Deploy Helm charts through Terraform, provide an external file values.yaml.tmpl, and use templatefile("values.yaml.tmpl",..) to render Terraform variables.
Deploy Helm charts through Helmfile, provide all values in-line, and use {{ requiredEnv "..." }} to render environment variables.

There's also #6876 which is a newer approach to this issue, resolving the concerns raised by https://github.com/helm/helm/issues/2492#issuecomment-413635332. However, it's large, and is taking a long time to get reviewed.

https://github.com/helm/helm/pull/6876 appears to be the most active/plausible approach to this issue so far. Doesn't appear that it'll end up in production any time soon, based on the discussion history. I'll close this proposal as stale and advise future readers to check out said PR.
FWIW, I ended up writing a simple pre-parser tool that generates a final values.override.yaml that gets passed to all of my top-level charts. Maybe not the most elegant solution, but it definitely helped achieve a "more DRY" workflow, which is what I was originally after. Cheers!


target: Create new connection for reentrant calls

When Target.conn property is required while the current connection is
already in use, provide a fresh connection to avoid deadlocks. This is
enabled by the @call_conn decorator that is used on all Target methods
that use self.conn directly.
Fixes https://github.com/ARM-software/devlib/issues/528
note2: if we consider that:

we are not interested in passing Target methods as callbacks to connection methods
the impact of call_conn is negligible

then we could just apply it to all instance methods of Target automatically in a metaclass (or using __init_subclass__ on Python >= 3.6)
note 3: a new connection will be created for every decorated target method call that is done while a call to the connection is active. This this adds overhead, but since it only happens in exceptional situations (from __del__) it should be acceptable. Regular use of the target should not be impacted by that.

Now tested on linux targets and lightly tested on local target. No testing on android target has been done (we don't have any android device in our CI). It seems to work well, with no unnecessary connection created.

Hi @douglas-raillard-arm Thanks for putting this together!
Do you happen to have a minimal example handy to demonstrate this issue that I could use to test things out on my side and I shall also kick off some tests on my android devices.

Hi @marcbonnici , my main test for this series was to apply a patch like that:
diff --git a/devlib/host.py b/devlib/host.py
index 8bd0edf9..2e9b356a 100644
--- a/devlib/host.py
+++ b/devlib/host.py
@@ -96,6 +96,13 @@ class LocalConnection(ConnectionBase):
     # pylint: disable=unused-argument
     def execute(self, command, timeout=None, check_exit_code=True,
                 as_root=False, strip_colors=True, will_succeed=False):
+
+        try:
+            if strip_colors:
+                from __main__ import breakthings
+                breakthings()
+        except ImportError:
+            pass
         self.logger.debug(command)
         use_sudo = as_root and not self.connected_as_root
         if use_sudo:

And then call that from a script defining a breakthings() function which would call target.execute() again to reenter LocalConnection.execute(). The actual issue that made me open https://github.com/ARM-software/devlib/issues/528 was based on __del__ being invoked by the garbage collector at the wrong moment, which depends on various timings on a Juno R0 with a specific workload so it's not easy to reproduce.
If you just want to check that there is no reentrant call on your setup (let's say a regular invocation of WA), you can just apply a patch like that:
diff --git a/devlib/target.py b/devlib/target.py
index 3b26a95f..571d213b 100644
--- a/devlib/target.py
+++ b/devlib/target.py
@@ -96,6 +96,7 @@ def call_conn(f):
     @functools.wraps(f)
     def wrapper(self, *args, **kwargs):
         reentered = self.conn.is_in_use
+        assert not reentered
         disconnect = False
         try:
             # If the connection was already in use we need to use a different


Inserting a LineItem of LineItemType CREDIT in the administration breaks the admin api

**Description: **
When adding a lineItem of type 'credit' via the administration interface (when manually creating an order via the admin interface) this lineItem has no payload, leading to an empty array (!) in the payload column of the order_line_item table.
This breaks type-safe consuming APIs since according to the documentation the 'payload' field should always return an object. In fact, in this case an array is returned.
Actually, null should be inserted instead of an empty array or the empty array should never be returned, but null instead.
Environment: tested in Shopware <IP_ADDRESS>, Shopware <IP_ADDRESS>, Shopware <IP_ADDRESS>
**Steps to reproduce: **
Create a new order in the administration, add a product, then add a 'credit' lineItem of any kind. Store the newly created order.
Expected result:
Adding the 'credit' lineItem creates a row in the order_line_item table which 'payload' column is null.
**Actual result: **
Adding the 'credit' lineItem creates a row in the order_line_item table which 'payload' column is an empty array [], thus not an object.

[public] Automated response: This issue is linked to the internal issue https://shopware.atlassian.net/browse/NEXT-35348.
[created from NEXT-35348, comment 486533]

[public] Hello,
Within our company roadmap and work capacity, we try to address each bug or improvement request but admit that not each one will be resolved. To continue our culture of honesty and openness, we are closing this issue to focus on our roadmap on behalf of all Shopware users.
If you feel like this issue is still impacting you, please create a new issue and let us know. Thank you again for your valuable feedback.
[created from NEXT-35348, comment 519434]


Replace cluster_context hash with a struct

Adds some robustness to the previously vague non-structured hash.
Fixes #853 by refactoring the kube_client initialization

Conflicts again...


Julia 1.11 and ArbNumerics issues with promote?

I'm sorry if this is not the right place, but it seems that last homebrew's version of julia 1.11 breaks ArbNumerics. Now errors are issued whenever some operation between ArbNumerics and built-in types are involved:
For instance, if one defines x = ArbComplex(1.242 + 0.243im), asking for 2x prompts the following error:
ERROR: promotion of types Int64 and ArbComplex{128} failed to change any arguments
Stacktrace:
[1] error(::String, ::String, ::String)
@ Base ./error.jl:44
[2] sametype_error(input::Tuple{Int64, ArbComplex{128}})
@ Base ./promotion.jl:424
[3] not_sametype(x::Tuple{Int64, ArbComplex{128}}, y::Tuple{Int64, ArbComplex{128}})
@ Base ./promotion.jl:418
[4] promote(x::Int64, y::ArbComplex{128})
@ Base ./promotion.jl:401
[5] top-level scope
@ REPL[11]:1
calling promote(2,x) also gives the same error.

Right place. Thank you.

should be fixed with pending merge


[master] Safari preference window tiling behavior issue

Steps to reproduce

Enable BSP tiling for space
Open Safari and its preference window (cmd-,)
Switch to another tab in the preference pane

Expected behavior

Kwm floats the preference window since it is not resizable

Actual behavior

Kwm tries to tile the preference window
Switching to another tab in the preferences resizes the window, causing Kwm to sometimes get stuck in an infinite loop trying to properly tile the window

So for some reason the preference window is not flagged as non-resizable, and it also has a AXStandardWindowRole. I don't really see a solution to this.
Seems like yet another OSX inconsistency..

I just use a rule to float windows that have "preferences" in the title

I just use a rule to float windows that have "preferences" in the title

The safari preference window has multiple titles depending which tab has been selected though, which none actually contain the word "preferences" or similar.

Ah whoops, I don't actually use Safari very much, so didn't actually check.

General, Tabs, AutoFill, Passwords, Search, Security, Privacy, Notifications, Extensions, Advanced - if either of that is the title of a website, Safari will float. That is, if I use the rule to float the prefs. It's a solution for now, but I really don't like that a random website could suddenly float my browser.
Maybe we can fix this with a rule that only applies to windows with a matching name that are also non-resizable?

Maybe we can fix this with a rule that only applies to windows with a matching name that are also non-resizable?

OSX doesn't flag the window as non-resizable, so this wouldnt change anything.

@koekeishiya Do you want to leave this open with #525 being fixed?

Should probably be left open just for tracking purposes.

#525 seems to address the issue of opening the prefs pane, but doesn't clicking any of the other tabs still trigger it? At least that is what it does for me.

@jslatts #525 only adds an option that tiles the preference windows automatically when opened via cmd - ,, if configured correctly.
Using cmd - 0x2B [ Safari ] -> : kwmc window -t next in my .khdrc file makes it so that when I press cmd - , while Safari is open, the next window to be created gets treated as a floating window, then the shortcut gets passed through to Safari. 0x2B is the keycode for , on a german mac keyboard layout.

Is there any way to filter based on class?  In the case of Safari, the actual browser window is a BrowserWindow where the others are NSWindow?


Add TraceEvent support for COMPACT_CSWITCH and other extended flag kernel providers

CSWITCH is rather voluminous, so I would rather not enable it. COMPACT_CSWITCH, on the other hand, can be quite modest in volume. There are also some other potentially valuable extended flag kernel providers that I would be interested in using (memory info, power, minifilter IO).
I've documented the secrets to invoking these providers on StartTrace here: https://gist.github.com/Zhentar/b12daf5683e6bcff455083f9f4bfa00e

I have looked into supporting COMPACT_CSWITCH in the past.   The issue is for most uses (in particular the uses that PerfView needs, you need the STACK of the cswitch.     COMPACT_CSWITCH does not support this, and even if it did, it would not help much (since it is the stack, not the CSWITCH that takes up most of the space).  Thus I did not pursue it.
There are other potentially interesting kernel events, and we have added a few (e.g. RefSet), when their value was high.   I am open to doing more of these, but I want them to have a clear value.   You can start out simply use XPERF to collect the data and see what is really useful, and if there is something that pops, we can consider it.    Also keep in mind that using WPR/WPA is really a perfectly fine solution if they use case is specialized (users in these niches would probably find other aspects of WPA useful as well).
I am closing this issue for now.   Feel free to open it (or other issues), if you feel my response above is inadequate.

To clarify, these are not things that I am intended to collect or analyze with PerfView; I am developing a standalone trace recorder using TraceEvent and would consume these programmatically or in WPA. Currently we mostly rely on WPR to collect field diagnostics but its use is severely hampered by the deluge of high frequency, low value events it collects.
COMPACT_CSWITCH I would like to support high precision attribution of CPU times to threads. It certainly does not deliver the value that COMPACT_SWITCH with stack traces does, but the low volume means we can just always turn it on without hampering our ability to collect extended duration traces.
Minifilter IO I want because it makes it real easy to pick out the impact of antivirus software, and the volume is quite manageable, so long as I filter it to the processes of interest.

So if I understand you, you only care about actually parsing other kernel events.    These could be added 'outside' the TraceEvent library itself, by creating the necessary *TraceEventParser (normally you make this from a manifest, but kernel events have no manifest, so you have to reverse engineer them.   It is not too hard because you can compare against XPERF's parsed output.    The 'Dump' command in the 'events' view is your friend here.
I an not really keen to put these specialty kernel parsers into the library because perfView does not have 'complete' support (it would not know how to generate them), and they are pretty specialized.


Add way to cancel out of drag-drop move

It would be nice to add a way to cancel out of a drag-drop move.  Once you select a handle, if you change your mind, you need to carefully "move" it to the row where it started.  Adding an undo (just depth 1) would be an alternative.

Exactly, ESC cancels it.


Issue #1140: fixes lab crashing when placing too many blocks above start-block

This PR fixes the Issue #1140
Pull Request in Blockly
The problem was a infinite loop that occurred when placing a certain amount of blocks above the start-block
This is fixed now by changing the variable i to j of the inner for-loop in allGlobalVariables method in Blockly

merged with https://github.com/OpenRoberta/openroberta-lab/commit/1d5e76175b46e7d09ea3593728d84a0f60372223


ALDoc : Best practices for folder naming

Please include the following with each issue:
1. Describe the bug
We would like to get some more insights on how ALDoc / Doxfx is generating the TOC for the documentation site. Our .al files are currenly organized into separate folder by logical domain / feature / library. We would like ALDoc to generate a similar table of contents, respecting this logical grouping.
I've however tried several setup but would like to get some recommendations of MS on how to best structure the files to get the desired ALDoc result.
PS: Seems like the system apps of MS also use \Src as subfolder, while the Base App does not and uses root folders by feature / namespace.
PS 2: This applies to an app that does not apply namespaces yet.
2. To Reproduce
Scenario 1 (our current app structure)

Current App has a \permission and \src folder, both containins ALL .al files
The files in the \src folder are logically grouped in subfolders.
The AlDoc results is not sufficient, as it only list permissions and src as Modules.

Scenario 2

App's root folder contains different folders with .al files, logically grouped in folders.
Result is quit OK (except several bugs of inproper ESCA folders)
Downside is that source files are no longer grouped inside a separate folder (and are in between the Translations, Settings, ... folders)

Scenario 3

App has one \src folder containins ALL .al files, logically grouped in folders.
From a developers perspective, that would be a valid solution, as it isolates sources from other app folders such as Translations, Settings, ...
The ALDoc does no longer respect / inherit the logical grouping

3. Expected behavior
I'm looking for a solution / advice on having the logical app folder structure represented as Modules in the AL documentation.
5. Versions:

AL Language: 13.0.864697

if you can't explain a structure to a trainee within 15 minutes, it is a bad structure in my opinion.
In my opinion the "Module" structure is not very useful, because many "modules" are overlapping, so you do not know where to place. And if this is the case every developer will handle it in his own way, which only causes chaos.

@esbenk Adding some more context based on below blog ...
https://www.navnab.com/2023/09/03/generating-help-with-the-aldoc-tool/
... that came to the same conclusion

A) As-is repo structure
- .vscode
- scripts
- src                (containg al files)
  - A_Feature    (containg al files)
  - X_Feature    (containg al files)
- translations

B) Expected aldoc repo structure
- .vscode
- A_Feature (containg al files)
- translations
- scripts
- X_Feature (containg al files)

C) Expected table of contents
Modules
- A_Feature
- X_Feature

Question is if aldoc would be able to support folder structures from A).


Adding more log info

Codecov Report

Merging #1911 (77b0d8d) into master (e93fbb1) will decrease coverage by 58.48%.
The diff coverage is 100.00%.

@@              Coverage Diff              @@
##             master    #1911       +/-   ##
=============================================
- Coverage     73.94%   15.45%   -58.49%
+ Complexity     9665     2278     -7387
=============================================
  Files           690      690
  Lines         53121    53121
  Branches       6618     6618
=============================================
- Hits          39280     8212    -31068
- Misses        11779    44434    +32655
+ Partials       2062      475     -1587

Impacted Files
Coverage Δ

...tore/src/main/java/com/github/ambry/store/Log.java
94.65% <100.00%> (ø)

.../src/main/java/com/github/ambry/router/Router.java
0.00% <0.00%> (-100.00%)
:arrow_down:

.../src/main/java/com/github/ambry/store/Message.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...rc/main/java/com/github/ambry/named/PutResult.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...rc/main/java/com/github/ambry/quota/QuotaMode.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...rc/main/java/com/github/ambry/quota/QuotaName.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...rc/main/java/com/github/ambry/rest/RestMethod.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...c/main/java/com/github/ambry/config/KMSConfig.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...c/main/java/com/github/ambry/config/SSLConfig.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...c/main/java/com/github/ambry/router/ByteRange.java
0.00% <0.00%> (-100.00%)
:arrow_down:

... and 540 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e93fbb1...77b0d8d. Read the comment docs.


Issue with k8s.io/docs/reference/kubectl/cheatsheet/

This is a Bug Report

Need to rectify comment wherein "cluster" is mentioned instead of "user"

Problem:
Comment section reads -
add a new cluster to your kubeconf that supports basic auth; whereas command points to new user addition
Proposed Solution:
Comment shall be -
"# add a new user to your kubeconf that supports basic auth"
Page to Update:
https://kubernetes.io/docs/reference/kubectl/cheatsheet/#kubectl-context-and-configuration

Thanks for spotting this @vijaygharge
The command you've mentioned lets you tell kubectl about new user identity (new to your .kubeconfig anyway), including details on how to authenticate as that user. As you say, it doesn't configure kubectl etc to know about a new cluster.
This looks worth fixing.
/help
/language en
/kind bug
/priority important-longterm

/sig cli

Sorry for jumping in, I'm gonna update the Issue labels to reflect the work on linked PR.
/remove-help
/assign @gosoon


Use new Cabana grid output

With Cabana#744, Cabana now supports specifying the filename when using BOVwriter.  This will remove dependency on std::filesystem for outputing on Frontier, allowing us to get c grids on Frontier.

Note this will require using a newer Cabana commit in the CI


HPB-1372 Add Application name and description to be indexed

@rudi147 @viteke Could you guys review PRs please?


DialDownPayload/DialUpPayload have incorrect type for settings

should be dict not string

@dBeau Yes you are right. Bug fixed in v0.3.1 release


Various OSM API calls implemented

We worked together with Thomas Gratier to implement several main API calls to allow manipulation (creation/edit/delete) of ways and relations, and also other functionalities. This PR is mainly to have another point of view from you @GuillaumeAmat before merging to see if everything is OK.
More changes will come in the next weeks, in particular for clarifying documentation, and also have more coherent naming of functions across the library.
Regards,
Adrien.

Coverage decreased (-38.4%) to 47.97% when pulling a77a7548a88bd90833ff51937315b863500b8515 on webgeodatavore:develop into 27401f05581aa40b224b34b85b4766a33404842b on osmlab:develop.

Thanks for your feedback ! I will perform some of the proposed changes tomorrow.

I pushed various improvements regarding the points you pointed out. For the tests, I reduced the gap in coverage, and this will be pushed forward by Thomas during next weeks. If this looks good on your side, I will make a release (minor version ?) to make these changes available publicly :-)

I pushed various improvements regarding the points you pointed out.

Great thanks!

For the tests, I reduced the gap in coverage, and this will be pushed forward by Thomas during next weeks.

In that PR or another one?

If this looks good on your side, I will make a release (minor version ?) to make these changes available publicly :-)

You can do a minor version until the API broke. SO if you stick with the naming deprecation for now, I'm good with it :) :+1:

Other tests will be provided in a separate PR. OK for the minor release, and thanks for your suggestions ;-)


support ddl based table declare

prototype parse postgresSQL DDL create materialized view from data source

I will be on vacation starting Monday.
A few words on this massive pr.

it interpret postgresSQL DDL and assign values to tablespec(s)
the logic is opt-in when user set table.ddl in yaml file otherwise fallback to YAML properties logic

take back and prototype myself.

introduce cognitive burden to learn two things
not clear how much benefits over yaml in current stage.

take back and prototype myself.

introduce cognitive burden to learn two things
not clear how much benefits over yaml in current stage.


Callbacks: onDeleteStep

Is there a potential to have a callback for steps being deleted in a canvas?
I think it is needed for many cases where a step is deleted anywhere in the canvas and you want to trigger something.
It seems to fit well in the list of callbacks:
add/move
+delete
render
scale

@michaelmarcuccio Yep. I like that idea. I will add that today or tomorrow.


Added support for JDK 8 and 14.

Signed-off-by: AWSHurneyt<EMAIL_ADDRESS>Issue #, if available:
https://github.com/opensearch-project/alerting/issues/242
Description of changes:
Added support for JDK 8 and 14 in test workflow.
CheckList:
[x] Commits are signed per the DCO using --signoff
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #335 (3782791) into main (a5c5cb3) will increase coverage by 0.01%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##               main     #335      +/-   ##
============================================
+ Coverage     78.43%   78.45%   +0.01%
  Complexity      214      214
============================================
  Files           173      173
  Lines          6975     6975
  Branches        916      916
============================================
+ Hits           5471     5472       +1
  Misses         1011     1011
+ Partials        493      492       -1

Impacted Files
Coverage Δ

...ain/kotlin/org/opensearch/alerting/AlertService.kt
78.53% <0.00%> (+0.48%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a5c5cb3...3782791. Read the comment docs.

./gradlew build succeeds locally.


Null Safety Migration

Is there any change this library getting null safety support?

This library is actually already null safe, I think the only thing for Flutter/Dart to recognize it is to migrate to Flutter 2, which I've proposed in PR #104

Awesome!

Well, the only missing thing is to push a new version to pub.dev. @avioli could you take care of that?

Any news on the push?

Bump!

hello???

I don't know if @avioli is alright or just took some time off, either way, I made a simplified version for personal usage while the lib is not updated!
https://github.com/objectivecosta/uni_links_simplified
Hope everything is all right!

@objectivecosta Is this a nullsafe variant of this lib?

@orevial maybe you should push a version to pub.dev too, call it flutter_uni_links

@objectivecosta I agree with @Arcturus5404 . Can you do this?

@Arcturus5404 @BringTheChill pushing another version of the lib is not the solution. I made a simplified repo which you can use to develop ATM, just add it as a git dependency on the pubspec.yaml. Pushing to pub.dev just so a few more lines on the pubspec could be saved is not a good solution.
Let's just wait for @avioli.

@objectivecosta thank you anyway for your effort with this. you helped me a lot!

If anyone else need temporary help running this:
# uni_links: ^0.4.0
  uni_links:
    git:
      url: git@github.com:objectivecosta/uni_links_simplified.git

DISCLAIMER: You'll be running the simplified version I put in https://github.com/objectivecosta/uni_links_simplified

I agree, forking the plugin to pub.dev is not a good solution as it will imply that the two packages will forever live side-by-side and efforts to maintain one of the other are duplicated which is not good IMHO.
I'd rather wait for @avioli to hopefully come back and in the mean time we can all depend on a Git branch for a null-safe version of the plugin 😉

@objectivecosta Can you explain what the simplified means? What did you remove for instance?

If you changed too much, a better solution for now would be:
uni_links: ^0.4.0
  uni_links:
    git:
      url: git@github.com:orevial/uni_links/tree/null-safety-migration

@Arcturus5404 uni_links depends on pub.dev's uni_links_web, which is not published yet. I just put it all in one package.

 With your solution you will probably get an error such as this one:

Because every version of uni_links_web from git depends on uni_links_platform_interface from hosted and YOUR-APP depends on uni_links_platform_interface from git, uni_links_web from git is forbidden.

In the meantime I created another branch with the same code but where uni-links-* dependencies are pointing to the same Git repository so each dependecy can be resolved. To use it:
uni_links:
    git:
      url: git@github.com:orevial/uni_links
      ref: null-safety-migration-local-git-repo
      path: uni_links

Note that this way you don't need to depend on inner packages (web/platform_interface)

Done. Thanks @orevial


Create a Cloud Platform environment

User Story
We want to test networking connectivity between the Cloud Platform and the Modernisation Platform. We will create a simple test app that will be deployed as a container into the CP.
Related Spike: https://github.com/ministryofjustice/modernisation-platform/issues/1410
Follow the instructions from https://user-guide.cloud-platform.service.justice.gov.uk/documentation/getting-started/env-create.html#creating-a-cloud-platform-environment to create a Cloud Platform environment, which will host the test app.
Value

Questions / Assumptions

Definition of done

[ ] readme has been updated
[ ] user docs have been updated
[ ] another team member has reviewed
[ ] tests are green

Reference
How to write good user stories

https://github.com/ministryofjustice/cloud-platform-environments/pull/6951


Not sent email

I run app, but it not sent to a gmail for me

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: fe1bea60-d173-f6d2-3559-b147699e295a
Version Independent ID: 98e7aacb-2a01-d581-9b03-bfef2893163e
Content: Account confirmation and password recovery in ASP.NET Core
Content Source: aspnetcore/security/authentication/accconfirm.md
Product: aspnet-core
Technology: aspnetcore-security
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

Hello! Thanks for contacting us. This sounds like a general question about using ASP.NET Core. While we try to look at and respond to all issues, for questions like this we recommend posting to a community support group like Stack Overflow with the asp.net-core tag.


Prevent vertical scroll due left/right swipe on touchable devices

When I swipe slides left/right on mobile phone, the screen a few scroll up and down. It's non comfort and bad usability.
I have a research of this question, and saw a different solution of this issue.

(bad) In tochmove/touchstart/touchend callbacks make a css style overflow-y: hidden. It's make left/right scroll clean, but when I need scroll page up/down - the slider component ignore my touch. It's bad, because if I orient phone to landscape, and hooper fill all screen - I lose possibility scroll page :( For example, see this.
(good) The best usability was on vuw-awesome-swiper (based on swiper4 library). In this case, I have a fixed vertical position, when swipe left/right, but I have possiblity scroll page up/down when make on swiper verticals taps.

Can you add support of scrolling like as swiper4 library? Very please. :)

Up.
This would be a killer feature usability wise. On iPhones the unwanted verticale scroll is even worse. Maybe a workaround Is possible using the hooks provided by the component? Need ti test it

Any ideas how I can fix it?

Any ideas how I can fix it?

the only solution i have in mind is, when touch event starts, grab the body and lock overflow-y, when it stops reactivate it

@sintj Oh, thanks =)

I founded simple fix, just add @touchstart.prevent="" on slider wrapper

I founded simple fix, just add @touchstart.prevent="" on slider wrapper

inside "" goes nothing?

I founded simple fix, just add @touchstart.prevent="" on slider wrapper

inside "" goes nothing?

Yep or you can add any function

I founded simple fix, just add @touchstart.prevent="" on slider wrapper

inside "" goes nothing?

Yep or you can add any function

Nice hack but, sadly, it also doesn’t allow vertical page scrolling on mobile which is not optimal

Update: I applied the following CSS to the div that contains the hooper element
touch-action: pan-y;
This only allows vertical swiping on the element.
But horizontal swiping still works because of the hooper code :)
Let me know if it also works for you guys


NIFI-3135 - Authorizing restricted components on snippet usage

NIFI-3135:

Authorizing restricted components on snippet usage.
Updating REST API docs accordingly.

Reviewing...


feat(napi): update the doc and type for tsconfig references

Current dependencies on/for this PR:

main

PR #24   👈

This stack of pull requests is managed by Graphite.

Merge activity

Dec 14, 8:11 AM: @@Boshen merged this pull request with Graphite.


SLIME/SBCL integration

Any surefire method to have SLIME and SBCL work within Doom Emacs? I'm not super well versed in how to avoid issues if I upgrade my Doom Emacs install or where exactly to set it up in my own install using MELPA.

Doom has a :lang common-lisp module. Enable it by uncommenting common-lisp in ~/.doom.d/init.el, then run ~/.emacs.d/bin/doom refresh on the command line to ensure everything is installed and set up.
It uses sly, rather than slime, however (a better fork of slime).

I'm not super well versed in how to avoid issues if I upgrade my Doom Emacs install

I'm not sure how this relates to slime/sly, but you can upgrade doom and its packages by running ~/.emacs.d/bin/doom upgrade. As long as you don't modify ~/.emacs.d directly and relegate your private configuration to ~/.doom.d, doom upgrade will go smoothly.

set it up in my own install using MELPA.

Set up your install of SLIME? Since the :lang common-lisp module handles it for you, you don't have to worry about it, but for future reference: package management in Doom is declarative. To install your own packages, add package! declarations to ~/.doom.d/packages.el, for example:
(package! slime)

Then configure the package in ~/.doom.d/config.el, like so:
(def-package! slime
  :defer t ; don't load the package immediately
  :init ; runs this immediately
  (setq inferior-lisp-program "sbcl")
  :config ; runs this when slime loads
  (set-repl-handler! 'lisp-mode #'sly-mrepl)
  (set-eval-handler! 'lisp-mode #'sly-eval-region)
  (set-lookup-handlers! 'lisp-mode
    :definition #'sly-edit-definition
    :documentation #'sly-describe-symbol)

  (add-hook 'lisp-mode-hook #'rainbow-delimiters-mode))

You can look up documentation in Doom with the SPC h f key (look up package! and def-package!).
Hope that helps!

Thanks! This works perfectly.

No, this is not working for me.  It is showing error in def-package!

@sree-kumar note the obsolete tag. This advice is approx a year out of date. Rename def-package! to use-package! and it should work for you. Though not sure what reason there b is to use slime instead of sly.

Yes, sorry about that. I knew it was closed, but I was desperate.  I have a slime configuration already for running c-lisp within emacs which I have been using for quite some time. I never came across sly.  Even after changing def-package! to use-package, I am getting this warning.
Warning (emacs): To restore SLIME in this session, customize ‘lisp-mode-hook’ and replace ‘sly-editing-mode’ with ‘slime-lisp-mode-hook’.
I don't know where to replace this.  Kindly help me because I want to stick to doom emacs.

@sree-kumar Disable :lang common-lisp.

Thanks.  I reverted back. But, I would like to use sly instead of slime in doom emacs. How to tell doom emacs to avoid slime and continue with sly.  Even after disabling, I am getting a warning:
File mode specification error: (file-missing Cannot open load file No such file or directory sly)
Thanks again and sorry to trouble you.  I am just a newbie.

@hlissner Can I have two configurations for emacs-snapshot (version 27.0), one for my previous emacs and one for new doom-emacs. If so, please let me know.  Because, after migrating to doom emacs, most of my earlier configurations are not working.  It takes time to adjust with doom-emcas.


Two small patches for build system and fatfs (IDFGH-10849)

idf.py gdb action incorrectly generated EOL in gdbinit
fatfs routines incorrectly report state for read-only filesystem

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@jendo42 One more request, could you please target master branch and not release/v5.1? Features and bug can be accepted on master branch only. We can backport the change to a release branch after it is merged into master.

sha=bcda40fcf22746f91f301bfcbba768d4a1747922


Implement network "engine" with port redirect iptables

Description
The network "engine" is the thing likely to be pluggable to support different backends (iptables/eBPF...).
The engine interfaces should be platform agnostic.
Probably using TPROXY not REDIRECT.
Need to first come up with a design for this.

This includes DNS


Prefix of commands in messages

📢 Suggestion proposed by Totopizza<PHONE_NUMBER>55561729)
What is the title of your suggestion?
Prefix of commands in messages
Explain your suggestion more accurately (It's best to give as much information as possible, so that we can implement the suggestion better)
I've been observing that when you change the default prefix "?" to another, there are some messages that say, for example: "?commands", and if the owner has changed the prefix to "." always say ".commands" and not "?commands"
Why should we add this feature?
Many users may get confused since it does not show the correct prefix.
Comments:
✅ SaVaGeCrEePeR28 • Furkan: Good idea, then many users can easier understand
✅ Profxy: there are few strings with ? instead of %prefix
📝 Dadi: I'll take a look and change the strings. If you still have some ?command strings instead of %prefixcommand, please let me know :)
✅ Dadi: -

Give us exact examples where this is still used please! :)


Request new module: azure-vm-bastion

Related user story
#74
Type of module
terraform
If requesting a terraform module, what is the target cloud platform?
azure
What is the purpose of the module?
Create an Azure bastion VM
What is the category of the module?
network

/name vm-bastion

/displayName Azure VM Bastion

/group bastion

Module has been created.


[packaging request]: Add dotenvx package

Package Name
dotenvx
Package Component
dev
Package Description
a better dotenv–from the creator of dotenv
Project URL
https://github.com/dotenvx/dotenvx

I might submit a merge request/patch for this later, just filling the issue so I don't forget

Closing this for a while


http: CodecClient handle TCP end_stream

Signed-off-by: Lizan Zhou<EMAIL_ADDRESS>Description:
Http::CodecClient should know if the connection is remote closed before onEvent.
Risk Level: Low
Testing:
unit test, integration tests
Docs Changes:
N/A
Release Notes:
N/A
Fixes #2715

@lizan I'm going to close this for now while we sort out the primary API changes. Once that lands, let's reopen and revisit this change.


A number of toString() methods on classes that implement ByteBufHolder can throw IllegalReferenceCountException

Two examples that I've found include WebSocketFrame.toString() and DefaultByteBufHolder.toString().  toString() implementations should always try to avoid throwing exceptions, since they're used for things like creating exception messages and arbitrary logging of inputs/outputs.  Consequently, if toString() does throw an exception, this will often hide another real problem, a typical example would be:
TextWebSocketFrame frame = ...
try {
  String text = frame.text();
  ReferenceCountUtil.release(frame);
  doSomeProcessing(text);
} catch (Exception e) {
  log.error("Error processing frame: " + frame, e);
}

In this example, if doSomeProcessing throws an exception, the exception will be caught, but not logged, instead, when frame.toString() is invoked, that will throw an IllegalReferenceCountException.
I don't think there's any need to guard access to ByteBuf.toString(), since it likewise shouldn't throw an exception for the same reasons as above, so ByteBufHolder toString() implementations should just invoke that directly without going through any reference count checks.

@jroper sounds like a bug... let me fix it.

Fixed by https://github.com/netty/netty/pull/4341


Problem with shiboken and python 3.8

Timecard failed silently on startup on my windows machine (windows 10, python 3.8). However, by running python timecard-app.exe, I received the following error message:
Traceback (most recent call last):
  File "C:\Users\moshe\AppData\Local\Programs\Python\Python38\lib\runpy.py", line 192, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "C:\Users\moshe\AppData\Local\Programs\Python\Python38\lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "timecard-app.exe\__main__.py", line 4, in <module>
  File "C:\Users\moshe\AppData\Local\Programs\Python\Python38\lib\site-packages\timecard\__main__.py", line 11, in <module>
    from timecard.interface import interface
  File "C:\Users\moshe\AppData\Local\Programs\Python\Python38\lib\site-packages\timecard\interface\interface.py", line 8, in <module>
    from timecard.interface.app import App
  File "C:\Users\moshe\AppData\Local\Programs\Python\Python38\lib\site-packages\timecard\interface\app.py", line 12, in <module>
    from PySide2.QtWidgets import QApplication, QVBoxLayout, QWidget
  File "C:\Users\moshe\AppData\Local\Programs\Python\Python38\lib\site-packages\PySide2\__init__.py", line 51, in <module>
    _setupQtDirectories()
  File "C:\Users\moshe\AppData\Local\Programs\Python\Python38\lib\site-packages\PySide2\__init__.py", line 21, in _setupQtDirectories
    import shiboken2
  File "C:\Users\moshe\AppData\Local\Programs\Python\Python38\lib\site-packages\shiboken2\__init__.py", line 27, in <module>
    from .shiboken2 import *
ImportError: DLL load failed while importing shiboken2: The specified procedure could not be found.

This appears to be a shiboken with python 3.8 issue, according to this stack overflow answer. Since the import error involves a DLL, I assume it is also a windows-only problem.
Since this is a shiboken problem, I suppose not much can be done, but I think fair warning should be given that timecard won't work on windows with python 3.8.

Yeah, I know about this. It's a known bug in PySide2 in relation to 3.8.0, and it's been addressed in a later version of PySide. There are two ways to handle this:

Use Python 3.7 instead of 3.8.
Use the latest version of PySide2 (5.14.0)

I plan to ensure the PyInstaller script explicitly uses Python 3.7 to get around this; that will form the basis for the official Windows release (with installer).

i am using python 3.7.5 and i am getting an error saying the following:  :-1: error: ImportError: DLL load failed while importing shiboken2: The specified procedure could not be found. can someone help me please

@TamGamer97 Assuming you installed from pip, run the following...
pip install --upgrade pyside2

That will ensure you have the latest PySide2. Then try to run Timecard again.
If you still have errors, please open a new Issue, and include the versions of the dependencies, which you can find via...
pip freeze

Thank you.