text:
Allow environment variables substitition in values.yaml

Hi, I would like to propose allowing environment variable substitution in values.yaml file. Something like
// values.yaml

namespace: ${NAMESPACE}

replicaCount: ${REPLICA_COUNT}

port: ${PORT}

image:
  repository: ${IMAGE}
  pullPolicy: IfNotPresent
  tag: ${TAG}

imagePullSecrets:
  - name: regcred

fullnameOverride: ${APP_NAME}

This would be much similar to what is achievable with docker-compose.yml
// docker-compose.yml

version: '3.8'

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
      target: base
    image: ${IMAGE}:${TAG}
    container_name: ${APP_NAME}
    ports:
      - '8080:8080'
    environment:
      PORT: ${PORT}
      NODE_ENV: ${NODE_ENV}
    restart: always

This is especially useful in CI/CD environments as values can be exported as environment variables and the value.yaml file is aware of such values and adequately substituted like in docker-compose.
Running Helm in a CI/CD usually involves constructing a separate values.yaml which will be passed as an argument to 'helm upgrade' command or directly setting each and every value in the command line as arguments
it is somehow daunting keeping multiple values.yaml file for different environments, and deployment targets and having to update each one for every change to a value.yaml
With this feature implemented,  only one values.yaml may be maintained for all environments and deployment targets. The respective values are substituted as needed in the values.yaml (since in most cases, most of the values are already exposed and available as CI variable or environment variable in the CI environment). This will alleviate the pain of replicating/constructing/maintaining multiple values.yaml.
I'd be open to contributing a PR to this

Also to cater for the security of chart consumers, this feature could be made optional (disabled by default and can be enabled by educated users who knows what could go wrong).

Consider, for a moment, those who use apt to install a package on a Debian installation. How many of those who do that are really educated on what's happening on their system and being done by the package? A mass majority are doing things based on a trust model. Usually without verifying. They are not highly educated users on the topics at hand.
This is one of the powerful things about package managers. They enable someone with expert knowledge to package up that knowledge so others can consume it with little to no knowledge on their part.
Problems can arise when package authors start to assume that end users know nearly as much as they do. Package authors have a very different level of knowledge from package consumers. Yet, do many package authors realize that? We want to enable some advanced features but we want to do it in a way that chart authors don't make the experience more complex or less secure for more chart consumers.
This is why I suggest a Helm Improvement Proposal (HIP). It would be a way to look at the varying angles, consider the roles involved, look at the security, and propose something to work with all of that.

Chart authors can also be mandated and (code enforced/lint to ensure) all environment variable placeholders are clearly documented and visible to chart consumers.

This assumes that chart consumers read the docs. Do people read the docs before the reach a bump in the road? I'm not sure they do. Security by expecting people to read the docs may be a bad assumption.

As I have not found any easy way to use environment variables in the values.yaml have I used this line to full fill the requirements.
CI_ENVIRONMENT_SLUG=lala envsubst < charts/values.yaml| helm \
  --kubeconfig ../kubeconf-dev \
  -n mynamespace install --create-namespace -f - --dry-run myapp ./mycharts

The main point is -f -

Any updates?

We already have chart provenance for those that are wanting to enforce security, and the charts are readable by anyone. I think the security issue is a bit moot in my opinion. Bash/Shell already have a way to handle defaults for an envvar when not defined, for which that syntax standard could also be followed.
Having been deploying things via chart for a while now, its getting a bit old having to --set everything when wanting to bring something in from an environment variable as a value override.

I'm just the same thing what @git001 is doing in https://github.com/helm/helm/issues/10026#issuecomment-942367623 and bypassing all security blah blah to get stuff done.
so just make a decision to:
a) support this as is with some --yes-I-know-what-I-am-doing
b) not support this "because of unix philosophy and use envsubst etc to roll your own substitution"
both outcomes are fine.

workaround: multiple value files substituted and merged together:
    values=${@:1}

    opts=""
    tmpfiles=""
    for value in $values; do
      tmpfile=$(mktemp)
      tmpfiles="${tmpfiles} ${tmpfile}"

      envsubst < "${value}" > $tmpfile
      opts="${opts} -f ${tmpfile}"
    done

    for tmpfile in $tmpfiles; do
      cat $tmpfile
    done

    helm upgrade --install \
      "${name}" "${name}/${chart}" \
      --create-namespace --namespace "${name}" \
      --version "${version}" \
      $opts

I'm just the same thing what @git001 is doing in #10026 (comment) and bypassing all security blah blah to get stuff done.
so just make a decision to: a) support this as is with some --yes-I-know-what-I-am-doing b) not support this "because of unix philosophy and use envsubst etc to roll your own substitution"
both outcomes are fine.

While envsubst works in some cases, it does not follow the bash/sh syntax when defining a default value.
Ergo, there would be no support within the values.yaml for something like ${MY_VAR:-test}

I fully agree to the previous comments. helm should have the option to use environment variables maybe with a flag --I_really_know_what_I_m_doing

To ensure integration in our DevOps Processes this improvement is essential!

+1 on this improvement.

This feature might be useful when we use ArgoCD. I didn't find out the helm way to solve the problem changing an image tag automatically in a value file when our application is builded. To solve this problem, I implemented a simple golang program which helps those changes (read a value file, get a tag as an input, and change the image tag value in the value file). It can make CI/CD pipeline but, not suitable. I would say that getting environment variables as a form of .tpl or other way and using them on templates are essential when we construct CI/CD pipeline as a declarative form.

Maybe have a look at https://baloise.github.io/gitopscli/

See the script CFPB built.
https://github.com/cfpb/consumerfinance.gov/blob/main/helm-install.sh#L99

yes, envsubst or sed

I have created a simple helm plugin which imports environment variables and passes them to helm as set values
https://github.com/bery/helm-set
export HELM_VAR_replicaCount=3
helm set upgrade --install --dry-run=false xxx ealenn/echo-server

Result
helm upgrade upgrade --install --dry-run=false xxx ealenn/echo-server --set replicaCount=3

We were facing the same problem, the missing possibility to add variables to values.

This should be possible with vals in combination with the envsubst backend. The reference in a values file would look very nice:
mysqlPassword: ref+envsubst://$MYSQL_PASSWORD

But [the way to get helm to use vals]((https://github.com/helmfile/vals#helm) is so convoluted, that other examples already provided for using envsubsts command or sed directly seems more elegant:
helm template mysql-1.3.2.tgz --set mysqlPassword='ref+envsubst://$MYSQL_PASSWORD' | vals ksdecode -o yaml -f - | tee manifests.yaml
cat manifests.yaml | ~/p/values/bin/vals eval -f - | tee all.yaml

There is a plugin that should make it easier to incorporate:
https://github.com/jkroepke/helm-secrets
I haven't used it because I'm trying to solve this on helmfile, which should work out-of-the-box with vals, but it isn't doing so for me with environment variables... but I leave those links in case they are useful to somebody using directly helm.

Nothing yet then?

This should be allowed. It's silly it isn't already unless there is a good reason not too. Often, more complex deploys have config variables in values.yaml that may need to have dynamic or sensitive information in them and while you can use envtpl (if no existing {{}} in values.yaml) or envsubstr it is a pain that this isn't already built into helm. I would think it would take a limited coding effort to add this in.

Supporting environment variables has been discussed at length and there have usually been issues in how we would do it. A proposal to add them would need a Helm Improvement Proposal.
I'll give you an example of an issue. A common case is for one person or organization to create a chart while someone else consumes it. Helm is a package manager like apt, zypper, yum, etc. It's common for someone to create a chart (package) like the PostgreSQL chart by Bitnami and for many others to install it. Those many other may not know how to install or operate PostgreSQL but they can easily use it.
Many people also store sensitive information in environment variables. Sometimes it's a key, like a GitHub token, or something else sensitive. How does the security model work to help shield the Helm user (chart consumer) from a malicious chart author who wants to exfiltrate sensitive information? Note, these types of situations do come up in our regular security audits.

I'd argue the legitimacy of this attack vector. The simple answer is: it doesn't. It's not entirely Helm's business to make sure users don't use it with malicious charts. Same as Maven [and its plugins], Gradle [and its plugins], kubectl apply, etc. It is up to the user to ensure he knows what he's doing and that the repository/chart he's using can be trusted.
The only really valid problem I can think of is scoping: all the charts are run in the same environment and multiple charts can be referring to the same env variable for different purposes. In this case, even a defaulting mechanism (like shell's ${VAR:-default_value}) will be helpless.

Supporting environment variables has been discussed at length and there have usually been issues in how we would do it. A proposal to add them would need a Helm Improvement Proposal.
I'll give you an example of an issue. A common case is for one person or organization to create a chart while someone else consumes it. Helm is a package manager like apt, zypper, yum, etc. It's common for someone to create a chart (package) like the PostgreSQL chart by Bitnami and for many others to install it. Those many other may not know how to install or operate PostgreSQL but they can easily use it.
Many people also store sensitive information in environment variables. Sometimes it's a key, like a GitHub token, or something else sensitive. How does the security model work to help shield the Helm user (chart consumer) from a malicious chart author who wants to exfiltrate sensitive information? Note, these types of situations do come up in our regular security audits.

I'd argue the legitimacy of this attack vector. The simple answer is: it doesn't. It's not entirely Helm's business to make sure users don't use it with malicious charts. Same as Maven [and its plugins], Gradle [and its plugins], kubectl apply, etc. It is up to the user to ensure he knows what he's doing and that the repository/chart he's using can be trusted.
The only really valid problem I can think of is scoping: all the charts are run in the same environment and multiple charts can be referring to the same env variable for different purposes. In this case, even a defaulting mechanism (like shell's ${VAR:-default_value}) will be helpless.

The way I use env variable in these situations is that I define them just for the execution I'm doing. So if I want to define a port with an env variable, I would do:
PORT_PROXY=8080 helm install my-chart chart-source
That way the variable is not even defined in the machine, and I can redefine it again for a different chart installation.
It would be more problematic for helmfiles, but that is not for this thread.

I just stumbled across this issue when seeing some custom sed substitution magic in our CI/CD setup manipulating values.yml files. I thought that can't be necessary as helm itself is already a kind of substitution technology but it turns out that is and this is one of the suggested workarounds for the missing environment variable substitution in Helm.
So here are my 2 cents on this topic. It could be done similarly to what Spring Boot does. Spring boot allows to set any configuration variable via environment variables. You just have to have to stick to some naming conventions for the environment variables. This way helm chart authors do not need to guess what users may want to override via environment variables and what not. They do not need to know about that feature at all.
To address the already mentioned security concerns this feature could be off by default and you could activate it with the already mentioned --i-know-what-i'm-doing command line switch (maybe --enable-values-from-env).
An example on how this would work. Given the following values.yml.
some-top-level:
  child1: "some default"

You could override this e.g. when doing helm upgrade --enable-values-from-env with an environment variable.
SOMETOPLEVEL_CHILD1="overridden value"

without the need to explicitly state in the values.yml that this config was intended to be overridden by an environment variable. This is consistent with the --set mechanism where you can override arbitrary configs as well.

Same idea as envsubst, but slightly more powerful: https://jinja.palletsprojects.com/
We've used that at work with success. Hope that helps !

This feature would be seriously helpful.

This is an alternative solution that supports default values。 https://github.com/a8m/envsubst

@hexiaofeng

This is an alternative solution that supports default values。 https://github.com/a8m/envsubst

Yep and is a suggested solution in https://github.com/helm/helm/issues/10026#issuecomment-942367623 :grinning:

Still an issue, please unstale.

@hexiaofeng

This is an alternative solution that supports default values。 https://github.com/a8m/envsubst

Yep and is a suggested solution in #10026 (comment) 😀

it's not a perfect solution though as it breaks down with stuff that needs quoting because it has special meaning in YAML, multiline and whatnot.

any updates?

/push

(marked as "keep open" due to community interest, and stop the fighting with the stale bot)

terraform uses TF_VAR_variable_name format
in similar way, i was hoping helm to have HELM_VAR_ to override atleast string variable

@xlrshubham you can check https://github.com/bery/helm-set, this is what I created to add the same behavior to helm ;)

to be honest, i just switched to helmfile, and basically changed my values.yaml to values.yaml.gotmpl templating
even if i am deploying 1 helm chart ! this feature is very helpful.

@xlrshubham you can check https://github.com/bery/helm-set, this is what I created to add the same behavior to helm ;)

nice work there , only problem is many organizations do not allow multiple custom tools on deploy agents

Sharing my workaround in case it helps anyone (no external tools required).
Within templates/deployment.yaml:
image: {{ .Values.image | replace "$TAG" .Values.tag }}

Within values.yaml:
image: $TAG

Populate the value:
export IMAGE="my-image:latest"
helm upgrade my-release my-chart --namespace default --set "tag=${IMAGE}"

@dudicoco this is by far the most elegant solution. it uses a controlled way to pass in envs and requires 0 external deps.
...right after built-in support for helm as --yes-I-know-what-I-am-doing-stop-hand-holding-me that is

authors: AminMkh NicolasTobias Noksa OnyinyeAladiume22 bery dkmiller drtobbyas dudicoco fredleb git001 gjenkins8 hexiaofeng interone-ms ithesadson jeremybusk joelezellLP jslay88 mattfarina matti netikras nhh niiku rbi timsamart vicenteherrera xlrshubham

repo: helm/helm


text:
Helm diff always shows up as different values (quote/unquote) after upgrading a chart. Rendered chart and deployment history doesn't match.

I have an issue with the [bitnami/rabbitmq] chart when trying to use the helmfile tool which relies on helm diff for its operation.
I asked on bitnami/charts#10985 (see there for more details) but they recommended relaying the question here.
Steps to reproduce:
1: Install the chart with a values.yaml file (see above link for content) specifying an auth.rabbitmq-password value and requesting an older revision of the chart.
2: helm upgrade to the latest revision of the chart.
3: run helm diff upgrade rabbitmq bitnami/rabbitmq --values ./values/rabbitmq.yaml --show-secrets
  # Source: rabbitmq/templates/secrets.yaml
---   rabbitmq-password: amFtbG9naWM=
+++   rabbitmq-password: "amFtbG9naWM="

---   rabbitmq-erlang-cookie: QkF4VFRsNGh2aWozVmtpdkZhQnRZdHpaTE5sTzd0dE4=
+++   rabbitmq-erlang-cookie: "QkF4VFRsNGh2aWozVmtpdkZhQnRZdHpaTE5sTzd0dE4="

# Source: rabbitmq/templates/statefulset.yaml
---         checksum/secret: 388f011111c4fa426600c2adddaed1d58b04ee8cf7cc47961484be93aa805c6d
+++        checksum/secret: 7f0e27773fe4b7e51f4e31ac4755b5a7edbf714b0a8e4000daa7562e95d094bd

After that, no matter how many times you call "upgrade", it will always present the same diff output, as if it doesn't apply it.
The statefulset is computed from the secrets so it make sense it changed. The question is why does the helm history contains the password without quote, but the rendered helm chart have some?
Using helm --dry-run --debug or helm template, you can see it render the chart with quotes for these values (in all revisions). So why is it that what is saved in the helm history used by the diff plugin presents the values without quotes?
I'm using 15 other different helm charts in the cluster, some with overridden auth values too, and bitname/rabbitmq is the only one showing that behaviour, so I'm pretty sure something is wrong in their chart, but what could it be?
This is extremely annoying since it prevents me from using the helmfile tool since every time I call apply it always says it needs to upgrade this chart, which isn't true.
Output of helm version:
version.BuildInfo{Version:"v3.8.2", GitCommit:"6e3701edea09e5d55a8ca2aae03a68917630e91b", GitTreeState:"clean", GoVersion:"go1.17.5"}
Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.6", GitCommit:"ad3338546da947756e8a88aa6822e9c11e7eac22", GitTreeState:"clean", BuildDate:"2022-04-14T08:49:13Z", GoVersion:"go1.17.9", Compiler:"gc", Platform:"windows/amd64"}
Server Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.0", GitCommit:"4ce5a8954017644c5420bae81d72b09b735c21f0", GitTreeState:"clean", BuildDate:"2022-05-19T15:39:43Z", GoVersion:"go1.18.1", Compiler:"gc", Platform:"linux/amd64"}
Cloud Provider/Platform (AKS, GKE, Minikube etc.):
KinD

This sounds annoying. I would be frustrated if I encountered this.
I'm not entirely sure what is going on here but I can add some context. There are 3 projects here by 3 different groups. There is Helm, Kubernetes, and the helm diff plugin.
I installed the bitnami rabbitmq chart into k8s 1.24. With both Helm v3.8.2 and the tip of main I ran some tests. I looked at a dry-run template generation and I installed the chart then looked at its manifests. In both cases what came back was quoted. Helm appears to be consistent here.
The Helm diff plugin is based on Helm v3.6.1. I think helm-diff makes calls out to the Helm CLI to get the manifests Helm used last time. Those manifests are later parsed into instances by Kuberentes packages (transitively through Helm 3.6.1) for v1.21.0. Manifests for diffing are generated from there.
I would look into helm-diff as the next step. I suspect it's something in there since the output from Helm is consistently quoted in my tests. helm-diff might need to be bumped to a newer version of Helm to pick up newer Kubernetes packages.

any updates on this?

source: gharchive/issue

authors: Dunge alex-bes-ccl mattfarina

license_type: permissive

license_source: github-api


text:
Helm template generates empty template with braces

Output of helm version:
version.BuildInfo{Version:"v3.8.0", GitCommit:"d14138609b01886f544b2025f5000351c9eb092e", GitTreeState:"clean", GoVersion:"go1.17.6"}
Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.2", GitCommit:"8b5a19147530eaac9476b0ab82980b4088bbc1b2", GitTreeState:"clean", BuildDate:"2021-09-15T21:31:32Z", GoVersion:"go1.16.8", Compiler:"gc", Platform:"darwin/amd64"}
Hi. I have:
# templates/configmap.yaml
{{- include "common-chartlib.configmap" (list . "backend.configmap") -}}
{{- define "backend.configmap" -}}
{{- end -}}

# common-chartlib that is used above
{{- define "common-chartlib.configmap.tpl" -}}
{{- if .Values.configMapDef}}
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Values.configMapDef.name }}
data:
  {{- range $key, $val := .Values.configMapDef.data}}
  {{ $key }}: {{ $val | quote }}
  {{- end }}
{{- end}}
{{- end}}
{{- define "common-chartlib.configmap" -}}
{{- include "common-chartlib.util.merge" (append . "common-chartlib.configmap.tpl") -}}
{{- end -}}

When I launch the template command it generates "almost empty" template with only braces that can't be used in kubernetes but I don't need any output here:
helm template . --name-template backend -s templates/configmap.yaml -f dev/common.yaml -f dev/redis.yaml # launch this
---
# Source: backend/templates/configmap.yaml
{}  # this line is the issue

How can I make the output empty? I can't just remove backend/templates/configmap.yaml because this file is used in other values.yaml files

Want to link the chart that you're working on? There's not enough here for me to duplicate it and I don't see anything obvious.

@joejulian
Sorry, its our internal chart.
Ok, let me clarify. We have this files in chart:
# templates/configmap.yaml file
{{- include "common-chartlib.configmap" (list . "backend.configmap") -}}
{{- define "backend.configmap" -}}
{{- end -}}

# Chart.yaml
apiVersion: v2
name: app
description: Helm chart for app
type: application
version: "0.0.10"
appVersion: "0.0.10"

dependencies:
- name: common-chartlib
  version: 0.1.0
  repository: file://../../../common-chartlib

# common-chartlib/templates/_configmap.yaml
{{- define "common-chartlib.configmap.tpl" -}}
{{- if .Values.configMapDef}}
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Values.configMapDef.name }}
data:
  {{- range $key, $val := .Values.configMapDef.data}}
  {{ $key }}: {{ $val | quote }}
  {{- end }}
{{- end}}
{{- end}}
{{- define "common-chartlib.configmap" -}}
{{- include "common-chartlib.util.merge" (append . "common-chartlib.configmap.tpl") -}}
{{- end -}}

# values-2.yaml
configMapDef:
  name: configmap
  data:
    VAR1: val1
    VAR2: val2

When I launch helm template cli command it shows the output with "{}" that can't be used in helm or kubectl commands to deploy it:
# default values.yaml file doesn't contain configmap config. It generates "{}" output
helm template . --name-template test -s templates/configmap.yaml
---
# Source: discovery-backend/templates/configmap.yaml
{}

# here I launch template command using values-2.yaml that contains configmap config. Works as expected
helm template . --name-template test -s templates/configmap.yaml -f values-2.yaml
---
# Source: discovery-backend/templates/configmap.yaml
apiVersion: v1
data:
  VAR1: val1
  VAR2: val2
kind: ConfigMap
metadata:
  name: configmap

The reason why I have templates/configmap.yaml file is that using default value.yaml I don't need manifest output (like "{}" now) and using values-2.yaml  I need configmap manifest output.
How can I remove the "{}" output?

I do understand the question. Taking what you've given me, I still cannot duplicate this issue.
Error: template: app/templates/configmap.yaml:1:4: executing "app/templates/configmap.yaml" at <include "common-chartlib.configmap" (list . "backend.configmap")>: error calling include: template: app/charts/common-chartlib/templates/_configmap.yaml:14:4: executing "common-chartlib.configmap" at <include "common-chartlib.util.merge" (append . "common-chartlib.configmap.tpl")>: error calling include: template: no template "common-chartlib.util.merge" associated with template "gotpl"

I'm happy to help you debug your chart, but you'll have to give me something I can reproduce.

@joejulian
Thanks for your support. Steps:

create chart test:

# templates/configmap.yaml
{{- include "common-chartlib.configmap" (list . "backend.configmap") -}}
{{- define "backend.configmap" -}}
{{- end -}}

# Chart.yaml
apiVersion: v2
name: test
description: Helm chart for tesst
type: application
version: "0.0.10"
appVersion: "3.34.1"

dependencies:
- name: common-chartlib
  version: 0.1.0
  repository: file://../common-chartlib

# values.yaml
fullnameOverride: test1

# values-2.yaml
fullnameOverride: test2

configMapDef:
  name: configmap
  data:
    VAR1: val1
    VAR2: val2

create common-chartlib dependency chart on the same directory level with test chart:

# Chart.yaml
apiVersion: v2
name: common-chartlib
description: Helm chart librabry for Oryxlabs helm packages

type: library
version: 0.1.0
appVersion: "0.1.0"

# templates/_configmap.yaml
{{- define "common-chartlib.configmap.tpl" -}}
{{- if .Values.configMapDef}}
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Values.configMapDef.name }}
data:
  {{- range $key, $val := .Values.configMapDef.data}}
  {{ $key }}: {{ $val | quote }}
  {{- end }}
{{- end}}
{{- end}}
{{- define "common-chartlib.configmap" -}}
{{- include "common-chartlib.util.merge" (append . "common-chartlib.configmap.tpl") -}}
{{- end -}}

# templates/_helpers.tpl
{{/*
Expand the name of the chart.
*/}}
{{- define "common-chartlib.name" -}}
{{- default .Chart.Name .Values.nameOverride | trunc 63 | trimSuffix "-" }}
{{- end }}

{{/*
Create a default fully qualified app name.
We truncate at 63 chars because some Kubernetes name fields are limited to this (by the DNS naming spec).
If release name contains chart name it will be used as a full name.
*/}}
{{- define "common-chartlib.fullname" -}}
{{- if .Values.fullnameOverride }}
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- $name := default .Chart.Name .Values.nameOverride }}
{{- if contains $name .Release.Name }}
{{- .Release.Name | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" }}
{{- end }}
{{- end }}
{{- end }}

{{/*
Create chart name and version as used by the chart label.
*/}}
{{- define "common-chartlib.chart" -}}
{{- printf "%s-%s" .Chart.Name .Chart.Version | replace "+" "_" | trunc 63 | trimSuffix "-" }}
{{- end }}

{{/*
Common labels
*/}}
{{- define "common-chartlib.labels" -}}
helm.sh/chart: {{ include "common-chartlib.chart" . }}
{{ include "common-chartlib.selectorLabels" . }}
{{- if .Chart.AppVersion }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
{{- end }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end }}

{{/*
Selector labels
*/}}
{{- define "common-chartlib.selectorLabels" -}}
app.kubernetes.io/name: {{ include "common-chartlib.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
{{- end }}

{{/*
Create the name of the service account to use
*/}}
{{- define "common-chartlib.serviceAccountName" -}}
{{- if .Values.serviceAccount.create }}
{{- default (include "common-chartlib.fullname" .) .Values.serviceAccount.name }}
{{- else }}
{{- default "default" .Values.serviceAccount.name }}
{{- end }}
{{- end }}

# templates/_util.yaml
{{- define "common-chartlib.util.merge" -}}
{{- $top := first . -}}
{{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}}
{{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}}
{{- toYaml (merge $overrides $tpl) -}}
{{- end -}}

check the directory structure:

tree test/ common-chartlib/
test/
├── Chart.yaml
├── templates
│   └── configmap.yaml
├── values-2.yaml
└── values.yaml
common-chartlib/
├── Chart.yaml
└── templates
    ├── _configmap.yaml
    ├── _helpers.tpl
    └── _util.yaml

go to test chart and run:

helm dependency build # build deps

helm template . --name-template test -s templates/configmap.yaml # default values.yaml file doesn't contain configmap config. It generates "{}" output, not expected
---
# Source: test/templates/configmap.yaml
{}

helm template . --name-template test -s templates/configmap.yaml -f values-2.yaml # values-2.yaml contains configmap config. Works as expected
---
# Source: test/templates/configmap.yaml
apiVersion: v1
data:
  VAR1: val1
  VAR2: val2
kind: ConfigMap
metadata:
  name: configmap

You're using toYaml on an empty dict. This returns {}.
Try:
# common-chartlib/templates/_util.yaml
{{- define "common-chartlib.util.merge" -}}
{{- $top := first . -}}
{{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}}
{{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}}
{{- $merged := merge $overrides $tpl -}}
{{- if $merged -}}
{{- $merged -}}
{{- end -}}
{{- end -}}

@joejulian
It works. Thanks! :)


text:
Helm 3.10.2 has 2 high vulnerabilities

Running a trivy image scan against an image with helm 3.10.2 installed results in a couple high vulnerabilities:

Total: 3 (UNKNOWN: 1, LOW: 0, MEDIUM: 0, HIGH: 2, CRITICAL: 0)

┌───────────────────┬─────────────────────┬──────────┬────────────────────────────────────┬───────────────────────────────────┬─────────────────────────────────────────────────────────────┐
│      Library      │    Vulnerability    │ Severity │         Installed Version          │           Fixed Version           │                            Title                            │
├───────────────────┼─────────────────────┼──────────┼────────────────────────────────────┼───────────────────────────────────┼─────────────────────────────────────────────────────────────┤
│ golang.org/x/net  │ CVE-2022-27664      │ HIGH     │ v0.0.0-20220722155237-a158d28d115b │ 0.0.0-20220906165146-f3363e06e74c │ golang: net/http: handle server errors after sending GOAWAY │
│                   │                     │          │                                    │                                   │ https://avd.aquasec.com/nvd/cve-2022-27664                  │
├───────────────────┼─────────────────────┤          ├────────────────────────────────────┼───────────────────────────────────┼─────────────────────────────────────────────────────────────┤
│ golang.org/x/text │ CVE-2022-32149      │          │ v0.3.7                             │ 0.3.8                             │ golang: golang.org/x/text/language: ParseAcceptLanguage     │
│                   │                     │          │                                    │                                   │ takes a long time to parse complex tags                     │
│                   │                     │          │                                    │                                   │ https://avd.aquasec.com/nvd/cve-2022-32149                  │
│                   ├─────────────────────┼──────────┤                                    │                                   ├─────────────────────────────────────────────────────────────┤
│                   │ GHSA-69ch-w2m2-3vjp │ UNKNOWN  │                                    │                                   │ An attacker may cause a denial of service by crafting an    │
│                   │                     │          │                                    │                                   │ Accept-Language...                                          │
│                   │                     │          │                                    │                                   │ https://github.com/advisories/GHSA-69ch-w2m2-3vjp           │
└───────────────────┴─────────────────────┴──────────┴────────────────────────────────────┴───────────────────────────────────┴─────────────────────────────────────────────────────────────┘```

These are both server issues. Helm does not host a server so these issues are not relevant.

These are both server issues. Helm does not host a server so these issues are not relevant.

The latest security scanning tools can detect vulnerabilities in statically linked binaries that come from code libraries that have known vulnerabilities.  This technology can not differentiate between actively called code in the binary and unused code and it is hard to know if it really is critical or not as there may be paths to exploit it.  Thus, the rule is that we must keep our binaries clean of vulnerabilities without trying to explain or justify if/why a certain vulnerability does not apply.  It is far too hard to deal with and can end up leading to "excusing" some vulnerability that ends up actually being an issue.
Unfortunately that brings up the problem of a tool such as helm being flagged for things like the runc library version being old even if that part of the code is not actively used in helm.  But it is very hard to single out tools from this scanning technology and to be sure that these types of flaws are not somehow exploitable in the code via some other related attack.
Yes, I know this is annoying and painful but it is also critical to being able to helping maintain security across complex software stacks.

I'm on the other side of this problem at least once a quarter. Recalculating the CVSS is one correct way to address CVE scan results. I use https://www.first.org/cvss/calculator/3.0. Most audit tools allow for rescoring with justification. We usually do it that way because even when we do contribute fixes for CVEs upstream, it's often months before the upstream tool gets released and we can't wait that long.
That said, if someone wants to open a PR to bump dependencies to versions that don't have any CVEs, I'm sure that would be appreciated by the maintainers as well as the rest of the community. :)

There's no version info in this issue and there has since been releases. Closing.

authors: Michael-Sinz joejulian pdrost-sonrai


text:
wait: consider respecting also READY container count

Currently --wait flag only awaits Status == Running condition to be true. But in some cases, this still evaluates to true even no ready containers are there. For example,
NAME                  READY   STATUS    RESTARTS       AGE
foo-7d6d8499f5-4hjz9  0/1     Running   0              1m

Helm --wait does not respect the READY. I think the correct condition would be STATUS == Running and all containers is ready == 1/1.
Output of helm version: v3.11.1
Output of kubectl version: v1.23.7
Cloud Provider/Platform (AKS, GKE, Minikube etc.): -

Actually helm does wait for ready:
https://github.com/helm/helm/blob/e007c900ce5f2233c8583565d5ba1b0433b1a213/pkg/kube/ready.go#L274-L281
What you're probably seeing is the maxUnavailable being met.

Since I answered this and there's been no further questions, I'm going to go ahead and close this.

authors: Dentrax joejulian


text:
Potential issue: --atomic --cleanup-on-fail invoke a rollback without --cleanup-on-fail

I think a helm upgrade --atomic --cleanup-on-fail that results in a rollback could run into an unexpected issue.

--atomic's rollback operation is not influenced by --cleanup-on-fail passed to the upgrade command (ref: code).
If the --atomic invoked rollback fail, it will not --cleanup-on-fail (ref: code)
It is possible to have --cleanup-on-fail be part of a rollback operation (ref: code)

I expected the --cleanup-on-fail to pass through also to the rollback operation if used in conjunction with --atomic. I'm not confident it will matter, but could perhaps the rollback operation render new templates that would fail to be cleaned up?
To figure that out, i guess it may be relevant to consider the built in objects and chart hooks.

Output of helm version:
version.BuildInfo{Version:"v3.1.2", GitCommit:"d878d4d45863e42fd5cff6743294a11d28a9abce", GitTreeState:"clean", GoVersion:"go1.13.8"}

I am not sure I follow the logic there. Can you produce a proof-of-concept?
It is definitely (under a wide variety of circumstances) possible to have a rollback fail. But when a rollback-on-failure fails, the behavior of the cleanup is very tricky. It is not at all clear what a user expects in that scenario. Our strategy in these cases is to not clean up after a failed rollback because a failed rollback may indicate that something is really wrong. We treat --cleanup-on-fail as only applying to the requested release, not the rollback if the requested release fails.
I am not sure if you are suggesting a way to improve this, or merely suggesting that we should change the meaning of --cleanup-on-fail to include cleaning up failed rollbacks (which sounds possibly too destructive to me). But an example case might help clarify things for me.

@technosophos my main personal concern was that it was too much ambiguity of how --cleanup-on-fail worked.
I've not experienced an issue from a failing rollback with --atomic and have no input on what is the best default behavior. But, if the default doesn't involve --cleanup-on-fail for the atomic rollback operation even though --cleanup-on-fail was specified (and applied for the upgrade operation), I think that should be documented within the CLI's --help text that it only applies to the new resources in the upgrade, but not the potential rollback caused by --atomic.

Yeah, for sure it should be documented.
It is possible that our assumptions about rollbacks are wrong. Recovery is definitely a tangled web.

Removing stale label as I intend to document.


text:
v3.2.2 does not contain fixes from v3.2.1

The patch level fixes pulled into v3.2.1 do not appear to be in v3.2.2. Investigating the reason for this. Details to follow on this issue.

v3.2.3 has been released and it contains the commits from v3.2.1 and v3.2.2.

The following is my postmortem analysis on why this happened and what we are going to do about it in the short term.
What happened?
The release process for patches starts with the release branch. Changes to be included in the patch release are cherry-picked on to that branch. Once this is done the branch needs to be pushed where it is tested in CI. Once that passes a tag can be created and pushed for the release process.
When v3.2.1 was released the tag was pushed but the release-3.2 branch wasn't. When v3.2.2 release process started it began on the release-3.2 branch that did not contain the changes from v3.2.1.
The release process documentation fails to document the need to push the branch for patch releases and the person executing the release followed the process as documented.
The Fix
The  short term solution was to release v3.2.3. This release cherry-picked the changes from v3.2.1 on to the release-3.2 branch in the order they were originally picked in to v3.2.1. This did not unwind the change from v3.2.2. Rather, it picked them on top of it.
The mid term solution involves fixing the current documentation to include the push in the patch step (issue https://github.com/helm/helm-www/issues/674). The documentation on the release process isn't great. https://github.com/helm/helm-www/issues/675 has been created to fix that process.
The long term solution is to automate more of the process to remove the possibility for human error.

When v3.2.1 was released the tag was pushed but the release-3.2 branch wasn't. When v3.2.2 release process started it began on the release-3.2 branch that did not contain the changes from v3.2.1.

Nice find!

The long term solution is to automate more of the process to remove the possibility for human error.

👍

authors: marckhouzam mattfarina


text:
fix(engine): clone Template for tpl

See https://github.com/helm/helm/issues/8002
What this PR does / why we need it:
This PR makes tpl function more performant. Using Template.Clone method, tpl works in isolation from "real" templates and avoids excessive and expensive Parse calls.
Special notes for your reviewer:
The new unit test makes sure that tpl function can be nested and has access to defines in partials.
If applicable:

[ ] this PR contains documentation
[X] this PR contains unit tests
[ ] this PR has been tested for backwards compatibility

Hi @diafour. Before we can look at the code, we need you to sign off on the DCO. More information can be found in the failing github check. Thanks!

Can you give any indication of what the performance gain is?

@technosophos we have a chart that relies on tpl. There are 30 files in templates folder and about 15 files that can be tpled depending on values. The difference in performance for this chart is huge:
$ time helm template . -f values.yaml 2>/dev/null 1>/dev/null
  153,41s user 45,19s system 166% cpu 1:59,24 total
$ time helm-new template . -f values.yaml 2>/dev/null 1>/dev/null
 5,98s user 0,41s system 162% cpu 3,934 total

I think I can create a separate repo with a minimal working example from that chart if needed.

Fix defines in tpl, add this case to the unit test.

Squashed and rebased on master.

Hello, @technosophos. Related issue #8002 becomes stale. Any thoughts regarding the fate of this PR?

Hi,
Anything new regarding this PR ? we are relaying on tpl for some use cases, having massive performance issues, any performance gain would be appreciated.

Hello, any news in terms of accepting and releasing this PR? As stated above by others, the performance of tpl is currently causing many performance problems with enterprise grade charts. The PR looks pretty optimistic and is waiting for a longer time on any move from the reviewers team. We definitelly need this fix to be applied.

Hi, is there any outstanding topics that need to be resolved where we, the community, could help to keep this PR moving forward into a release? We're facing the same performance issues and this fix reduces the duration of our helm template runs from over 20s to less than 500ms while producing the exact same output, verified with sha256sum.

No sign off. There's a new PR that solves this and that contributor found flaws in this PR. I believe this PR has been abandoned.
Closing in favor of #11456

@joejulian I don't think it is abandoned. We are still willing to contribute. I think this particular PR suffers with lack of feedback from maintainers, and this is frustrating.

source: gharchive/pull-request

authors: bacongobbler cul-bsi dev-ninja-ops diafour joejulian kchaber nabokihms technosophos


text:
feat: add optional boolean '--wait' flag to 'uninstall' command.

add optional boolean '--wait' flag to 'uninstall' command. If set 'uninstall' command will wait until all the resources are deleted before returning. It will wait for as long as --timeout
Signed-off-by: Mike Ng ming@redhat.com
closes #2378
What this PR does / why we need it:
The helm uninstall --wait flag has been heavily requested by the community, see #2378 .
This is my hacking attempt at implementing this flag.
Special notes for your reviewer:
If applicable:

[x] this PR contains documentation
[x] this PR contains unit tests
[x] this PR has been tested for backwards compatibility

looking forward to this feature
please merge

This feature would simplify a lot things :)

Please merge this so I can remove sleeps from our CI.

@bacongobbler Can this get merged? Seems like quite a nice addition to Helm.

Adding this to the Helm 3.7.0 milestone for review. Thanks @mikeshng for working on this!

authors: RussellTaylor83 bacongobbler inteon kustodian mikeshng orong-pp


text:
Value "true" is not being sent to kubernetes

Operating system
summerwind/actions-runner:v2.301.1-ubuntu-20.04 (Github actions)
Helmfile Version
v0.156.0
Helm Version
v3.12.3
Bug description
We are using retool’s chart on v6.1.1. As far as I can tell there's nothing wrong with the chart as the value is being displayed correctly when running helmfile apply.
When applying configuration I can see that it’s supposed to be:
- name: "POSTGRES_SSL_ENABLED"
  value: "true"

However when it get’s to kubernetes it’s being show as just:
- name: "POSTGRES_SSL_ENABLED"

Example helmfile.yaml
env:
  POSTGRES_SSL_ENABLED: "true"

There are some sensitive information on the rest of the chart configuration, can only share this part.
Error message you've seen (if any)
There are no error messages, it's applying but with incorrect information.
Steps to reproduce

Working Helmfile Version

Relevant discussion
No response

@brunomiranda-hotmart sorry. I couldn't get you. please post a demo.

Hey @yxxhero while producing more steps to reproduce it worked, I'm currently a little bit lost to where to issue is.
Steps to Reproduce

Create a helm chart using command: helm create test-chart
Add an env section to containers like so:

          env:
            - name: DEBUG
              value: "true"
            {{- range $key, $value := .Values.env }}
            - name: "{{ $key }}"
              value: "{{ $value }}"
            {{- end }}
            {{- with .Values.environmentVariables }}
{{ toYaml . | indent 12 }}
            {{- end }}

Package the chart using the command helm package test-chart
Create a helmfile config:

releases:
- name: foo
  chart: ./test-chart-0.1.0.tgz
  values:
  - ./chart-values.yaml

Create the file chart-values.yaml with this config:

env:
  POSTGRES_SSL_ENABLED: "true"

environmentVariables:
  - name: "POSTGRES_SSL_ENABLED_2"
    value: "true"

Run helmfile apply

Behavior with retool chart
Environment variables like POSTGRES_SSL_ENABLED will be created but without a value. Example:

@brunomiranda-hotmart from your comments. I see that this issue only happend on you retool chart. right? th anks so much.

It is considered preferable to use include over template in Helm templates simply so that the output formatting can be handled better for YAML documents.

@yxxhero

I see that this issue only happend on you retool chart. right?
Yeah, apparently so

It is considered preferable to use include over template in Helm templates
I don't understand what you mean by using include over template, could you elaborate a little bit more on that?

@brunomiranda-hotmart did you try to use helm only for your chart?

@brunomiranda-hotmart 👋 I believe that's a chart issue, not helmfile's.
helmfile just runs helm commands like helm template and helm upgrade and so on in favor of your helmfile.yaml.
So any chart that works with helm should work with helmfile.
Looking into the retool chart, it seems to have its own key for setting the SSL_ENABLED env.
https://github.com/tryretool/retool-helm/blob/4681a410cf79d2180c902f8559f3f08c8024df43/charts/retool/templates/deployment_backend.yaml#L106-L107
Woud you mind giving it a try, instead of the env and environmentVariables settings?

authors: brunomiranda-hotmart mumoshu yxxhero

repo: helmfile/helmfile

license: MIT


text:
Will this work with XML?

Will this minify XML files?

I think it should. Check out the html-minifier docs and try it out. If you run into any specific bugs, feel free to open an issue with an example of what you're doing, the results you get and what you expected to get.

authors: alexjking doowb

repo: helpers/handlebars-helper-minify

license: mit

license_source: bigquery


text:
Animate: Add additional examples

Animate: Add additional examples

This adds additional Storybook examples for Animate. It also fixes
the right animation sequence, and adds an expand sequence.

Changes Unknown when pulling 1d5bd8bd8cd24bb3a21b382f0a1d001fff3fc121 on Animate/add-examples into ** on master**.

authors: ItsJonQ coveralls

repo: helpscout/blue


text:
加载核心脚本失败，请重试

打开就报错，重启了还是不对

目前使用的什么版本？

最新的

升级到 1.2.0，如果还是弹出报错的提示，点击 立即重启 ，然后再尝试启动插件

加我vx 23536175

fixed in 1.2.1

[Image Manager] 依赖安装流程结束 [Image Manager] ✅ Image Manager 初始化完成 [Image Manager] 根工作区: /Users/zhoudajun/Code/rbp-client/common_base/sound_lover/assets [Image Manager] libvips 开始自动安装依赖 [Image Manager] sharp binary 开始自动安装依赖: sharp-v1.1.0-napi-v7-darwin-arm64.tar.gz, sharp-v1.1.0-napi-v7-darwin-x64.tar.gz, sharp-v1.1.0-napi-v7-linux-x64.tar.gz, sharp-v1.1.0-napi-v7-linuxmusl-x64.tar.gz, sharp-v1.1.0-napi-v7-win32-ia32.tar.gz, sharp-v1.1.0-napi-v7-win32-x64.tar.gz [Image Manager] 依赖安装流程结束 [Image Manager] ✅ Image Manager 初始化完成
最新版本还是打不开, 只能老老实实用0.24

升级到 1.2.2 即可


text:
The way of evaluation

Hi, author ! Thanks for your code! But I have a puzzle about the evaluation. In 147~150 lines of main.py, you first decide if the new val_acc is bigger than original one. If this condition is satisfied, you then decide the test_acc in the same way. However, during the training of logreg, the test shouldn't be used in my opinion, while only validation is ok. Is there any problem?

See this issue #2

ok


text:
🛑 hentaiOS GitLab is down

In 3deec95, hentaiOS GitLab (https://gitlab.hentaios.com) was down:

HTTP code: 521
Response time: 267 ms

Resolved: hentaiOS GitLab is back up in 8ff1ac0.


text:
[WIP] Add/update documentation re: plugins

Need to decide where to put the markdown -- it could be a standalone page or a section somewhere else.

squash & merge

authors: ncdc skriss

repo: heptio/ark


text:
Fixing broken banner link in the bastion host.

Fixing the banner link in your cloud formation template.
Signed-off-by: Nate Stewart nate@cockroachlabs.com

ok to test

Ok, I pushed the update branch but didn't want to do that. I'm going to merge locally without that merge commit and push.

Thanks for the patch!

authors: chuckha nstewart

repo: heptio/aws-quickstart


text:
Supports JSON configs

Sonobuoy looks at the extensions of the files the configmap defines
and uses a loader implementation to Unmarshal the bytes into a struct.
Both YAML and JSON are supported with respective file extensions of .yaml and .json.
Signed-off-by: Chuck Ha chuck@heptio.com

Motivation here is that if we use jsonnet to nicely define the plugin configs, we will end up with a ConfigMap that defines JSON plugin configs instead of the expected YAML.
We COULD wrap the YAML in a jsonnet string, but that was rejected in PR #9. This PR adds support for JSON plugin config definitions which unblocks #5.

@kensimon could you review please.

authors: chuckha timothysc

repo: heptio/sonobuoy


text:
Openstack Provider Implementation

Fixes:
https://github.com/heptio/velero/issues/940
https://github.com/heptio/velero/issues/119
Signed-off-by: Derek Lemon -T (delemon - AEROTEK INC at Cisco) delemon@cisco.com

Moving to a plugin impl.

Hi @drekle , did you end up publishing the openstack plugin ? Thanks.

https://github.com/cisco-sso/velero-plugin-openstack

authors: drekle tlvenn

repo: heptio/velero


text:
Add original item to restore plugin interface

This had originally been merged into the plugins branch.
Signed-off-by: Michal Wieczorek wieczorek-michal@wp.pl

@nrb PTAL (we're closing down the plugins branch and doing the work directly in master since we're past v0.11 now)

authors: carlisia skriss


text:
HARP-7373: Stub TextElementsRenderer dependencies for testing.

Add helper functions for testing that stub dependencies for
TextElementsRenderer unit tests.
Unit tests are implemented in follow-up PR.
Signed-off-by: Andres Mandado andres.mandado-almajano@here.com
Thank you for contributing to harp.gl!
Before requesting a pull request, please remember to check the following documents:

contribution guidelines
coding style

If you are adding new functionality we would highly appreciate if you can describe what is the capability you are adding and even better if you can add some examples. Please also remember to add tests for it.
CI Check
Our bots will check whether your PR can be directly integrated into the mainline. We have some internal integration tests running on the background, our bots will inform you of the next steps and someone from our team will take a look and help if needed!
And please do not forget to sign-off your commit! You can read more about DCO here. But, in short, you just need to use git commit -s or append --signoff when you are committing to the repo.
Happy contributing!

Codecov Report

Merging #1142 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1142   +/-   ##
=======================================
  Coverage   46.68%   46.68%
=======================================
  Files         243      243
  Lines       22373    22373
  Branches     4999     4999
=======================================
  Hits        10445    10445
  Misses      11928    11928

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 bd410f0...dab9298. Read the comment docs.

authors: atomicsulfate codecov-io


text:
wrong doc on Open5GS tutorial Dockerized VoLTE Setup

probably totally independent from here, but tutorial in https://open5gs.org/open5gs/docs/tutorial/03-VoLTE-dockerized/ at step 2 (build base docker images) say:

cd ../kamailio_base
docker build --no-cache --force-rm -t open5gs_kamailio .

that is wrong, it must say:

cd ../ims_base
docker build --no-cache --force-rm -t docker_kamailio .

You are right. That needs correction. Please open a PR in open5gs repo. Thank you for pointing it out

authors: gmaruzz herlesupreeth


text:
🛑 Hermes Exchange Server is down

In 8825028, Hermes Exchange Server (https://posta.hermes.name.tr/owa) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Hermes Exchange Server is back up in 129e6e4.

repo: hermesthecat/hermes-uptime


text:
ci: allow failing rftrace in release mode

See https://github.com/hermit-os/kernel/issues/1260.
CC: @cagatay-y

Part of https://github.com/hermit-os/kernel/pull/1259.

repo: hermit-os/kernel


text:
Fix loader for Qemu Raspi3 target

Qemu supports the raspi3 target (I'm running qemu-system-aarch64 -display none -smp 4 -m 1G -serial stdio -kernel target/aarch64-unknown-hermit-loader/debug/rusty-loader  -machine raspi3)
These commits add some support for raspi3, so that I could at least successfully boot into the kernel. A lot of fields in BOOT_INFO are not initialized correctly though.
Some things like the value  phys in link.ld should also be set through some board-specific files.
Some commits also only aim to simply improve readability or convert the llvm_asm! to the asm! macro.
I'm leaving this here for discussion for now.

Ok, sounds like a great starting point.

authors: jschwe stlankes

repo: hermitcore/rusty-loader


text:
Add "cron" tests

It's helpful to see when "main" started failing as external dependencies change (such as a change in defaults).

The builder repo's tests are run every day, and they include a smoke test that builds the Ruby getting started guide. We'll also be adding Direwolf CNB tests in the future.
What failure modes did you have in mind to catch with cron tests here?

👍🏻 That seems good enough

Actually I remembered why I wanted it: For the case where someone is contributing, but tests are failing. I want them to be able to check if main is failing as well or it's just their PR.
Basically: It's less for me and more for 3rd party contributors (which we don't have yet, but I would like). Plus I'm tagging this as a wanted contribution for a hackday, hoping that someone can make an easy-ish pr https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#schedule

authors: edmorley schneems

repo: heroku/buildpacks-ruby


text:
Working Tar

Deployer now correctly copies symlinks
Tar producer adds symlinks into jar

This fixes #22

Excellent! testing it out now.

Thanks much! I will cut a release as soon as the US holiday weekend is over.

Awesome! Thank you. This will cut our slug size with ~10%, and since we were previously close to the 300MB limit, that helps a lot.

authors: jkutner tobias-

repo: heroku/heroku-maven-plugin


text:
🛑 Software Center - Test 1 is down

In c7458e5, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 26e01f9.

repo: herrphon/upptime


text:
🛑 Auth-Bridge - Test 1 is down

In 27c5ccc, Auth-Bridge - Test 1 ($AUTH_BRIDGE_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Auth-Bridge - Test 1 is back up in 80b5404.


text:
🛑 Software Center - Test 1 is down

In 165a38a, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in e65ed95.


text:
🛑 Software Center - Test 1 is down

In cff0078, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 766f817 after 669 days, 12 hours, 5 minutes.


text:
🛑 Auth-Bridge - Test 1 is down

In 6987964, Auth-Bridge - Test 1 ($AUTH_BRIDGE_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Auth-Bridge - Test 1 is back up in 19a2c76 after 16 minutes.


text:
🛑 Auth-Bridge - Test 1 is down

In 5c194dc, Auth-Bridge - Test 1 ($AUTH_BRIDGE_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Auth-Bridge - Test 1 is back up in e8fa6ed after 17 minutes.


text:
🛑 Software Center - Test 1 is down

In 5083f51, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 44d1f20.


text:
🛑 Auth-Bridge - Test 1 is down

In 9110afd, Auth-Bridge - Test 1 ($AUTH_BRIDGE_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Auth-Bridge - Test 1 is back up in c91972c after 25 minutes.


text:
🛑 Software Center - Test 1 is down

In 7a3e6f6, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in afe269d after 29 minutes.


text:
🛑 Software Center - Test 1 is down

In 7616d67, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 786fb82 after 11 minutes.


text:
🛑 Software Center - Test 1 is down

In 3ce4e1f, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 8de8ba2 after 11 minutes.


text:
🛑 Auth-Bridge - Test 1 is down

In 5235bc8, Auth-Bridge - Test 1 ($AUTH_BRIDGE_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Auth-Bridge - Test 1 is back up in dfc1b6c.


text:
🛑 Software Center - Test 1 is down

In 0d94181, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 0f28cc8 after 44 minutes.


text:
🛑 Software Center - Test 1 is down

In 5cd3549, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 004f19b.


text:
🛑 Software Center - Test 1 is down

In 6fbefd5, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 19ba23a.


text:
Crash: resignThresholdForBoardSize invoked with GoBoardSizeUndefined

Two crash reports have been received for version 0.12.0. The reports indicate that it is possible that the GtpEngineProfile method resignThresholdForBoardSize: is invoked with GoBoardSizeUndefined (or value 0).

7 years after it was reported, this issue can now be safely considered obsolete.

repo: herzbube/littlego


text:
🛑 Hacker News is down

In b70a4cf, Hacker News (https://news.ycombinator.com) was down:

HTTP code: 502
Response time: 292 ms

Resolved: Hacker News is back up in 703f0b3 after 10 minutes.

repo: heshengshui/upptime


text:
feat: drop support for python 3.8

Python 3.8 is EOL since 07 Oct 2024.
https://devguide.python.org/versions/

Once we merge this, we might need to release a major version of the Ansible collection. I still need to check if this is a good timing.

repo: hetznercloud/hcloud-python


text:
val_loss

hello,Mr He:
I divide one-tenth of the data from your training set as a cross-validation set. After training, the verification set error grows from the beginning. Shouldn't it be a gradual decline?

Could you please share your setting for num_neg, which is used in training phase for negative sampling? I found this parameter has a strong effect on val loss.

I set num_neg=4 the same as yours, used for negative sampling during the training phase.
------------------ 原始邮件 ------------------
发件人: "HenryNebula"notifications@github.com;
发送时间: 2019年4月1日(星期一) 下午2:55
收件人: "hexiangnan/neural_collaborative_filtering"neural_collaborative_filtering@noreply.github.com;
抄送: "愿你我依旧还在"1691763880@qq.com; "Author"author@noreply.github.com;
主题: Re: [hexiangnan/neural_collaborative_filtering] val_loss (#42)
Could you please share your setting for num_neg, which is used in training phase for negative sampling? I found this parameter has a strong effect on val loss.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

So I suppose the error you mentioned here refers to the loss of binary-cross-entropy on the validation set? If so, I guess it would be more proper to use the performance like HR or NDCG as the metric. The reason is the numbers of negative samples are different between training set and validation set (1 vs 4 and 1 vs 99 in the data file *.neg.dat), so the loss may act weirdly.

the loss of binary-cross-entropy is on the validation set,But I divided a part of the training set as a validation set. The ratio of positive and negative samples is 1:4.
------------------ 原始邮件 ------------------
发件人: "HenryNebula"notifications@github.com;
发送时间: 2019年4月1日(星期一) 下午3:11
收件人: "hexiangnan/neural_collaborative_filtering"neural_collaborative_filtering@noreply.github.com;
抄送: "愿你我依旧还在"1691763880@qq.com; "Author"author@noreply.github.com;
主题: Re: [hexiangnan/neural_collaborative_filtering] val_loss (#42)
So I suppose the error you mentioned here refers to the loss of binary-cross-entropy on the validation set? If so, I guess it would be more proper to use the performance like HR or NDCG as the metric. The reason is the numbers of negative samples are different between training set and validation set (1 vs 4 and 1 vs 99 in the data file *.neg.dat), so the loss may act weirdly.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

So you pair another 4 negative samples with the positive one sampled from the original training set to make a new validation set? If so, I think maybe you can check if those negative samples overlap any positive training samples. If all negative samples are correctly chosen, I don't have a better idea about this issue at present.

Ok,Thank you very much!
------------------ 原始邮件 ------------------
发件人: "HenryNebula"notifications@github.com;
发送时间: 2019年4月1日(星期一) 下午4:01
收件人: "hexiangnan/neural_collaborative_filtering"neural_collaborative_filtering@noreply.github.com;
抄送: "愿你我依旧还在"1691763880@qq.com; "Author"author@noreply.github.com;
主题: Re: [hexiangnan/neural_collaborative_filtering] val_loss (#42)
So you pair another 4 negative samples with the positive one sampled from the original training set to make a new validation set? If so, I think maybe you can check if those negative samples overlap any positive training samples. If all negative samples are correctly chosen, I don't have a better idea about this issue at present.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

You're welcome :)

Hey @HenryNebula ,
My question is in some ways related to the value loss, so I felt I should comment here, rather than creating a new issue. The question is some what trivial. I've read the paper and ran the models successfully. Although, I'm a bit confused on one part.
The use of Softmax activation with a binary-cross-entropy is driving me fuzzy. To me this is more or less a regression problem, i.e., when applied to Movie Lens data set trying to predict movie ratings based on previous interactions, the loss function of 'mse' along with 'relu' or even linear activation's make sense, but how come a 'sigmoid' function is used for activation on the last layer ?
Wouldn't the sigmoid function always lead to outputs between [0,1] ? Even if we perform 'N' number of hyper-parameter tuning steps and other regularization techniques , technically a sigmoid function never crosses an output of 1.0 right ? I looked at other implementations of this paper and pretty much found the same thing, a sigmoid function at the end.
I'm not trying to contradict your or the original authors idea here, I'm just trying to figure out how sigmoid activation would make sense for this problem. Or is there any piece I'm missing fundamentally here. Let me what you think.

authors: HenryNebula amit8121 wangdazi


text:
PyVISA-py does not appear to work with VM of Ubuntu

Hi I am not sure if I'm having issues with my VM or PyVISA-py. I installed the latest PyVISA-py on my Ubuntu VM at work so I can start running all my test scripts in Linux instead of Windows, however somethings seem to not work correctly. Below is an output I get after checking to see what devices I have available to connect to.
Python 2.7.6 (default, Jun 22 2015, 17:58:13)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.

import visa
rm = visa.ResourceManager('@py')
rm.list_resources()
(u'ASRL/dev/ttyS31::INSTR', u'ASRL/dev/ttyS30::INSTR', u'ASRL/dev/ttyS29::INSTR', u'ASRL/dev/ttyS28::INSTR', u'ASRL/dev/ttyS27::INSTR', u'ASRL/dev/ttyS26::INSTR', u'ASRL/dev/ttyS25::INSTR', u'ASRL/dev/ttyS24::INSTR', u'ASRL/dev/ttyS23::INSTR', u'ASRL/dev/ttyS22::INSTR', u'ASRL/dev/ttyS21::INSTR', u'ASRL/dev/ttyS20::INSTR', u'ASRL/dev/ttyS19::INSTR', u'ASRL/dev/ttyS18::INSTR', u'ASRL/dev/ttyS17::INSTR', u'ASRL/dev/ttyS16::INSTR', u'ASRL/dev/ttyS15::INSTR', u'ASRL/dev/ttyS14::INSTR', u'ASRL/dev/ttyS13::INSTR', u'ASRL/dev/ttyS12::INSTR', u'ASRL/dev/ttyS11::INSTR', u'ASRL/dev/ttyS10::INSTR', u'ASRL/dev/ttyS9::INSTR', u'ASRL/dev/ttyS8::INSTR', u'ASRL/dev/ttyS7::INSTR', u'ASRL/dev/ttyS6::INSTR', u'ASRL/dev/ttyS5::INSTR', u'ASRL/dev/ttyS4::INSTR', u'ASRL/dev/ttyS3::INSTR', u'ASRL/dev/ttyS2::INSTR', u'ASRL/dev/ttyS1::INSTR', u'ASRL/dev/ttyS0::INSTR')

and here is the output of python -m visa info on my VM. Any help would be much appreciated!! Thanks!
Machine Details:
Platform ID:    Linux-3.13.0-61-generic-x86_64-with-Ubuntu-14.04-trusty
Processor:      x86_64
Python:
Implementation: CPython
Executable:     /usr/bin/python
Version:        2.7.6
Compiler:       GCC 4.8.2
Bits:           64bit
Build:          Jun 22 2015 17:58:13 (#default)
Unicode:        UCS4
PyVISA Version: 1.8
Backends:
ni:
Version: 1.8 (bundled with PyVISA)
Binary library: Not found
py:
Version: 0.2
ASRL INSTR: Available via PySerial (2.7)
TCPIP INSTR: Available
USB RAW: Available via PyUSB (1.0.0b2). Backend: libusb1
USB INSTR: Available via PyUSB (1.0.0b2). Backend: libusb1
GPIB INSTR:
Please install linux-gpib to use this resource type.
No module named gpib
TCPIP SOCKET: Available

What is not working? I do not see any error messages?
Ps. I am using PyUSB rc1, maybe you can update to it as well.

So I don't know if something isn't working. I am just really confused on why I get the list of all the devices that I can supposedly use, when I only have one USB device connected to my computer. I thought it might be because I had an old version of PyUSB on my VM, but after I updated it was the same. I'll try the PyUSB rc1 to see if that helps. I was mainly curious if you have tried PyVISA-py out on a Linux VM, because it's always possible the list of usable device that is presented to me could just be devices the VM thinks it sees.

In general VISA lists all conected devices except in the case of serial
where ir lists all ports. This is what you are seeing. This is true for
Ni-ViSA and pyvisa-py (albeit the first provides a shorter and cleaner
output as it filters the list to show only the real ports). So the output
you are getting is correct.
Regarding the usb device in the VM, it works. But you have to tell the VM
to grab it in the same way that you do it with a usb stick.
hope it helps. let us know.
El 19:48 Jue Ago 27, 2015, dillharr notifications@github.com escribió:

So I don't know if something isn't working. I am just really confused on
why I get the list of all the devices that I can supposedly use, when I
only have one USB device connected to my computer. I thought it might be
because I had an old version of PyUSB on my VM, but after I updated it was
the same. I'll try the PyUSB rc1 to see if that helps. I was mainly curious
if you have tried PyVISA-py out on a Linux VM, because it's always possible
the list of usable device that is presented to me could just be devices the
VM thinks it sees.
—
Reply to this email directly or view it on GitHub
https://github.com/hgrecco/pyvisa-py/issues/56#issuecomment-135576522.

Thank you for your help! I'm pretty sure my issues are stemming from my VM setup after doing some more testing, so I am going to try to tweak some things on my VM. Thanks again!

Post your results here if you manage to make it work. I am sure other users are trying to achieve the same thing!

authors: dillharr hgrecco

repo: hgrecco/pyvisa-py


text:
modified segmenter directory and dataset class name along with other …

…small issues

Thanks...merging this. I have fixed some bugs which I'll add in a separate PR.

authors: YiwenShaoStephen hhadian

repo: hhadian/waldo


text:
下载SQL回滚报错:connect() argument 1 must be str, not None

问题描述
在使用Archery SQL审核上线功能时，在下载SQL回滚报错
报错结果：
connect() argument 1 must be str, not None
版本信息

应用版本/分支：{"archery": {"version": "1.7.10"}
部署方式：Docker

系统设置没配置备份库连接信息

系统设置没配置备份库连接信息
感谢，我这边先试一下

系统设置没配置备份库连接信息
你好，我按你说的配置备份库连接，也显示有报错

系统设置没配置备份库连接信息
你好，我按你说的配置备份库连接，也显示有报错

你好，默认那个“Inception”是不用开启的吧，我看官方文档说的，直接用goInception，还是说Inception也要配置

备份库的账号密码没填

谢谢你，我这边现在解决了！
------------------ 原始邮件 ------------------
发件人: "小圈圈"<notifications@github.com>;
发送时间: 2020年6月13日(星期六) 中午12:01
收件人: "hhyo/Archery"<Archery@noreply.github.com>;
抄送: "♂Dreamヾ"<499453652@qq.com>;"Author"<author@noreply.github.com>;
主题: Re: [hhyo/Archery] 下载SQL回滚报错:connect() argument 1 must be str, not None (#777)
备份库的账号密码没填
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

备份库的账号密码没填

你好，能不能再请教个问题，我这边操作SQL上线时，点击SQL检测的时候，我执行的SQL语句中有空值，但是提示不能为空值，不能提交不成功，请问这个在哪里修改呢？

看一下 goinception 或者 inception 的文档吧, 这里应该是改 goincetion 的配置

authors: LeoQuote hhyo yuanmeng-123

repo: hhyo/Archery


text:
Editor not in focus when opening one file

I have this issue where if I'm opening a single file, the editor comes up but is not focused, so I need to click in it before I can start editing. The same does not happen when opening multiple files.

Thanks for reporting it and the pull request. I haven't experienced this myself on Win7 and Win8 or a specific program.
Does it happen all the time or just for one or more programs?

I just started using your script, and only have one editor defined - I replaced "notepad.exe" with SublimeText.exe.
I'm on Win7.

Just downloaded ST to try it and it doesn't happen here but I accepted your pull request and bumped the version number to v0.93.
Thanks again. 👍


text:
Plz new backup database

shop-online
Plz new backup database
Static analysis:
3 errors were found during analysis.
Variable name was expected. (near " " at position 23)
Variable name was expected. (near " " at position 38)
Unrecognized statement type. (near "new" at position 0)
SQL query:
new file mode 100644 @@ -0,0 +1,232 @@ +++++++++ +SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO"
MySQL said: Documentation
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'new file mode 100644
@@ -0,0 +1,232 @@
+++++++++
+SET SQL_MODE = "NO_AUTO_VALUE_' at line 1

#1064 Database Error
Please do change new backup (export) database. :( 👍
Thank You

I Just make a new databases to the Source Code Thank You for the free Source :) 👍
Sorry for my language

@tommyhawk95 I need database Plz upload

@cookiesze Done

@cookiesze Done

can you send me the database ? hehe

authors: cookiesze pasekb tommyhawk95


text:
🛑 kiwifarms.st is down

In 6488164, kiwifarms.st (https://kiwifarms.st) was down:

HTTP code: 0
Response time: 0 ms

Resolved: kiwifarms.st is back up in c022769 after 5 minutes.

repo: hickoryhouse/kf


text:
🛑 Kiwi Farms Forum is down

In 34488f7, Kiwi Farms Forum (https://kiwifarms.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Kiwi Farms Forum is back up in 53ca168 after 5 minutes.


text:
🛑 kiwifarms.st is down

In 78d64f3, kiwifarms.st (https://kiwifarms.st) was down:

HTTP code: 0
Response time: 0 ms

Resolved: kiwifarms.st is back up in 4ad7aa0 after 4 minutes.


text:
🛑 kiwifarms.st is down

In e3dc780, kiwifarms.st (https://kiwifarms.st) was down:

HTTP code: 502
Response time: 1180 ms

Resolved: kiwifarms.st is back up in 5e6e2ce after 18 hours, 45 minutes.


text:
Fix for python 3.8 and numpy dependency

This PR adds python-version specific dependencies to address numpy compatibility with v1.x and v2.x.
There is one spec test failing in 3.8. Could that be due to numpy 2.0 and numpy 1.x differences?
@smiet, can you please invetigate?

all passing now, fixed on current spec master by not requiring 2.0 if python<3.8.
There is a new PR waiting that removes numpy dependency on install, but that shouldn't affect this.

@smiet
Spec related tests are still failing. https://github.com/hiddenSymmetries/simsopt/actions/runs/9713949797/job/26811901758 Can you please check?

@mbkumar  the failures you are referring to are caused by an identifier collision in the python cache of the Fortran memory. They occur because f90rwap uses an identifier based on the pointer in memory for its python-cache, and re-loading a Spec object results in sucessive deallocation and allocation, with possibility of occupying the same location on memory-constrained systems (such as runners). This results in the collision such that python references an outdated and misshapen array.
Will be addressed and fixed in PR  #431, if you want to speed it up, give it an approve, or directly merge it ;)

authors: mbkumar smiet

repo: hiddenSymmetries/simsopt


text:
Merge recent dev environment, but still error....

I have merged with the 83937c7. Please merge this PR.
However, this version still has an error when running the test code because this test code does not consider the wind force.
I believe this test code should be able to run without changing this test code itself.

The following task list describes the step-by-step modification strategy for merging your good contribution to the original repository.

[ ] modify the code by using multiple dispatch for running this test code without modification.
[ ] add the test code considering wind force.


text:
🛑 μlogger is down

In 7893e6f, μlogger (https://gps.hinzwifi.xyz/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: μlogger is back up in d196ae2 after 32 minutes.

repo: hinzwifi/uptime-hinz


text:
🛑 File Share is down

In 682caa7, File Share (https://share.hinzwifi.xyz/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: File Share is back up in da53ecc after 12 minutes.


text:
test: exceptions incomplete

Missing new test system (test.py)
Missing SUCCESS
Needs to be updated with either macro or lest test framework (preferred)

@matiashf will take a look at this one

I simplified the exception tests to make them fit with lest, and now they only test for exception types, not exception descriptions. Will they have to be extended to compare exception strings?
@alfred-bratterud rewrote the tests in 03c097690aaf125cc0ee62060c0d847e683f94e1, but it's unclear what the rationale was compared to the previous version in 9cd39f3c8842b62c24f13355c5c11cdce006e7a8.

I see no reason not to compare exception strings, as the current version does that. Just extend it as you see fit if you come up with more scenarios 👍

Fixed with #677

authors: AndreasAakesson matiashf

repo: hioa-cs/IncludeOS


text:
Add favicon in html file

find any relatable favicon for markdown and add that image as a favicon in html file.

I would like to work on this issue.

@VanshSutariya, thanks for raising your hand, please submit a PR by tomorrow.

@hirentimbadiya can i work on this.

authors: VanshSutariya heisdinesh hirentimbadiya

repo: hirentimbadiya/Markdown-Previewer


text:
fix for dBASE Level 7

Hi,
I am trying to connect to one of my dbf table (dbase version 7) and it doesn't work with the original code.
I have modified some of the code in XBase\Table according to the format provided in this website.
http://www.dbase.com/KnowledgeBase/int/db7_file_fmt.htm
Let me know what you think. Thanks.

Btw, my dbf version ($this->version) was captured as '4' in readHeader function.
I have posted my dbf header structure in stackoverlow.
http://stackoverflow.com/questions/42295178/check-dbase-version-with-hex-viewer

I don't think this is still relevant. If not, you can reopen it.

repo: hisamu/php-xbase


text:
Support matchMedia in jsdom

Describe the bug
I rely on a dependency uPlot which calls window.matchMedia.
So this might eventually be added to jsdom (workaround for jest), in the meantime I attempted this mock:
window.matchMedia = window.matchMedia || (() => {
  return {
    matches: false,
    addListener: () => {},
    removeListener: () => {},
  }
})

It seems that it is ignored by histoire.
Reproduction
https://stackblitz.com/edit/histoire-vue3-starter-wwbdpg
System Info
System:
    OS: Linux 5.19 Ubuntu 22.10 22.10 (Kinetic Kudu)
    CPU: (12) x64 AMD Ryzen 5 1600 Six-Core Processor
    Memory: 5.64 GB / 15.58 GB
    Container: Yes
    Shell: 5.2.2 - /bin/bash
  Binaries:
    Node: 16.14.0 - /usr/local/bin/node
    Yarn: 1.22.5 - /usr/bin/yarn
    npm: 8.3.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 108.0.5359.124
  npmPackages:
    @histoire/plugin-vue: 0.12.4 => 0.12.4
    @vitejs/plugin-vue: 4.0.0 => 4.0.0
    histoire: 0.12.4 => 0.12.4
    vite: 4.0.4 => 4.0.4

Used Package Manager
npm
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion.
[X] The provided reproduction is a minimal reproducible example of the bug.

Okay so I digged around the src and adding something like this to the populateGlobal fnc does in fact resolves my issue.
// ..........
// ..........
// ..........

export function populateGlobal(global, win, options = {}) {
    const { bindFunctions = false } = options;
    const keys = getWindowKeys(global, win);
    const originals = new Map();
    const overrideObject = new Map();

    win.matchMedia = (() => {
      return {
        matches: false,
        addEventListener: () => {},
        removeListener: () => {},
      }
    })

    // ..........
    // ..........
    // ..........

}

Obviously this mock might not cover every use-case with matchMedia, without more context on how exactly JSDOM is used within histoire I cannot tell whether this is sufficient.

I ran into the same issue, but I have a temporary fix inside the component to work in Histoire. I created a simple file, that must be imported before the library is imported in the Vue Component.
// utils/fixHistoireMatchMediaBug.js

if (!window.matchMedia) {
  window.matchMedia = () => ({
    matches: false,
    addEventListener: () => {},
    removeListener: () => {},
  });
}
// needs an export in order to be recognized as module
export {};

Inside the component that imports the library (in my case it was the plyr library) I imported this file
import '@utils/fixHistoireMatchMediaBug.js';
// must be placed after the import of the fix.
import Plyr from 'plyr';
// ...

This is really not a nice solution, but it works until this is fixed in Histoire. I hope, this bug will be fixed soon, but maybe this also helps to solve it termporarily.

authors: kristofgilicze leifmarcus

repo: histoire-dev/histoire


text:
Missing Build Instructions

It would be very helpful to have a section in the README.MD file about how to build the software.

I thought that would be rather straightforward. You just have to build the src/extralibs with the provided makefiles (actually the repository contains the lib already compiled) & then the tracker.
Are you running into some sort of issues during compilation ?

I am.  On 64-bit Linux every typedef long long unsigned uint64_t; needs to be replaced with #include  instead due to a type collision.  Also C++17 doesn't allow pointer=&value; so *pointer=value; needs to be corrected in 2 places.  The linker needs -lpthread for multithreading.  My code now builds but segfaults on running.

That include should be cstdint.  GitHub blocked the angle braces.

The seg fault is coming from the *pointer=value; in xml.cpp.

Thanks.  I'll need to think on that part some more then.

Also it's using oss so you'll probably have to install the oss emulation of alsa. I planed to move the audio output to alsa but never did (it shouldn't be too hard).

I thought that would be rather straightforward. You just have to build the src/extralibs with the provided makefiles (actually the repository contains the lib already compiled) & then the tracker.

Happens to me all the time, I get too comfortable with my own codebase and I totally miss how confusing it can be for the newcomers to get started. I'd say anything that requires more than ./configure && make && make install needs some mention in the README.md.

Are you running into some sort of issues during compilation ?

Yes. I always end up with a zip files that contains some assets (I'm guessing) but no executable files. I'd actually appreciate a small list of steps to produce the macOS app from the source code.

Basically, you'll have to do a "make -f makefile.macosx" and it should create an universal binary but i don't think newer OSX can compile ppc code (it was made a long time ago on OSX Tiger). Splitting that file in two may work.

I see, maybe the arch is the problem, indeed. When I perform that, I get this on an Intel Mac running macOS 11.4:
g++ -c -o ptk_ppc.o  -O3 -mcpu=G4 -fomit-frame-pointer -ffast-math --prefetch-loop-arrays -faltivec -maltivec -mtune=G4 -fno-rtti -I/Library/Frameworks/SDL.framework/Headers -Lsrc/extralibs/sdl_draw -Lsrc/extralibs/zlib-1.2.3 -L/library/frameworks -fno-strict-aliasing -arch ppc -D __MACOSX__ -D __GCC__ -D __MACOSX_CORE__ -D __BIG_ENDIAN__ -D __MOT_SWAP__ -D __AIFF__ src/ptk.cpp
clang: error: unsupported option '--prefetch-loop-arrays'; did you mean '-fprefetch-loop-arrays'?
clang: error: the clang compiler does not support 'faltivec', please use -maltivec and include altivec.h explicitly
clang: warning: include path for libstdc++ headers not found; pass '-stdlib=libc++' on the command line to use the libc++ standard library instead [-Wstdlibcxx-not-found]
make: *** [ptk_ppc.o] Error 1

Yeah, PowerPC support was dropped at Snow Leopard (10.6).  (Then it was all downhill from there IMO.)
@hitchhikr
Thanks for the updated build script for Linux64.  It works from PulseAudio using its OSS emulator.

padsp ./ptk_linux

diogoeichert: i'll see what i can do about that.
SamuraiCrow: I'll move the linux version from oss to alsa.

macos Monterey 12.4, 2019 macbook pro intel, receiving errors trying to build those extralibs, seems like layers of missing or misconfigured dependencies, haven't gotten to the bottom of the layers yet.  Currently just running the windows binary through wine. +1 for a README!

Try it again, it should work now...

authors: SamuraiCrow diogoeichert hitchhikr illettante

repo: hitchhikr/protrekkr


text:
feat(108) - Define 2 status fields for adapters & bridges

We need to be able to express 2 status' for adapters and bridges. We now have runtimeStatus and connectionStatus.

Merged - note the IT need merging in the test project. //TODO simon

repo: hivemq/hivemq-edge


text:
請問是否不再支持導出模型

cannot export trained model, is that still suport exporting model?

?

authors: hiyouga johnhonjj

repo: hiyouga/LLaMA-Factory


text:
error after loading the model

increase your VRAM or try smaller model

.

我的也是这样，后来发现是数据集出问题了，在LLaMA-Factory/data/dataset_info.json文件中配置如下：
"llama3_law": {
    "formatting": "sharegpt",
    "file_name": "train_data_law.json",
    "columns": {
      "messages": "conversations",
      "system": "system",
      "tools": "tools"
    },
    "tags": {
      "role_tag": "from",
      "content_tag": "value",
      "user_tag": "human",
      "assistant_tag": "gpt"
    }
  }

数据集格式如下：
[
  {
    "conversations": [
      {
        "from": "human",
        "value": "基于下列案件，推测可能的判决结果。\n经审理查明，2015年6月21日15时许，被告人白某某在大东区小河沿公交车站乘坐被害人张某某驾驶的133路公交车，当车辆行驶至沈阳市大东区东陵西路26号附近时，被告人白某某因未能下车而与司机张某某发生争执，并在该公交车行驶中用手拉拽档杆，被证人韩某某拉开后，被告人白某某又用手拉拽司机张某某的右胳膊，导致该车失控撞向右侧马路边停放的轿车和一个路灯杆，路灯杆折断后将福锅记炖品店的牌匾砸坏。后经被害人张某某报警，公安人员赶至现场将被告人白某某传唤到案。经鉴定，公交车受损价值人民币5,189.9元，轿车受损价值人民币1,449.57元，路灯杆受损价值人民币2,927.15元，福锅记饭店牌匾受损价值人民币9,776元，本案损失价值共计人民币19,342.6元。上述事实，被告人白某某在庭审中亦无异议，被害人张某某、朱某某、詹某某陈述，证人韩某某的证言，现场勘察笔录，视听资料，鉴定结论书，被告人白某某的供述与辩解等证据证实，足以认定。"
      },
      {
        "from": "gpt",
        "value": "根据《刑法》第一百一十四条的规定，被告人白某某以危险方法危害公共安全，尚未造成严重后果。根据案件事实，被告人白某某在公交车上与司机发生争执，并用手拉拽档杆和司机的胳膊，导致公交车失控撞向停放的轿车和路灯杆，最终造成公交车、轿车、路灯杆以及福锅记饭店牌匾的损坏。根据鉴定结果，本案损失共计人民币19,342.6元。\n综上所述，根据《刑法》第一百一十四条的规定，被告人白某某的行为构成以危险方法危害公共安全罪。根据该罪的刑罚幅度，可判处三年以上十年以下有期徒刑。\n需要注意的是，以上仅为根据提供的案件事实和相关法律条文进行的推理，最终的判决结果还需根据法庭审理的具体情况和法官的判断做出。"
      }
    ],
    "system": "",
    "tools": ""
  }
]

@YuChuanhui3 Iam using alpaca dataset format


text:
glm-4-9b-chat-1m do_predict得到的generated_predictions.jsonl中的label出现了\n和一些非数据集中的结果。

Reminder

[X] I have read the README and searched the existing issues.

System Info
llamafactory              0.7.2.dev0
Python 3.10.14
ubuntu 20.04
Reproduction
$llamafactory-cli train glm_predict.yaml
generated_predictions.jsonl 输出
{"label": "\n[S,137.0]", "predict": "\n[S,137.0]"}
{"label": "\n", "predict": "\n"}
{"label": "\n", "predict": "\n"}
{"label": "\n[S,593", "predict": "\n[S,593"}
{"label": "\n[H,593", "predict": "\n[S,593"}
glm_predict.yaml 内容
model
model_name_or_path: ./THUDM_glm-4-9b-chat-1m
adapter_name_or_path: saves/glm/lora/sft
method
stage: sft
do_predict: true
finetuning_type: lora
dataset
dataset: data_v0.1
template: glm4
overwrite_cache: true
preprocessing_num_workers: 16
output
output_dir: saves/glm/lora/predict
eval
per_device_eval_batch_size: 4
predict_with_generate: true
Expected behavior
期望输出
generated_predictions.jsonl 输出
{"label": "[S,137.0]", "predict": "[S,137.0]"}
{"label": "[S,593]", "predict": "[S,593]"}
{"label": "[H,593]", "predict": "[S,593]"}
只包含"\n"的结果都没有出现在数据集中。
Others
No response

_register_template(
name="glm4",
format_user=StringFormatter(slots=["<|user|>\n{{content}}<|assistant|>"]),
format_assistant=StringFormatter(slots=["\n{{content}}"]),
format_user=StringFormatter(slots=["<|user|>\n{{content}}<|assistant|>\n"]),
format_assistant=StringFormatter(slots=["{{content}}"]),
format_system=StringFormatter(slots=["[gMASK]{{content}}"]),
format_function=FunctionFormatter(slots=["{{name}}\n{{arguments}}"]),
format_observation=StringFormatter(slots=["<|observation|>\n{{content}}<|assistant|>"]),
stop_words=["<|user|>", "<|observation|>"],
efficient_eos=True,
force_system=True,
)
我改成这样好了。

_register_template(     name="glm4",     # format_user=StringFormatter(slots=["<|user|>\n{{content}}<|assistant|>"]),     # format_assistant=StringFormatter(slots=["\n{{content}}"]),     format_user=StringFormatter(slots=["<|user|>\n{{content}}<|assistant|>\n"]),     format_assistant=StringFormatter(slots=["{{content}}"]),     format_system=StringFormatter(slots=["[gMASK]<sop>{{content}}"]),     format_function=FunctionFormatter(slots=["{{name}}\n{{arguments}}"]),     format_observation=StringFormatter(slots=["<|observation|>\n{{content}}<|assistant|>"]),     stop_words=["<|user|>", "<|observation|>"],     efficient_eos=True,     force_system=True, )
我改成这样好了。

_register_template(
name="glm4",
# format_user=StringFormatter(slots=["<|user|>\n{{content}}<|assistant|>"]),
# format_assistant=StringFormatter(slots=["\n{{content}}"]),
format_user=StringFormatter(slots=["<|user|>\n{{content}}<|assistant|>\n"]),
format_assistant=StringFormatter(slots=["{{content}}"]),
format_system=StringFormatter(slots=["[gMASK]{{content}}"]),
format_function=FunctionFormatter(slots=["{{name}}\n{{arguments}}"]),
format_observation=StringFormatter(slots=["<|observation|>\n{{content}}<|assistant|>"]),
stop_words=["<|user|>", "<|observation|>"],
efficient_eos=True,
force_system=True,
)
改成这样好了。

_register_template( name="glm4", # format_user=StringFormatter(slots=["<|user|>\n{{content}}<|assistant|>"]), # format_assistant=StringFormatter(slots=["\n{{content}}"]), format_user=StringFormatter(slots=["<|user|>\n{{content}}<|assistant|>\n"]), format_assistant=StringFormatter(slots=["{{content}}"]), format_system=StringFormatter(slots=["[gMASK]{{content}}"]), format_function=FunctionFormatter(slots=["{{name}}\n{{arguments}}"]), format_observation=StringFormatter(slots=["<|observation|>\n{{content}}<|assistant|>"]), stop_words=["<|user|>", "<|observation|>"], efficient_eos=True, force_system=True, )
改成这样不会出现\n了。

好的感谢～

authors: coasxu sunpenglv


text:
我在腾讯云中全量微调8B的llama架构128k上下文模型，我很确信JSON解析错误不来源于数据集和模型config，仍有json.decoder.JSONDecodeError: Expecting value: line 1 column 2 (char 1)。

Reminder

[x] I have read the README and searched the existing issues.

System Info
[2024-07-24 14:55:53,299] [INFO] [real_accelerator.py:203:get_accelerator] Setting ds_accelerator to cuda (auto detect)
[WARNING]  async_io requires the dev libaio .so object and headers but these were not found.
[WARNING]  async_io: please install the libaio-dev package with apt
[WARNING]  If libaio is already installed (perhaps from source), try setting the CFLAGS and LDFLAGS environment variables to where it can be found.
[WARNING]  Please specify the CUTLASS repo directory as environment variable $CUTLASS_PATH
[WARNING]  sparse_attn requires a torch version >= 1.5 and < 2.0 but detected 2.3
[WARNING]  using untested triton version (2.3.0), only 1.0.0 is known to be compatible

llamafactory version: 0.8.3.dev0
Platform: Linux-5.4.119-19.0009.28-x86_64-with-glibc2.31
Python version: 3.9.0
PyTorch version: 2.3.0+cu121 (GPU)
Transformers version: 4.42.4
Datasets version: 2.20.0
Accelerate version: 0.32.1
PEFT version: 0.11.1
TRL version: 0.8.6
GPU type: NVIDIA H800
DeepSpeed version: 0.14.4
Bitsandbytes version: 0.43.1
vLLM version: 0.4.2

Reproduction
llamafactory-cli train examples/train_full/llama3_full_sft_ds3.yaml
model
model_name_or_path: /home/tione/notebook/checkpoint-200
method
stage: sft
do_train: true
finetuning_type: full
deepspeed: examples/deepspeed/ds_z3_offload_config.json
dataset
dataset: mixed_data
template: llama3
cutoff_len: 36000
max_samples: 1000
overwrite_cache: true
preprocessing_num_workers: 16
output
output_dir: saves/ours/full/sft
logging_steps: 10
save_steps: 500
plot_loss: true
overwrite_output_dir: true
train
per_device_train_batch_size: 1
gradient_accumulation_steps: 2
learning_rate: 1.0e-4
num_train_epochs: 10.0
lr_scheduler_type: cosine
warmup_ratio: 0.1
bf16: true
ddp_timeout: 180000000
flash_attn: fa2
eval
val_size: 0.1
per_device_eval_batch_size: 1
eval_strategy: steps
eval_steps: 500
Expected behavior
这段代码用于全量微调8B的128k上下文模型。
Others

你可以不用本项目，用原生 transformers 做一下推理看看。

如果数据集里面存在单引号，替换成双引号，试试

这个是腾讯云 TI 平台旁路工具网络问题导致，不影响训练，已经修复了。

这是腾讯云 TI 平台执行工具异常报错，实际不影响训练的

版本的问题  满足这个条件datasets=2.20.0 requires pandas>=2.0.0


text:
🛑 HJStrauss is down

In bb67b5e, HJStrauss (https://www.hjstrauss.de) was down:

HTTP code: 0
Response time: 0 ms

Resolved: HJStrauss is back up in 273fb43 after 9 minutes.

repo: hjstrauss/MonitorMySites


text:
🛑 Griffo is down

In 47d001f, Griffo (https://www.griffo.de) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Griffo is back up in 726c940 after 9 minutes.


text:
🛑 Opa Hansi is down

In 6d21156, Opa Hansi (https://www.opahansi.de) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Opa Hansi is back up in a999dfc after 14 minutes.


text:
Discipline

BePractitioner als bron? Combinatie worden van codes...
Hans De Keersmaecker vraagt om dit aan het terminologiecentrum door te geven.

BePractitionerRole currently uses http://hl7.org/fhir/R4/valueset-practitioner-role.html

Asked to become a member of https://csct.be/ , so that we can ask SNOMED-CT questions, because the NRC does not answer our questions.

@annenerenhausen will provide the SNOMED-CT

#167

WG: we will use the codes provided in the document #167 as a temporary valueset (but even this one is not complete, so we wait for input by @annenerenhausen ) and have it replaced by SNOMED CT later.

WG: we will receive the list today.

updated in #205

The list in #205 is the same as in cd-hcparty

WG: this is the final set for phase 1


text:
Fix vterm popup rule

akermu/emacs-libvterm@c2c2c8afb935c11778388721912250cd1103aaf9 changed
the default buffer name of vterm buffers, so Doom's popup-rule no longer
matches them. This causes functions like +vterm/here to use the entire
frame instead of creating a popup window.
Fix it by changing the popup rule to match the new naming scheme.

Thanks!

authors: hlissner marienz

repo: hlissner/doom-emacs


text:
FileField metadata isn't persisted correctly

I'm using the first method from the "Writing" section to store a file and its content_type:
http://mongoengine.org/docs/v0.5/guide/gridfs.html
You can set the FileField and its content type, but objects returned from a query have their content_type set to None.  FYI, using the put() method seems to work fine.

I suggest two methods to set_data (name, value) and get_data (name)

authors: chrismrivera wpjunior

repo: hmarr/mongoengine


text:
DTSAM-524 Test existing RAS pagination

Jira link
DTSAM-573 "RAS pagination issues: always add ID sort to paginated queries, use a large page size for internal uses of the query routines"
Change description
Remove temporary override of RAS image name so we can test existing RAS pagination with data loaded from ORM.

NB: This is a test PR to test without hmcts/am-role-assignment-service#2354 fix applied.  See also #2123.

Closed as ticket number wrong in brach and PR

repo: hmcts/am-org-role-mapping-service


text:
Docstore pt

Before creating a pull request make sure that:

[ ] commit messages are meaningful and follow good commit message guidelines
[ ] README and other documentation has been updated / added (if needed)
[ ] tests have been updated / new tests has been added (if needed)

Please remove this line and everything above and fill the following sections:
JIRA link (if applicable)
Change description
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[ ] No

no longer needed because we have created a repository for doc store performance tests

repo: hmcts/ccd-test-performance


text:
CIV-5243 Remove caseworker-civil-admin

Before creating a pull request make sure that:

[x] commit messages are meaningful and follow good commit message guidelines
[x] README and other documentation has been updated / added (if needed)
[x] tests have been updated / new tests has been added (if needed)

Please remove this line and everything above and fill the following sections:
JIRA link (if applicable)
https://tools.hmcts.net/jira/browse/CIV-5243
Change description
Remove caseworker-civil-admin
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[ ] No

repo: hmcts/civil-ccd-definition


text:
feature/help with fees additional apllication

JIRA link (if applicable)
https://tools.hmcts.net/jira/browse/PRL-3723
Change description
Changes for help with fees for additional applications
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[x] No

Have closed to save pods

Closed to reduce pods

repo: hmcts/prl-cos-api


text:
VIH-7550 Mutation test fixes

JIRA link (if applicable)
VIH-7550
Change description

Mutation test fixes

Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[X] No

/azp run

/azp run

repo: hmcts/vh-test-api


text:
Disclosure control not appearing in Voiceover Rotor

The current disclosure control (aka details element) is not appearing in the Voiceover Rotor under Form Controls in Safari. Still appears in Chrome.
The older version (in Gov UK Elements) does, but requires some modification to ensure links inside the component's body do not receive focus. See https://gist.github.com/adamliptrot-oc/6db079ddd1cd46030418f62e9fab3839
Bug reported to Webkit:

Using this page as a testbed:
https://design-system.service.gov.uk/components/details/default/index.html
When navigating to the element with Voiceover the following is announced:
"You are currently on a summary. To click this button press Control, Option, Space"
but the element does not appear in Voiceover's Rotor
Expected behaviour:
The element appears in the Form Controls section of the Rotor
Actual behaviour:
The element does not appear in any section of the Rotor
Seen with Safari 13 and in Safari Tecnology Preview Release 105

https://bugs.webkit.org/show_bug.cgi?id=211284

Will test this on iPhone and update with findings.

repo: hmrc/accessibility


text:
PPTP-1693 - Disable business verification for partners

Description of Work carried through
Brief description of what/why/how.
Check list

[x] ./precheck was executed (Integration/Component/Unit tests)
[x] sbt scalafmt test:scalafmt was executed

Are there any tests to cover this change?

Are there any tests to cover this change?

I have added the tests

authors: kiranprakashdigital paulblakehmrc


text:
Obtain full URL from config file

No longer append the endpoint, have the user
specify the full URL.

This commit was dropped when merging local-write-back branch to main.

repo: hms-networks/flexy-thingworx-connector


text:
Update mill-main, mill-scalalib to 0.11.10

About this PR
📦 Updates

com.lihaoyi:mill-main
com.lihaoyi:mill-scalalib

from 0.11.7 to 0.11.10
📜 GitHub Release Notes - Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.lihaoyi" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "com.lihaoyi" }
}]

labels: library-update, early-semver-minor, semver-spec-patch, commit-count:1

Superseded by #20.

repo: hoangmaihuy/mill-scala-tsi