queue-proxy container image is not set in the KnativeService's pod when configured in the charm

Bug Description
Hit this issue while testing CKF 1.8 in airgapped (related to https://github.com/canonical/bundle-kubeflow/issues/889 and https://github.com/canonical/bundle-kubeflow/issues/898):
When configuring the queue-proxy image in the custom images, then creating a KnativeService, the queue-proxy image in the KnativeService gets the default value, not the one configured in the charm.
This is a blocker for using KNative in an airgapped environment.
See https://github.com/canonical/knative-operators/issues/140 for context on configuring the custom images.
Looking at the knative-serving charm's config, we can see that the custom image is set there:
juju config knative-serving custom_images
activator: <IP_ADDRESS>:5000/knative-releases/knative.dev/serving/cmd/activator:c2994c2b6c2c7f38ad1b85c71789bf1753cc8979926423c83231e62258837cb9
autoscaler: <IP_ADDRESS>:5000/knative-releases/knative.dev/serving/cmd/autoscaler:8319aa662b4912e8175018bd7cc90c63838562a27515197b803bdcd5634c7007
controller: <IP_ADDRESS>:5000/knative-releases/knative.dev/serving/cmd/controller:98a2cc7fd62ee95e137116504e7166c32c65efef42c3d1454630780410abf943
webhook: <IP_ADDRESS>:5000/knative-releases/knative.dev/serving/cmd/webhook:4305209ce498caf783f39c8f3e85dfa635ece6947033bf50b0b627983fd65953
autoscaler-hpa: <IP_ADDRESS>:5000/knative-releases/knative.dev/serving/cmd/autoscaler-hpa:eb612b929eaa57ef1573a04035a8d06c9ed88fd56e741c56bd909f5f49e4d732
net-istio-controller/controller: <IP_ADDRESS>:5000/knative-releases/knative.dev/net-istio/cmd/controller:27e7beb7c62036216fc464fb2181e56b030158ad4ceb57a7de172f54b4fe43db
net-istio-webhook/webhook: <IP_ADDRESS>:5000/knative-releases/knative.dev/net-istio/cmd/webhook:0cdef272e39c57971ce9977765f164dd8e3abb9395a4f60e7a4160d57dcc09f2
queue-proxy: <IP_ADDRESS>:5000/knative-releases/knative.dev/serving/cmd/queue:dabaecec38860ca4c972e6821d5dc825549faf50c6feb8feb4c04802f2338b8a
domain-mapping: <IP_ADDRESS>:5000/knative-releases/knative.dev/serving/cmd/domain-mapping:f66c41ad7a73f5d4f4bdfec4294d5459c477f09f3ce52934d1a215e32316b59b
domainmapping-webhook: <IP_ADDRESS>:5000/knative-releases/knative.dev/serving/cmd/domain-mapping-webhook:7368aaddf2be8d8784dc7195f5bc272ecfe49d429697f48de0ddc44f278167aa

and Looking at the KnativeServing CR, we can see that the queue-proxy field is set there correctly in the registry section:
apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  creationTimestamp: "2024-05-28T12:09:54Z"
  finalizers:
  - knativeservings.operator.knative.dev
  generation: 2
  name: knative-serving
  namespace: knative-serving
  resourceVersion: "548475"
  uid: 2600de7a-1c4a-4dc6-a14e-aa9fd15fe19d
spec:
  config:
    domain:
      <IP_ADDRESS>.nip.io: ""
    istio:
      gateway.kubeflow.kubeflow-gateway: some-workload.knative-operator.svc.cluster.local
      local-gateway.knative-serving.knative-local-gateway: knative-local-gateway.kubeflow.svc.cluster.local
  registry:
    override:
      activator: <IP_ADDRESS>:5000/knative-releases/knative.dev/serving/cmd/activator:c2994c2b6c2c7f38ad1b85c71789bf1753cc8979926423c83231e62258837cb9
      autoscaler: <IP_ADDRESS>:5000/knative-releases/knative.dev/serving/cmd/autoscaler:8319aa662b4912e8175018bd7cc90c63838562a27515197b803bdcd5634c7007
      autoscaler-hpa: <IP_ADDRESS>:5000/knative-releases/knative.dev/serving/cmd/autoscaler-hpa:eb612b929eaa57ef1573a04035a8d06c9ed88fd56e741c56bd909f5f49e4d732
      controller: <IP_ADDRESS>:5000/knative-releases/knative.dev/serving/cmd/controller:98a2cc7fd62ee95e137116504e7166c32c65efef42c3d1454630780410abf943
      domain-mapping: <IP_ADDRESS>:5000/knative-releases/knative.dev/serving/cmd/domain-mapping:f66c41ad7a73f5d4f4bdfec4294d5459c477f09f3ce52934d1a215e32316b59b
      domainmapping-webhook: <IP_ADDRESS>:5000/knative-releases/knative.dev/serving/cmd/domain-mapping-webhook:7368aaddf2be8d8784dc7195f5bc272ecfe49d429697f48de0ddc44f278167aa
      net-istio-controller/controller: <IP_ADDRESS>:5000/knative-releases/knative.dev/net-istio/cmd/controller:27e7beb7c62036216fc464fb2181e56b030158ad4ceb57a7de172f54b4fe43db
      net-istio-webhook/webhook: <IP_ADDRESS>:5000/knative-releases/knative.dev/net-istio/cmd/webhook:0cdef272e39c57971ce9977765f164dd8e3abb9395a4f60e7a4160d57dcc09f2
      queue-proxy: <IP_ADDRESS>:5000/knative-releases/knative.dev/serving/cmd/queue:dabaecec38860ca4c972e6821d5dc825549faf50c6feb8feb4c04802f2338b8a
      webhook: <IP_ADDRESS>:5000/knative-releases/knative.dev/serving/cmd/webhook:4305209ce498caf783f39c8f3e85dfa635ece6947033bf50b0b627983fd65953
  version: 1.10.2
status:
  conditions:
  - lastTransitionTime: "2024-05-28T12:12:20Z"
    status: "True"
    type: DependenciesInstalled
  - lastTransitionTime: "2024-05-29T10:48:32Z"
    status: "True"
    type: DeploymentsAvailable
  - lastTransitionTime: "2024-05-28T12:12:20Z"
    status: "True"
    type: InstallSucceeded
  - lastTransitionTime: "2024-05-29T10:48:32Z"
    status: "True"
    type: Ready
  - lastTransitionTime: "2024-05-28T12:12:02Z"
    status: "True"
    type: VersionMigrationEligible
  manifests:
  - /var/run/ko/knative-serving/1.10.2
  - /var/run/ko/ingress/1.10/istio
  observedGeneration: 2
  version: 1.10.2

However, it is not getting picked up by the KnativeService CR's Pod:
Image:          gcr.io/knative-releases/knative.dev/serving/cmd/queue@sha256:dabaecec38860ca4c972e6821d5dc825549faf50c6feb8feb4c04802f2338b8a

It still sets the default image in the container^
To Reproduce

Deploy CKF 1.8/stable in airgapped
Configure the queue-proxy image to the image in the local registry, in my case I set it to <IP_ADDRESS>:5000/knative-releases/knative.dev/serving/cmd/queue:dabaecec38860ca4c972e6821d5dc825549faf50c6feb8feb4c04802f2338b8a
Create this KnativeService example:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld
  namespace: admin
spec:
  template:
    spec:
      containers:
      - image: python:3.11.9-alpine
        command: [sleep, "3600"]
        ports:
          - containerPort: 8080
        env:
          - name: TARGET
            value: "World"

Check the queue-proxy image in the KnativeService pod:

pod description
kubectl describe po helloworld-00001-deployment-854f6f5f6d-sfbbf -nadmin
Name:             helloworld-00001-deployment-854f6f5f6d-sfbbf
Namespace:        admin
Priority:         0
Service Account:  default
Node:             airgapped-microk8s/<IP_ADDRESS>
Start Time:       Wed, 29 May 2024 11:10:03 +0000
Labels:           app=helloworld-00001
                  pod-template-hash=854f6f5f6d
                  security.istio.io/tlsMode=istio
                  service.istio.io/canonical-name=helloworld
                  service.istio.io/canonical-revision=helloworld-00001
                  serving.knative.dev/configuration=helloworld
                  serving.knative.dev/configurationGeneration=1
                  serving.knative.dev/configurationUID=135fa2d4-7270-4607-91b0-c859ec89af71
                  serving.knative.dev/revision=helloworld-00001
                  serving.knative.dev/revisionUID=82e82ada-8e20-4993-9158-9099212b0bee
                  serving.knative.dev/service=helloworld
                  serving.knative.dev/serviceUID=553ba036-a8d3-414b-b941-fab4a2263010
Annotations:      cni.projectcalico.org/containerID: d7341aeb83813809a63340ba03907673cd4a37d4060f7bf9135182b254f67c0e
                  cni.projectcalico.org/podIP: <IP_ADDRESS>/32
                  cni.projectcalico.org/podIPs: <IP_ADDRESS>/32
                  kubectl.kubernetes.io/default-container: user-container
                  kubectl.kubernetes.io/default-logs-container: user-container
                  prometheus.io/path: /stats/prometheus
                  prometheus.io/port: 15020
                  prometheus.io/scrape: true
                  serving.knative.dev/creator: admin
                  sidecar.istio.io/status:
                    {"initContainers":["istio-init"],"containers":["istio-proxy"],"volumes":["workload-socket","credential-socket","workload-certs","istio-env...
Status:           Pending
IP:               <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  ReplicaSet/helloworld-00001-deployment-854f6f5f6d
Init Containers:
  istio-init:
    Container ID:  containerd://60baff0104f694b5610059afbacdf0fe2b2bf9f9e7b6190350bcccdd45bad030
    Image:         <IP_ADDRESS>:5000/istio/proxyv2:1.17.3
    Image ID:      <IP_ADDRESS>:5000/istio/proxyv2@sha256:ea9373309e35569cf2a011e973aa1f49e0354fd2d730e8a0d5cc25964499a100
    Port:          <none>
    Host Port:     <none>
    Args:
      istio-iptables
      -p
      15001
      -z
      15006
      -u
      1337
      -m
      REDIRECT
      -i
      *
      -x

      -b
      *
      -d
      15090,15021,15020
      --log_output_level=default:info
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Wed, 29 May 2024 11:10:05 +0000
      Finished:     Wed, 29 May 2024 11:10:05 +0000
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:     2
      memory:  1Gi
    Requests:
      cpu:        100m
      memory:     128Mi
    Environment:  <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-m7szg (ro)
Containers:
  user-container:
    Container ID:  containerd://ea66e01e58b900ce3a0d3abb839086f10005272e40337a6b53a7c327e42af696
    Image:         <IP_ADDRESS>:5000/python@sha256:df44c0c0761ddbd6388f4549cab42d24d64d257c2a960ad5b276bb7dab9639c7
    Image ID:      <IP_ADDRESS>:5000/python@sha256:df44c0c0761ddbd6388f4549cab42d24d64d257c2a960ad5b276bb7dab9639c7
    Port:          8080/TCP
    Host Port:     0/TCP
    Command:
      sleep
      3600
    State:          Running
      Started:      Wed, 29 May 2024 11:10:06 +0000
    Ready:          True
    Restart Count:  0
    Environment:
      TARGET:           World
      PORT:             8080
      K_REVISION:       helloworld-00001
      K_CONFIGURATION:  helloworld
      K_SERVICE:        helloworld
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-m7szg (ro)
  queue-proxy:
    Container ID:
    Image:          gcr.io/knative-releases/knative.dev/serving/cmd/queue@sha256:dabaecec38860ca4c972e6821d5dc825549faf50c6feb8feb4c04802f2338b8a
    Image ID:
    Ports:          8022/TCP, 9090/TCP, 9091/TCP, 8012/TCP, 8112/TCP
    Host Ports:     0/TCP, 0/TCP, 0/TCP, 0/TCP, 0/TCP
    State:          Waiting
      Reason:       ErrImagePull
    Ready:          False
    Restart Count:  0
    Requests:
      cpu:      25m
    Readiness:  http-get http://:15020/app-health/queue-proxy/readyz delay=0s timeout=1s period=10s #success=1 #failure=3
    Environment:
      SERVING_NAMESPACE:                        admin
      SERVING_SERVICE:                          helloworld
      SERVING_CONFIGURATION:                    helloworld
      SERVING_REVISION:                         helloworld-00001
      QUEUE_SERVING_PORT:                       8012
      QUEUE_SERVING_TLS_PORT:                   8112
      CONTAINER_CONCURRENCY:                    0
      REVISION_TIMEOUT_SECONDS:                 300
      REVISION_RESPONSE_START_TIMEOUT_SECONDS:  0
      REVISION_IDLE_TIMEOUT_SECONDS:            0
      SERVING_POD:                              helloworld-00001-deployment-854f6f5f6d-sfbbf (v1:metadata.name)
      SERVING_POD_IP:                            (v1:status.podIP)
      SERVING_LOGGING_CONFIG:
      SERVING_LOGGING_LEVEL:
      SERVING_REQUEST_LOG_TEMPLATE:             {"httpRequest": {"requestMethod": "{{.Request.Method}}", "requestUrl": "{{js .Request.RequestURI}}", "requestSize": "{{.Request.ContentLength}}", "status": {{.Response.Code}}, "responseSize": "{{.Response.Size}}", "userAgent": "{{js .Request.UserAgent}}", "remoteIp": "{{js .Request.RemoteAddr}}", "serverIp": "{{.Revision.PodIP}}", "referer": "{{js .Request.Referer}}", "latency": "{{.Response.Latency}}s", "protocol": "{{.Request.Proto}}"}, "traceId": "{{index .Request.Header "X-B3-Traceid"}}"}
      SERVING_ENABLE_REQUEST_LOG:               false
      SERVING_REQUEST_METRICS_BACKEND:          prometheus
      TRACING_CONFIG_BACKEND:                   none
      TRACING_CONFIG_ZIPKIN_ENDPOINT:
      TRACING_CONFIG_DEBUG:                     false
      TRACING_CONFIG_SAMPLE_RATE:               0.1
      USER_PORT:                                8080
      SYSTEM_NAMESPACE:                         knative-serving
      METRICS_DOMAIN:                           knative.dev/internal/serving
      SERVING_READINESS_PROBE:                  {"tcpSocket":{"port":8080,"host":"<IP_ADDRESS>"},"successThreshold":1}
      ENABLE_PROFILING:                         false
      SERVING_ENABLE_PROBE_REQUEST_LOG:         false
      METRICS_COLLECTOR_ADDRESS:
      HOST_IP:                                   (v1:status.hostIP)
      ENABLE_HTTP2_AUTO_DETECTION:              false
      ROOT_CA:
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-m7szg (ro)
  istio-proxy:
    Container ID:  containerd://afcad5017289db34701349ee19e7017b1573950ae909e73d32b574d5f31b7f27
    Image:         <IP_ADDRESS>:5000/istio/proxyv2:1.17.3
    Image ID:      <IP_ADDRESS>:5000/istio/proxyv2@sha256:ea9373309e35569cf2a011e973aa1f49e0354fd2d730e8a0d5cc25964499a100
    Port:          15090/TCP
    Host Port:     0/TCP
    Args:
      proxy
      sidecar
      --domain
      $(POD_NAMESPACE).svc.cluster.local
      --proxyLogLevel=warning
      --proxyComponentLogLevel=misc:error
      --log_output_level=default:info
      --concurrency
      2
    State:          Running
      Started:      Wed, 29 May 2024 11:10:13 +0000
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:     2
      memory:  1Gi
    Requests:
      cpu:      100m
      memory:   128Mi
    Readiness:  http-get http://:15021/healthz/ready delay=1s timeout=3s period=2s #success=1 #failure=30
    Environment:
      JWT_POLICY:                    third-party-jwt
      PILOT_CERT_PROVIDER:           istiod
      CA_ADDR:                       istiod.kubeflow.svc:15012
      POD_NAME:                      helloworld-00001-deployment-854f6f5f6d-sfbbf (v1:metadata.name)
      POD_NAMESPACE:                 admin (v1:metadata.namespace)
      INSTANCE_IP:                    (v1:status.podIP)
      SERVICE_ACCOUNT:                (v1:spec.serviceAccountName)
      HOST_IP:                        (v1:status.hostIP)
      PROXY_CONFIG:                  {"discoveryAddress":"istiod.kubeflow.svc:15012","tracing":{"zipkin":{"address":"zipkin.kubeflow:9411"}}}

      ISTIO_META_POD_PORTS:          [
                                         {"name":"user-port","containerPort":8080,"protocol":"TCP"}
                                         ,{"name":"http-queueadm","containerPort":8022,"protocol":"TCP"}
                                         ,{"name":"http-autometric","containerPort":9090,"protocol":"TCP"}
                                         ,{"name":"http-usermetric","containerPort":9091,"protocol":"TCP"}
                                         ,{"name":"queue-port","containerPort":8012,"protocol":"TCP"}
                                         ,{"name":"https-port","containerPort":8112,"protocol":"TCP"}
                                     ]
      ISTIO_META_APP_CONTAINERS:     user-container,queue-proxy
      ISTIO_META_CLUSTER_ID:         Kubernetes
      ISTIO_META_NODE_NAME:           (v1:spec.nodeName)
      ISTIO_META_INTERCEPTION_MODE:  REDIRECT
      ISTIO_META_WORKLOAD_NAME:      helloworld-00001-deployment
      ISTIO_META_OWNER:              kubernetes://apis/apps/v1/namespaces/admin/deployments/helloworld-00001-deployment
      ISTIO_META_MESH_ID:            cluster.local
      TRUST_DOMAIN:                  cluster.local
      ISTIO_KUBE_APP_PROBERS:        {"/app-health/queue-proxy/readyz":{"httpGet":{"path":"/","port":8012,"scheme":"HTTP","httpHeaders":[{"name":"K-Network-Probe","value":"queue"}]},"timeoutSeconds":1}}
    Mounts:
      /etc/istio/pod from istio-podinfo (rw)
      /etc/istio/proxy from istio-envoy (rw)
      /var/lib/istio/data from istio-data (rw)
      /var/run/secrets/credential-uds from credential-socket (rw)
      /var/run/secrets/istio from istiod-ca-cert (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-m7szg (ro)
      /var/run/secrets/tokens from istio-token (rw)
      /var/run/secrets/workload-spiffe-credentials from workload-certs (rw)
      /var/run/secrets/workload-spiffe-uds from workload-socket (rw)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  workload-socket:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  <unset>
  credential-socket:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  <unset>
  workload-certs:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  <unset>
  istio-envoy:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:     Memory
    SizeLimit:  <unset>
  istio-data:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  <unset>
  istio-podinfo:
    Type:  DownwardAPI (a volume populated by information about the pod)
    Items:
      metadata.labels -> labels
      metadata.annotations -> annotations
  istio-token:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  43200
  istiod-ca-cert:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      istio-ca-root-cert
    Optional:  false
  kube-api-access-m7szg:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   Burstable
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  87s                default-scheduler  Successfully assigned admin/helloworld-00001-deployment-854f6f5f6d-sfbbf to airgapped-microk8s
  Normal   Pulled     86s                kubelet            Container image "<IP_ADDRESS>:5000/istio/proxyv2:1.17.3" already present on machine
  Normal   Created    85s                kubelet            Created container istio-init
  Normal   Started    85s                kubelet            Started container istio-init
  Normal   Pulled     85s                kubelet            Container image "<IP_ADDRESS>:5000/python@sha256:df44c0c0761ddbd6388f4549cab42d24d64d257c2a960ad5b276bb7dab9639c7" already present on machine
  Normal   Created    84s                kubelet            Created container user-container
  Normal   Started    84s                kubelet            Started container user-container
  Normal   Pulled     78s                kubelet            Container image "<IP_ADDRESS>:5000/istio/proxyv2:1.17.3" already present on machine
  Normal   Created    77s                kubelet            Created container istio-proxy
  Normal   Started    77s                kubelet            Started container istio-proxy
  Warning  Failed     54s (x2 over 78s)  kubelet            Error: ErrImagePull
  Normal   BackOff    40s (x4 over 77s)  kubelet            Back-off pulling image "gcr.io/knative-releases/knative.dev/serving/cmd/queue@sha256:dabaecec38860ca4c972e6821d5dc825549faf50c6feb8feb4c04802f2338b8a"
  Warning  Failed     40s (x4 over 77s)  kubelet            Error: ImagePullBackOff
  Normal   Pulling    29s (x3 over 84s)  kubelet            Pulling image "gcr.io/knative-releases/knative.dev/serving/cmd/queue@sha256:dabaecec38860ca4c972e6821d5dc825549faf50c6feb8feb4c04802f2338b8a"
  Warning  Failed     23s (x3 over 78s)  kubelet            Failed to pull image "gcr.io/knative-releases/knative.dev/serving/cmd/queue@sha256:dabaecec38860ca4c972e6821d5dc825549faf50c6feb8feb4c04802f2338b8a": rpc error: code = Unknown desc = failed to pull and unpack image "gcr.io/knative-releases/knative.dev/serving/cmd/queue@sha256:dabaecec38860ca4c972e6821d5dc825549faf50c6feb8feb4c04802f2338b8a": failed to resolve reference "gcr.io/knative-releases/knative.dev/serving/cmd/queue@sha256:dabaecec38860ca4c972e6821d5dc825549faf50c6feb8feb4c04802f2338b8a": failed to do request: Head "https://gcr.io/v2/knative-releases/knative.dev/serving/cmd/queue/manifests/sha256:dabaecec38860ca4c972e6821d5dc825549faf50c6feb8feb4c04802f2338b8a": dial tcp <IP_ADDRESS>:443: connect: no route to host

Environment
airgapped environment
microk8s 1.25-strict/stable
juju 3.1/stable
Relevant Log Output
Failed to pull image "gcr.io/knative-releases/knative.dev/serving/cmd/queue@sha256:dabaecec38860ca4c972e6821d5dc825549faf50c6feb8feb4c04802f2338b8a": rpc error: code = Unknown desc = failed to pull and unpack image "gcr.io/knative-releases/knative.dev/serving/cmd/queue@sha256:dabaecec38860ca4c972e6821d5dc825549faf50c6feb8feb4c04802f2338b8a": failed to resolve reference "gcr.io/knative-releases/knative.dev/serving/cmd/queue@sha256:dabaecec38860ca4c972e6821d5dc825549faf50c6feb8feb4c04802f2338b8a": failed to do request: Head "https://gcr.io/v2/knative-releases/knative.dev/serving/cmd/queue/manifests/sha256:dabaecec38860ca4c972e6821d5dc825549faf50c6feb8feb4c04802f2338b8a": dial tcp <IP_ADDRESS>:443: connect: no route to host

Additional Context
No response

Looking a bit around in upstream manifests, it looks like we need to configure the queue-proxy image in this place of the manifests
https://github.com/kubeflow/manifests/blob/v1.8.0/common/knative/knative-serving/base/upstream/serving-core.yaml#L4667
We'll need to ensure we can configure this also via the KnativeServing CR

Thanks @kimwnasptd for the pointers.
Inspecting my airgapped cluster, indeed I see the queue-sidecar-image set to the upstream image in config-deployment ConfigMap in the knative-serving namespace:
kubectl get ConfigMap -n knative-serving config-deployment -oyaml
apiVersion: v1
data:
  _example: |-
    ################################
    #                              #
    #    EXAMPLE CONFIGURATION     #
    #                              #
    ################################

    # This block is not actually functional configuration,
    # but serves to illustrate the available configuration
    # options and document them in a way that is accessible
    # to users that `kubectl edit` this config map.
    #
    # These sample configuration options may be copied out of
    # this example block and unindented to be in the data block
    # to actually change the configuration.

    # List of repositories for which tag to digest resolving should be skipped
    registries-skipping-tag-resolving: "kind.local,ko.local,dev.local"

    # Maximum time allowed for an image's digests to be resolved.
    digest-resolution-timeout: "10s"

    # Duration we wait for the deployment to be ready before considering it failed.
    progress-deadline: "600s"

    # Sets the queue proxy's CPU request.
    # If omitted, a default value (currently "25m"), is used.
    queue-sidecar-cpu-request: "25m"

    # Sets the queue proxy's CPU limit.
    # If omitted, no value is specified and the system default is used.
    queue-sidecar-cpu-limit: "1000m"

    # Sets the queue proxy's memory request.
    # If omitted, no value is specified and the system default is used.
    queue-sidecar-memory-request: "400Mi"

    # Sets the queue proxy's memory limit.
    # If omitted, no value is specified and the system default is used.
    queue-sidecar-memory-limit: "800Mi"

    # Sets the queue proxy's ephemeral storage request.
    # If omitted, no value is specified and the system default is used.
    queue-sidecar-ephemeral-storage-request: "512Mi"

    # Sets the queue proxy's ephemeral storage limit.
    # If omitted, no value is specified and the system default is used.
    queue-sidecar-ephemeral-storage-limit: "1024Mi"

    # Sets tokens associated with specific audiences for queue proxy - used by QPOptions
    #
    # For example, to add the `service-x` audience:
    #    queue-sidecar-token-audiences: "service-x"
    # Also supports a list of audiences, for example:
    #    queue-sidecar-token-audiences: "service-x,service-y"
    # If omitted, or empty, no tokens are created
    queue-sidecar-token-audiences: ""

    # Sets rootCA for the queue proxy - used by QPOptions
    # If omitted, or empty, no rootCA is added to the golang rootCAs
    queue-sidecar-rootca: ""
  queue-sidecar-image: gcr.io/knative-releases/knative.dev/serving/cmd/queue@sha256:dabaecec38860ca4c972e6821d5dc825549faf50c6feb8feb4c04802f2338b8a
kind: ConfigMap
metadata:
  annotations:
    knative.dev/example-checksum: 410041a0
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{"_example":"################################\n#                              #\n#    EXAMPLE CONFIGURATION     #\n#                              #\n################################\n\n# This block is not actually functional configuration,\n# but serves to illustrate the available configuration\n# options and document them in a way that is accessible\n# to users that `kubectl edit` this config map.\n#\n# These sample configuration options may be copied out of\n# this example block and unindented to be in the data block\n# to actually change the configuration.\n\n# List of repositories for which tag to digest resolving should be skipped\nregistries-skipping-tag-resolving: \"kind.local,ko.local,dev.local\"\n\n# Maximum time allowed for an image's digests to be resolved.\ndigest-resolution-timeout: \"10s\"\n\n# Duration we wait for the deployment to be ready before considering it failed.\nprogress-deadline: \"600s\"\n\n# Sets the queue proxy's CPU request.\n# If omitted, a default value (currently \"25m\"), is used.\nqueue-sidecar-cpu-request: \"25m\"\n\n# Sets the queue proxy's CPU limit.\n# If omitted, no value is specified and the system default is used.\nqueue-sidecar-cpu-limit: \"1000m\"\n\n# Sets the queue proxy's memory request.\n# If omitted, no value is specified and the system default is used.\nqueue-sidecar-memory-request: \"400Mi\"\n\n# Sets the queue proxy's memory limit.\n# If omitted, no value is specified and the system default is used.\nqueue-sidecar-memory-limit: \"800Mi\"\n\n# Sets the queue proxy's ephemeral storage request.\n# If omitted, no value is specified and the system default is used.\nqueue-sidecar-ephemeral-storage-request: \"512Mi\"\n\n# Sets the queue proxy's ephemeral storage limit.\n# If omitted, no value is specified and the system default is used.\nqueue-sidecar-ephemeral-storage-limit: \"1024Mi\"\n\n# Sets tokens associated with specific audiences for queue proxy - used by QPOptions\n#\n# For example, to add the `service-x` audience:\n#    queue-sidecar-token-audiences: \"service-x\"\n# Also supports a list of audiences, for example:\n#    queue-sidecar-token-audiences: \"service-x,service-y\"\n# If omitted, or empty, no tokens are created\nqueue-sidecar-token-audiences: \"\"\n\n# Sets rootCA for the queue proxy - used by QPOptions\n# If omitted, or empty, no rootCA is added to the golang rootCAs\nqueue-sidecar-rootca: \"\"","queue-sidecar-image":"gcr.io/knative-releases/knative.dev/serving/cmd/queue@sha256:dabaecec38860ca4c972e6821d5dc825549faf50c6feb8feb4c04802f2338b8a"},"kind":"ConfigMap","metadata":{"annotations":{"knative.dev/example-checksum":"410041a0"},"labels":{"app.kubernetes.io/component":"controller","app.kubernetes.io/name":"knative-serving","app.kubernetes.io/version":"1.10.2"},"name":"config-deployment","namespace":"knative-serving","ownerReferences":[{"apiVersion":"operator.knative.dev/v1beta1","blockOwnerDeletion":true,"controller":true,"kind":"KnativeServing","name":"knative-serving","uid":"8994c6ac-bdb5-476e-a791-cc493d0481e0"}]}}
    manifestival: new
  creationTimestamp: "2024-06-05T11:36:05Z"
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/name: knative-serving
    app.kubernetes.io/version: 1.10.2
  name: config-deployment
  namespace: knative-serving
  ownerReferences:
  - apiVersion: operator.knative.dev/v1beta1
    blockOwnerDeletion: true
    controller: true
    kind: KnativeServing
    name: knative-serving
    uid: 8994c6ac-bdb5-476e-a791-cc493d0481e0
  resourceVersion: "17546"
  uid: 05551649-ea37-4961-b776-ed49069a7f1e

I was not able to reproduce this issue in airgapped today.
I am seeing this error when trying to apply the knative service:
Error from server (InternalError): error when creating "ksvc.yaml": Internal error occurred: failed calling webhook "webhook.serving.knative.dev": failed to call webhook: Post "https://webhook.knative-serving.svc:443/?timeout=10s": dial tcp <IP_ADDRESS>:443: connect: connection refused

I looked into it and filed #185 , after setting the images specified in #185 I no longer see the error above so I can now start playing with editing the configmap and the Image resource

I modified the KnativeServing.yaml.j2 file locally by adding to the spec.config.deployment:
queue-sidecar-image: <IP_ADDRESS>:5000/knative-releases/knative.dev/serving/cmd/queue:dabaecec38860ca4c972e6821d5dc825549faf50c6feb8feb4c04802f2338b8a

to test out if this is what we need for the KnativeService workload. Now I see the queue-proxy image set correctly in the pod:

 KnativeService workload pod description
```
kubectl describe po -nadmin helloworld-00001-deployment-dbc8767d4-dx72q
Name:             helloworld-00001-deployment-dbc8767d4-dx72q
Namespace:        admin
Priority:         0
Service Account:  default
Node:             airgapped-microk8s/<IP_ADDRESS>
Start Time:       Thu, 06 Jun 2024 09:34:48 +0000
Labels:           app=helloworld-00001
                  pod-template-hash=dbc8767d4
                  security.istio.io/tlsMode=istio
                  service.istio.io/canonical-name=helloworld
                  service.istio.io/canonical-revision=helloworld-00001
                  serving.knative.dev/configuration=helloworld
                  serving.knative.dev/configurationGeneration=1
                  serving.knative.dev/configurationUID=c0074455-8e69-407b-a2a3-e8a485298fc4
                  serving.knative.dev/revision=helloworld-00001
                  serving.knative.dev/revisionUID=fdf829b1-6b34-48cc-acd2-24e5cb44cf28
                  serving.knative.dev/service=helloworld
                  serving.knative.dev/serviceUID=5efd018d-52d4-41e1-b145-6a8e91e781a7
Annotations:      cni.projectcalico.org/containerID: 8971dbb25490761f17413bcd41daa04bf05ea61e953e05c690f7d877da15f198
                  cni.projectcalico.org/podIP: <IP_ADDRESS>/32
                  cni.projectcalico.org/podIPs: <IP_ADDRESS>/32
                  kubectl.kubernetes.io/default-container: user-container
                  kubectl.kubernetes.io/default-logs-container: user-container
                  prometheus.io/path: /stats/prometheus
                  prometheus.io/port: 15020
                  prometheus.io/scrape: true
                  serving.knative.dev/creator: admin
                  sidecar.istio.io/status:
                    {"initContainers":["istio-init"],"containers":["istio-proxy"],"volumes":["workload-socket","credential-socket","workload-certs","istio-env...
Status:           Running
IP:               <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  ReplicaSet/helloworld-00001-deployment-dbc8767d4
Init Containers:
  istio-init:
    Container ID:  containerd://49418a7abdd082d4779564f257a7a19999b25fbb1fad4d42fd486a57599d7645
    Image:         <IP_ADDRESS>:5000/istio/proxyv2:1.17.3
    Image ID:      <IP_ADDRESS>:5000/istio/proxyv2@sha256:ea9373309e35569cf2a011e973aa1f49e0354fd2d730e8a0d5cc25964499a100
    Port:
    Host Port:
    Args:
      istio-iptables
      -p
      15001
      -z
      15006
      -u
      1337
      -m
      REDIRECT
      -i
      *
      -x
  -b
  *
  -d
  15090,15021,15020
  --log_output_level=default:info
State:          Terminated
  Reason:       Completed
  Exit Code:    0
  Started:      Thu, 06 Jun 2024 09:34:49 +0000
  Finished:     Thu, 06 Jun 2024 09:34:49 +0000
Ready:          True
Restart Count:  0
Limits:
  cpu:     2
  memory:  1Gi
Requests:
  cpu:        100m
  memory:     128Mi
Environment:  <none>
Mounts:
  /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-g264f (ro)

Containers:
user-container:
Container ID:  containerd://ef220fe7d9d7333064b9564e615ae40d87cda530f57da85b1ad464f24f644963
Image:         <IP_ADDRESS>:5000/python@sha256:df44c0c0761ddbd6388f4549cab42d24d64d257c2a960ad5b276bb7dab9639c7
Image ID:      <IP_ADDRESS>:5000/python@sha256:df44c0c0761ddbd6388f4549cab42d24d64d257c2a960ad5b276bb7dab9639c7
Port:          8080/TCP
Host Port:     0/TCP
Command:
sleep
3600
State:          Running
Started:      Thu, 06 Jun 2024 09:34:51 +0000
Ready:          True
Restart Count:  0
Environment:
TARGET:           World
PORT:             8080
K_REVISION:       helloworld-00001
K_CONFIGURATION:  helloworld
K_SERVICE:        helloworld
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-g264f (ro)
queue-proxy:
Container ID:   containerd://6fd63941bed441263c860ea2e3bf83ff52d1fef7ad107a1ab9f9af144bf9286e
Image:          <IP_ADDRESS>:5000/knative-releases/knative.dev/serving/cmd/queue:dabaecec38860ca4c972e6821d5dc825549faf50c6feb8feb4c04802f2338b8a
Image ID:       <IP_ADDRESS>:5000/knative-releases/knative.dev/serving/cmd/queue@sha256:20a2e88595a443f1fe9db8c41cc985e4139f7e587d9a48ad0f30519cacd831f5
Ports:          8022/TCP, 9090/TCP, 9091/TCP, 8012/TCP, 8112/TCP
Host Ports:     0/TCP, 0/TCP, 0/TCP, 0/TCP, 0/TCP
State:          Running
Started:      Thu, 06 Jun 2024 09:34:52 +0000
Ready:          False
Restart Count:  0
Requests:
cpu:      25m
Readiness:  http-get http://:15020/app-health/queue-proxy/readyz delay=0s timeout=1s period=10s #success=1 #failure=3
Environment:
SERVING_NAMESPACE:                        admin
SERVING_SERVICE:                          helloworld
SERVING_CONFIGURATION:                    helloworld
SERVING_REVISION:                         helloworld-00001
QUEUE_SERVING_PORT:                       8012
QUEUE_SERVING_TLS_PORT:                   8112
CONTAINER_CONCURRENCY:                    0
REVISION_TIMEOUT_SECONDS:                 300
REVISION_RESPONSE_START_TIMEOUT_SECONDS:  0
REVISION_IDLE_TIMEOUT_SECONDS:            0
SERVING_POD:                              helloworld-00001-deployment-dbc8767d4-dx72q (v1:metadata.name)
SERVING_POD_IP:                            (v1:status.podIP)
SERVING_LOGGING_CONFIG:
SERVING_LOGGING_LEVEL:
SERVING_REQUEST_LOG_TEMPLATE:             {"httpRequest": {"requestMethod": "{{.Request.Method}}", "requestUrl": "{{js .Request.RequestURI}}", "requestSize": "{{.Request.ContentLength}}", "status": {{.Response.Code}}, "responseSize": "{{.Response.Size}}", "userAgent": "{{js .Request.UserAgent}}", "remoteIp": "{{js .Request.RemoteAddr}}", "serverIp": "{{.Revision.PodIP}}", "referer": "{{js .Request.Referer}}", "latency": "{{.Response.Latency}}s", "protocol": "{{.Request.Proto}}"}, "traceId": "{{index .Request.Header "X-B3-Traceid"}}"}
SERVING_ENABLE_REQUEST_LOG:               false
SERVING_REQUEST_METRICS_BACKEND:          prometheus
TRACING_CONFIG_BACKEND:                   none
TRACING_CONFIG_ZIPKIN_ENDPOINT:
TRACING_CONFIG_DEBUG:                     false
TRACING_CONFIG_SAMPLE_RATE:               0.1
USER_PORT:                                8080
SYSTEM_NAMESPACE:                         knative-serving
METRICS_DOMAIN:                           knative.dev/internal/serving
SERVING_READINESS_PROBE:                  {"tcpSocket":{"port":8080,"host":"<IP_ADDRESS>"},"successThreshold":1}
ENABLE_PROFILING:                         false
SERVING_ENABLE_PROBE_REQUEST_LOG:         false
METRICS_COLLECTOR_ADDRESS:
HOST_IP:                                   (v1:status.hostIP)
ENABLE_HTTP2_AUTO_DETECTION:              false
ROOT_CA:
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-g264f (ro)
istio-proxy:
Container ID:  containerd://a88c348293484519e7ae0f76fd0552b1adcacb8eff86d0a8154d6a2075aeeaa0
Image:         <IP_ADDRESS>:5000/istio/proxyv2:1.17.3
Image ID:      <IP_ADDRESS>:5000/istio/proxyv2@sha256:ea9373309e35569cf2a011e973aa1f49e0354fd2d730e8a0d5cc25964499a100
Port:          15090/TCP
Host Port:     0/TCP
Args:
proxy
sidecar
--domain
$(POD_NAMESPACE).svc.cluster.local
--proxyLogLevel=warning
--proxyComponentLogLevel=misc:error
--log_output_level=default:info
--concurrency
2
State:          Running
Started:      Thu, 06 Jun 2024 09:34:52 +0000
Ready:          True
Restart Count:  0
Limits:
cpu:     2
memory:  1Gi
Requests:
cpu:      100m
memory:   128Mi
Readiness:  http-get http://:15021/healthz/ready delay=1s timeout=3s period=2s #success=1 #failure=30
Environment:
JWT_POLICY:                    third-party-jwt
PILOT_CERT_PROVIDER:           istiod
CA_ADDR:                       istiod.kubeflow.svc:15012
POD_NAME:                      helloworld-00001-deployment-dbc8767d4-dx72q (v1:metadata.name)
POD_NAMESPACE:                 admin (v1:metadata.namespace)
INSTANCE_IP:                    (v1:status.podIP)
SERVICE_ACCOUNT:                (v1:spec.serviceAccountName)
HOST_IP:                        (v1:status.hostIP)
PROXY_CONFIG:                  {"discoveryAddress":"istiod.kubeflow.svc:15012","tracing":{"zipkin":{"address":"zipkin.kubeflow:9411"}}}
  ISTIO_META_POD_PORTS:          [
                                     {"name":"user-port","containerPort":8080,"protocol":"TCP"}
                                     ,{"name":"http-queueadm","containerPort":8022,"protocol":"TCP"}
                                     ,{"name":"http-autometric","containerPort":9090,"protocol":"TCP"}
                                     ,{"name":"http-usermetric","containerPort":9091,"protocol":"TCP"}
                                     ,{"name":"queue-port","containerPort":8012,"protocol":"TCP"}
                                     ,{"name":"https-port","containerPort":8112,"protocol":"TCP"}
                                 ]
  ISTIO_META_APP_CONTAINERS:     user-container,queue-proxy
  ISTIO_META_CLUSTER_ID:         Kubernetes
  ISTIO_META_NODE_NAME:           (v1:spec.nodeName)
  ISTIO_META_INTERCEPTION_MODE:  REDIRECT
  ISTIO_META_WORKLOAD_NAME:      helloworld-00001-deployment
  ISTIO_META_OWNER:              kubernetes://apis/apps/v1/namespaces/admin/deployments/helloworld-00001-deployment
  ISTIO_META_MESH_ID:            cluster.local
  TRUST_DOMAIN:                  cluster.local
  ISTIO_KUBE_APP_PROBERS:        {"/app-health/queue-proxy/readyz":{"httpGet":{"path":"/","port":8012,"scheme":"HTTP","httpHeaders":[{"name":"K-Network-Probe","value":"queue"}]},"timeoutSeconds":1}}
Mounts:
  /etc/istio/pod from istio-podinfo (rw)
  /etc/istio/proxy from istio-envoy (rw)
  /var/lib/istio/data from istio-data (rw)
  /var/run/secrets/credential-uds from credential-socket (rw)
  /var/run/secrets/istio from istiod-ca-cert (rw)
  /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-g264f (ro)
  /var/run/secrets/tokens from istio-token (rw)
  /var/run/secrets/workload-spiffe-credentials from workload-certs (rw)
  /var/run/secrets/workload-spiffe-uds from workload-socket (rw)

Conditions:
Type              Status
Initialized       True
Ready             False
ContainersReady   False
PodScheduled      True
Volumes:
workload-socket:
Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
Medium:
SizeLimit:
credential-socket:
Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
Medium:
SizeLimit:
workload-certs:
Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
Medium:
SizeLimit:
istio-envoy:
Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
Medium:     Memory
SizeLimit:
istio-data:
Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
Medium:
SizeLimit:
istio-podinfo:
Type:  DownwardAPI (a volume populated by information about the pod)
Items:
metadata.labels -> labels
metadata.annotations -> annotations
istio-token:
Type:                    Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds:  43200
istiod-ca-cert:
Type:      ConfigMap (a volume populated by a ConfigMap)
Name:      istio-ca-root-cert
Optional:  false
kube-api-access-g264f:
Type:                    Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds:  3607
ConfigMapName:           kube-root-ca.crt
ConfigMapOptional:
DownwardAPI:             true
QoS Class:                   Burstable
Node-Selectors:
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type     Reason     Age                    From     Message

Warning  Unhealthy  2m10s (x3 over 2m30s)  kubelet  Readiness probe failed: HTTP probe failed with statuscode: 503
</details>
so this fixes the `ImagePullBackOff` error we were seeing earlier.

I also saw the `Image` resource being set correctly, so we don't need to patch it:

kubectl get Images -nknative-serving
NAME          IMAGE
queue-proxy   <IP_ADDRESS>:5000/knative-releases/knative.dev/serving/cmd/queue:dabaecec38860ca4c972e6821d5dc825549faf50c6feb8feb4c04802f2338b8a
I will be sending a PR to add the `queue-sidecar-image` to the `KnativeServing.yaml.j2` manifest template

After configuring the queue-sidecar-image correctly, the KnativeService is still not Ready as desired.
The workload pod is stuck with 2/3 Ready containers
The queue-proxy container is not Ready, but not due to ImagePullBackOff. In the pod description it says:
  Warning  Unhealthy  2m55s (x7 over 4m8s)  kubelet            Readiness probe failed: HTTP probe failed with statuscode: 500
  Warning  Unhealthy  2m54s (x5 over 4m9s)  kubelet            Readiness probe failed: Get "http://<IP_ADDRESS>:15020/app-health/queue-proxy/readyz": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

The logs of the queue-proxy container are:
kubectl logs -nadmin helloworld-00001-deployment-dbc8767d4-dx72q -c queue-proxy
{"severity":"INFO","timestamp":"2024-06-06T09:34:52.152001373Z","logger":"queueproxy","caller":"sharedmain/main.go:259","message":"Starting queue-proxy","commit":"500756c","knative.dev/key":"admin/helloworld-00001","knative.dev/pod":"helloworld-00001-deployment-dbc8767d4-dx72q"}
{"severity":"INFO","timestamp":"2024-06-06T09:34:52.152352674Z","logger":"queueproxy","caller":"sharedmain/main.go:265","message":"Starting http server metrics:9090","commit":"500756c","knative.dev/key":"admin/helloworld-00001","knative.dev/pod":"helloworld-00001-deployment-dbc8767d4-dx72q"}
{"severity":"INFO","timestamp":"2024-06-06T09:34:52.152348217Z","logger":"queueproxy","caller":"sharedmain/main.go:265","message":"Starting http server main:8012","commit":"500756c","knative.dev/key":"admin/helloworld-00001","knative.dev/pod":"helloworld-00001-deployment-dbc8767d4-dx72q"}
{"severity":"INFO","timestamp":"2024-06-06T09:34:52.15236817Z","logger":"queueproxy","caller":"sharedmain/main.go:265","message":"Starting http server admin:8022","commit":"500756c","knative.dev/key":"admin/helloworld-00001","knative.dev/pod":"helloworld-00001-deployment-dbc8767d4-dx72q"}
aggressive probe error (failed 202 times): dial tcp <IP_ADDRESS>:8080: connect: connection refused
timed out waiting for the condition
aggressive probe error (failed 202 times): dial tcp <IP_ADDRESS>:8080: connect: connection refused
timed out waiting for the condition
aggressive probe error (failed 202 times): dial tcp <IP_ADDRESS>:8080: connect: connection refused
timed out waiting for the condition
aggressive probe error (failed 202 times): dial tcp <IP_ADDRESS>:8080: connect: connection refused
timed out waiting for the condition
aggressive probe error (failed 202 times): dial tcp <IP_ADDRESS>:8080: connect: connection refused
timed out waiting for the condition

I'm not sure now why this is happening so I'm looking into it

PR is now open #186 to add the config for queue image

closed by #186 and port-forwarded to main in #189


Ability to obtain global versions defined in .rtx.toml / config.toml files?

Hey there, hope you're doing well. Thanks heaps for this wonderful tool!
I'm attempting to integrate rtx into the Ansible playbooks that setup my development workstation but encountered one little feature that seems to be missing.
Based on the output of rtx global show below, he preferred way to configure rtx is using rtx use and the global config.toml or local .rtx.toml files.

A future v2 release of rtx will default to using ~/.config/rtx/config.toml instead.

However, there doesn't seem to be an equivalent to the rtx global command which shows global versions defined in ~/.config/rtx/config.toml. Using rtx current or rtx ls may show local versions which have been set in parent directories via .rtx.toml, so that may be misleading.
This makes it more tricky to script rtx in tools like Ansible when we want to set the global versions for various tools. Parsing config.toml in such tools is more difficult than a simple command like rtx global and would require a TOML parser to be installed etc..
I wonder if there could be an rtx current -g/--global option and similarly rtx ls -g/--global which would only show versions defined in the global config.toml and .tool_versions global files?
Thanks heaps in advance
Fotis

Thank you so much @jdxcode. Would it be possible to also add this flag to the rtx current command too please?
Cheers
Fotis

that's a hidden command that only exists to retain asdf compatibility. I think the usage of ls and current overlap too much to have separate commands. You should be able to get the information you want with rtx ls --global | awk '{print $1 "\t" $2}'

that's a hidden command that only exists to retain asdf compatibility. I think the usage of ls and current overlap too much to have separate commands.
You should be able to get the information you want with rtx ls --global | awk '{print $1 "\t" $2}'

Sweet, makes sense. Thanks heaps 😄


3.0.0 alpha 2 preparation

Cherry-pick #149, #152, #153, #156

@ludovicsteinbach That was my thought. Cherry-picking dependency updates is a pain because the lock file always conflicts, but I thought that was outweighed by addressing a vulnerability


1948 leveldb update in master

fixes https://github.com/apache/camel-quarkus/issues/1948
[ ] An issue should be filed for the change unless this is a trivial change (fixing a typo or similar). One issue should ideally be fixed by not more than one commit and the other way round, each commit should fix just one issue, without pulling in other changes.
[ ] Each commit in the pull request should have a meaningful and properly spelled subject line and body. Copying the title of the associated issue is typically enough. Please include the issue number in the commit message prefixed by #.
[ ] The pull request description should explain what the pull request does, how, and why. If the info is available in the associated issue or some other external document, a link is enough.
[ ] Phrases like Fix # or Fixes # will auto-close the named issue upon merging the pull request. Using them is typically a good idea.
[ ] Please run mvn process-resources -Pformat (and amend the changes if necessary) before sending the pull request.
[ ] Contributor guide is your good friend: https://camel.apache.org/camel-quarkus/latest/contributor-guide.html

Thanks @JiriOndrusek.


Tabitha starting halfway through CSV instead of at the beginning

Using the attached CSV and iterating through it with Tabitha (version 0.2.0), it appears to be starting halfway through the document rather than at the beginning.  Here's my code:
try (InputStream delimFileStream = fileUrl.openStream();
     RowReader reader = RowReaderFactory.open(delimFileStream)
                                        .orElseThrow(() -> new OpeningReaderException(String.format(
                                            "Could not open reader for URL (%s), MIME type of %s.",
                                            url,
                                            fileMime))
                                        )
                                        .withInlineHeaders()) {

    Row firstRow = reader.read().orElse(null);
    firstRow.header().ifPresent(header -> log.info("Header: " + Arrays.toString(header.toArray())));

    reader.forEach(row -> {
        List<String> strs = new ArrayList<>();
        row.forEach(cell -> strs.add(cell.getString().orElse("empty")));
        log.info(strs.toString());
    });
}

This prints the following:
Header: [, CA, United States, 12/1/03 19:13, 2/5/09 22:11, 35.36583, -120.84889]
[1/4/09 16:59, Product1, 1200, Visa, Amy, Parramatta, New South Wales, Australia, 1/3/09 22:35, 2/5/09 22:44, -33.8166667, 151]
[1/30/09 11:56, Product1, 1200, Mastercard, Whitney, Dumbleton, England, United Kingdom, 7/31/08 13:46, 2/6/09 0:04, 52.0166667, -1.9666667]
[1/6/09 5:10, Product1, 1200, Visa, Astrid, Altlengbach, Lower Austria, Austria, 6/24/08 0:49, 2/6/09 0:37, 48.15, 15.9166667]
[1/14/09 3:39, Product1, 1200, Visa, jo, Ballincollig, Cork, Ireland, 12/10/08 7:41, 2/6/09 2:36, 51.8833333, -8.5833333]
.... roughly 500 more items...
[1/8/09 11:55, Product1, 1200, Diners, julie, Haverhill, England, United Kingdom, 11/29/06 13:31, 3/1/09 7:28, 52.0833333, 0.4333333]
[1/12/09 21:30, Product1, 1200, Visa, Julia , Madison                     , WI, United States, 11/17/08 22:24, 3/1/09 10:14, 43.07306, -89.40111]

What Tabitha is registering as the header (the first row it has found) is actually line 526 in the CSV.
Turning this CSV into an XLSX via Microsoft Excel and then using that as the input to the code above works correctly (ignore the "empty" strings - I realize that's my problem and not a Tabitha problem):
Header: [Transaction_date, Product, Price, Payment_Type, Name, City, State, Country, Account_Created, Last_Login, Latitude, Longitude]
[empty, Product1, empty, Visa, Betina, Parkville                   , MO, United States, empty, empty, empty, empty]
[empty, Product1, empty, Mastercard, Federica e Andrea, Astoria                     , OR, United States, empty, empty, empty, empty]
...all the rest of the items...

CSV is attached as a .txt, as Github does not allow CSVs to be added as attachments.
SalesJan2009.txt
salesjan2009xl.xlsx

I am able to reproduce this behavior. Oddly enough, using a File instead of an InputStream fixes the issue. This works:
import com.widen.tabitha.RowReaderFactory

RowReaderFactory.open(new File("SalesJan2009.csv")).get().withInlineHeaders().withCloseable { reader ->
    def header = false

    reader.forEach {
        if (!header) {
            header = true
            println("header: " + it.header().get())
        }
        println("row: " + it)
    }
}

This does not:
import com.widen.tabitha.RowReaderFactory

RowReaderFactory.open(new FileInputStream("SalesJan2009.csv")).get().withInlineHeaders().withCloseable { reader ->
    def header = false

    reader.forEach {
        if (!header) {
            header = true
            println("header: " + it.header().get())
        }
        println("row: " + it)
    }
}


Roll engine 5f5713e33971..2036530c4dd6 (2 commits)

git@github.com:flutter/engine.git/compare/5f5713e33971...2036530c4dd6
git log 5f5713e33971..2036530c4dd6 --no-merges --oneline
2019-11-08<EMAIL_ADDRESS>Revert "Always use IOSGLContextSwitch to access EAGLContexts to prevent plugins from polluting Flutter's EAGLContext (#13314)" (flutter/engine#13753)
2019-11-08<EMAIL_ADDRESS>Always use IOSGLContextSwitch to access EAGLContexts to prevent plugins from polluting Flutter's EAGLContext (flutter/engine#13314)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

Trybots failed. These were the failed builds: https://cirrus-ci.com/task/6290863960883200

Commit queue failed; closing this roll.


Fork Me banner invisibly blocks HTML output button on Form Builder

After creating the same form 4 times, I realized why the output button was redirecting me to the github page only sometimes :rage4:

Yeah, it doesn't seem to be a problem that that Internet has solved. The only thing I can think of is 3 images in a table!


angular form

how to include media-item-forms ?

@deebloo thanku
problem is solved

Closing as answered by @deebloo, thanks!


(BKR-1084) Add --debug-errors option to enter pry on a test failing

Adds a --debug-errors option. When used, beaker will drop the runner into a pry console if/when a test fails or errors.
This is intended for the beaker run subcommand.

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/4027/

@kevpl - after reviewing with @johnduarte , we thought that if we had a debugger option like this, then we would not need the previously PR'ed --skip-last-teardown option - you can use this option instead to keep running beaker until it fails, and then inspect the ruby code and the SUT state at the time of failure.
I think this also means we don't need the other PR to expand the debugging doc with byebug instructions; but we could still keep those doc changes as they should be useful general ruby debugging information

Tests appear to be failing because we don't yet have pry-byebug on rubygems.delivery.puppetlabs.net - I can fix that if the general approach to this PR gets a thumbs up

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/4073/

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/4075/

@puppetlabs-jenkins please re-test this

@puppetlabs-jenkins test this please

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/4076/

Latest test failure is due to vmpooler capacity.

@puppetlabs-jenkins retest this please

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/4089/


Performance issue in scenario_runner-0.9.10/models/research/seq_flow_lite/models/sgnn/sgnn.py

Hello! Our static bug checker has found a performance issue in scenario_runner-0.9.10/models/research/seq_flow_lite/models/sgnn/sgnn.py:  fused_project is repeatedly called in a for loop, but there is a tf.function decorated function func defined and called in  fused_project.
In that case, when fused_project is called in a loop, the function func will create a new graph every time, and that can trigger tf.function retracing warning.
Here is the tensorflow document to support it.
Briefly, for better efficiency, it's better to use:
@tf.function
def inner():
    pass

def outer():
    inner()

than:
def outer():
    @tf.function
    def inner():
        pass
    inner()

Looking forward to your reply.

But some variables are depending on the outer function. Code may be more complex if changes are made. Is it necessary to make the change or do you have any other ideas? @zaidtahirbutt


How to setting to show “px” but not “pt/px”

For example, I want to mark “79px”, but not "56.9pt / 79px".

@runhugo set 72 ppi for your document.


How to implement custom proxy manager for Bucket4j to integrate with homegrown cache?

As of today, bucket4j support provides integration with cache solutions like Hazelcast, Redis etc., we have a requirement where we wanted to use bucket4j with our homegrown cache solution. Are there any steps documented that helps us with implementing the custom integration?

Hello @deshpandeanoop
To build custom integration you need to answer to following question: does your solution support any variant of RPC when on JVM may call another JVM? It can be something like EntryProccessors from JCache, VoltDb's stored procedures, or serializable functions in Infinispan. If your solution supports RPC, just extend AbstractProxyManager and implement abstract methods, use IgniteProxyManager or InfinispanProxyManager for reference. Do not forget to think about transaction isolation, you need to clearly understand how to protect data from concurrent modifications.
If RPC is not supported then you need to choose one of basic class for extending:

SelectForUpdateBasedProxyManager if your solution supports the selecting and locking the data via one remote call.
AbstractLockBasedProxyManager if your soulution supports the locks on the data.
AbstractCompareAndSwapBasedProxyManager if your solution supports CAS.
If nothing from above is supported then anyway you can use AbstractLockBasedProxyManager by delegating the locking acquiring to another solutions like Redis or something similar.
If your sulution supports the both CAS and locking, then choose apropriate way based on proposed contention on the buckets - usually locking win when contention is high and vise versa.

Then you need to test resulting code via via extending this test-base. TCK is available in maven central with special type test-jar
        <dependency>
            <groupId>com.bucket4j</groupId>
            <artifactId>bucket4j-core</artifactId>
            <version>${bucket4j.version}</version>
            <type>test-jar</type>
            <scope>test</scope>
        </dependency>

AbstractDistributedBucketTest contains multiple checks for many aspects of distributed bucket implementation. Do not skip this step, it is ultimately major, see thos thread https://github.com/bucket4j/bucket4j/discussions/349#discussioncomment-4912745


Slides lose content on full screen

When on full screen, some lines of slides are lost.

The slides often used in half screen mode so that live coding can occur on the other half - resizing is important but must be careful about affecting this view.


TypeError: n.parentNode is null

This error will be thrown when using button.js:

Can't replicate it. However, you should check n.parentNode before using it.


KeyError : search-results

Hello!
I am sorry but i have this error and i don't know if it is due to the API key or something else...
Unfortunately i cannot connect to my institution because i am off the country.
I dont know if this plays an important role..
Any help much appreciated!

are you using a legitimate api key?
you might be able to use search api without subscription. try reading https://dev.elsevier.com/api_key_settings.html and also the FAQs.

Well i think yes.. i just created the API key from the page you mentioned by signing up..

same here.
i am using api and it's not working

Please try using your affiliation (e.g., university) VPN if you're using your work internet. I test PyScopus without any problem.


(!) Memory Leak in website demo page

I am experiencing a critical memory leak issue when trying to access https://apexcharts.com/javascript-chart-demos/
I'm using Firefox Developer Edition 62.0b15 (64-bit), on Debian 9.5 "Stretch".
Here is a video proof (youtube link). You can clearly see the CPU going crazy at around 15 to 20 seconds in the video, only a few moments after loading the page. Then, the memory starts filling up rapidly, eventually eating through swap space, at that point i have no choice but to kill Firefox to keep my system stable.
I do have a few addons installed on the browser, but i do not believe that they have any impact on the issue.
Is anyone able to reproduce this behavior?

Yup, tried on two computer, RAM usage gone wild, had to restart my PC. Tried on Firefox Linux and Chrome Windows.

Is anyone able to reproduce this behavior?

Yes, same issue here. Firefox 62.0b15 (64-bit) (non-developer) on Ubuntu 16.04.5 64bit

@GitSquared Confirmed the bug.
The memory leak is due to the mixed chart. I disabled each chart one by one and disabling mixed charts made the page responsive. Otherwise, my firefox was also crashing every time I loaded the demo page.
I will investigate the mixed chart rendering, thanks for reporting

@junedchhipa It's working for me now. Thanks for the quick response. Closing.

@junedchhipa Dashboard demo has the same problem

@arkhenstone I will check the Dashboard too. Combo chart (line/area/column) seems the main culprit. I will try to fix it quickly so I don't have to go to each and every place to disable Mixed Charts ;)

I believe @arkhenstone reported this issue to also happen in Chrome, nah?

Tried on Firefox Linux and Chrome Windows.

Is this still true or is this issue really Firefox-specific?

Ah! right. If the same problem persists in Chrome as well, then this is not browser specific. Reverting title change

I have fixed the issues which were crashing Firefox when viewing demo pages.
@arkhenstone can you please test the demo page as well as the dashboards?
@GitSquared can't reproduce the "heatmap" issue in firefox/chrome. Can you please test again and if error persists, give more info?
Thanks


fix: missing input for workflow

This needed now and was missing

Weird, didn't i fix that already with?
https://github.com/get10101/10101/pull/2475


Do not list concealed pages

Page method with_concealed_if(bool) to list concealed pages
Move Page.search to dataset extension
Show a lock for concealed pages in lists

Added some tests as well, merging now.


Pug now has to be installed globally

When trying to use pug templates (<template lang="pug">), before upgrading vbuild (from 4.x.x I think) I could install pug in the project's package.json and it would pick it up and use that version. Now I need to yarn global add pug to get my project to compile. Is there any reason for this change?
$ vbuild --version
6.24.7
$ node --version
v6.1.0

you're probably using a global installed vbuild, this way vue-loader isn't installed in current working directory while your pug dependency is, the solution is to install vbuild locally yarn add vbuild --dev


Wiremock Doesn't Mock the Webclient Request

I am using spring boot 2.5.7, java 8 and junit 5.(I also used wiremock-jre but issue is same)
<parent>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-parent</artifactId>
	<version>2.5.7</version>
	<relativePath />
</parent>

	<dependency>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-test</artifactId>
		<scope>test</scope>
	</dependency>

	<dependency>
		<groupId>org.springframework.cloud</groupId>
		<artifactId>spring-cloud-contract-wiremock</artifactId>
		<version>3.0.4</version>
		<scope>test</scope>
	</dependency>

My integration test class:
@SpringBootTest(classes = MyTestApplication.class, webEnvironment = WebEnvironment.RANDOM_PORT)
@AutoConfigureWireMock(port = 0)
@DirtiesContext
public class MyTestControllerTest {

  @LocalServerPort
  private int port;

  @Autowired
  private TestRestTemplate restTemplate;

  @BeforeEach
  void init() {
    stubFor(post(urlPathEqualTo("http://localhost:8443/my-third-party-endpoint"))
        .willReturn(aResponse()
            .withStatus(200)
            .withHeader("Content-Type", MediaType.APPLICATION_JSON.toString())
            .withHeader("Accept", MediaType.APPLICATION_JSON.toString())
            .withBody("{}")));
  }

  @Test
  public void testAddEmployee() {
    PartInspectionImageModel partInspectionImageModel = new PartInspectionImageModelProvider().createPartInspectionImageModel();

    ResponseEntity<PartInspectionImageModel> responseEntity = this.restTemplate
        .postForEntity("http://localhost:" + port + "/rest/my-test-endpoint", partInspectionImageModel, PartInspectionImageModel.class);

    assertEquals(200, responseEntity.getStatusCodeValue());
  }
}

Code piece to be mocked by wiremock inside my implementation class:
 WebClient webClient = WebClient.create("http://localhost:8443");

  Mono<String> postPartInspectionImageModelToML = webClient.post()
      .uri("/my-third-party-endpoint")
      .contentType(MediaType.APPLICATION_JSON)
      .accept(MediaType.APPLICATION_JSON)
      .body(Mono.just(completeMlProcessingModel), CompleteMlProcessingModel.class)
      .retrieve()
      .bodyToMono(String.class);

  String response = postPartInspectionImageModelToML.block();

Due to it can't be mocked, test failing at postPartInspectionImageModelToML.block() phase.
Error is only:

Caused by: java.net.ConnectException: Connection refused: no further
information

Hey @mgnfcnt where3 did you specify the port for Wiremock to start on 8443? By default it's on 8080, so it's worth amending your code to:
- WebClient webClient = WebClient.create("http://localhost:8443");
+ WebClient webClient = WebClient.create("http://localhost:8080");

Additionally, this doesn't look quite right to me - I think you can do it as just:
-    stubFor(post(urlPathEqualTo("http://localhost:8443/my-third-party-endpoint"))
+   stubFor(post(urlPathEqualTo("/my-third-party-endpoint"))

@jamietanna "http://localhost:8443" this is another service i need to call that is why i am creating webclient with this base-url. I cant change it to 8080 because that service running on 8443 port

For this example though, we're trying to test through Wiremock though, right?

I am trying to create integration test for specific endpoint. In my implementation class i have webclient call. I am trying to mock this request with wiremock. thats all

So the first thing we need to do is to inject in "http://localhost:8443" (via the constructor or @Value for a field) so we can stub it out for the purpose of this test, because:

it's a better practice so you can change it more easily in the future
it allows us to have one value for the tests, and one for Production code

I suggest taking this to the mailing list or Stackoverflow, since it's a Spring integration question rather than bug or enhancement request.


KAFKA-4604: Fix gradle build to avoid generating unnecessary projects

Fix gradle build to avoid generating unnecessary projects for non project sub folders. The unnecessary projects cause unwanted file deletes in git when these projects are cleaned in eclipse.

retest this please

I ran the following two commands with JDK 1.8 setup and the tests ran successfully.
./gradlew -PscalaVersion=2.11 test
./gradlew -PscalaVersion=2.12 test

Hi @ijuma @guozhangwang
I am new to the codebase and process, so please guide me if I am going wrong somewhere.
I have done a merge from trunk HEAD and tried the following tests on my local setup.
./gradlew -PscalaVersion=2.10 test (with JDK1.7)
./gradlew -PscalaVersion=2.11 test (with JDK1.8)
./gradlew -PscalaVersion=2.12 test (with JDK1.8)

The tests fail sometimes when run all together but the failing ones pass when run selectively afterwards. May be the tests are non deterministic, or am I missing something?
I will push the trunk HEAD merge to trigger another Jenkins test.

I tested the branch and can confirm that there is no Eclipse files generated at root fold and sub-connect folder. @ijuma do you want to double check?

@guozhangwang @ijuma - Closing this PR since it is obsoleted by https://github.com/apache/kafka/pull/2382


excluding variables from symbols for workbench.action.gotoSymbol

I'm using Go To Symbol in Editor... to navigate functions/methods and I don't really care about variables. I know to add : after @ would make it show classes only, but no way to get rid of variables and keep methods and classes.
Need a setting similar to Outline: Show Variables  to ignore variables

yes it's duplicated


Tests: adopt AbsolutePath APIs for path construction

Update the test expectations to use AbsolutePath for the construction
of the path literals in order to support non-/ path separator
characters.  This allows these test expectations to match on Windows.

@swift-ci please smoke test

@tomerd ooh, I do like that clean up idea; and I agree that it is better suited as a follow up change

@swift-ci please smoke test

@swift-ci please smoke test


Connection issue Ledger Nano X

Issue description
When trying to connect the Ledger Nano X with Firefly the connection is rarely possible. When the ledger finally connects, the button for generating an address doesn't work. This was on my PC with Windows 10.
I have tried to

reinstall Firefly with deleting the appdata folder,
reinstall the iota app on the ledger,
disable windows defender.

Also, every other ledger-related app can instantly connect to my ledger. Only firefly fails to do this. I have tried to restart the PC several times and only opening the firefly app.
I have also tried to connect the Ledger Nano X on my old PC with Windows 7. And there it is no problem. Firefly connects without problems.
Wallet version
Firefly v1.2
IOTA App v0.7.3
Ledger Nano X firmware v1.3.0
System specification
What is your operating system?
Windows 10
Is it a repeatable issue?
Y
Steps To reproduce the issue
Explain how the maintainer can reproduce the issue.

Open Firefly
Login Profile
Connect Ledger Nano X
Open IOTA app on ledger

Hey @MiKeF05, some other Windows users have also been experiencing bugginess, mainly in the communication with the Ledger device and Firefly. We suspect that it might have something to do with the wallet.rs library, but are still investigating - thank you for your understanding and patience.


Get Link appears to be broken due to a lack of permission

Search before asking

[X] I had searched in the issues and found no similar issues.

Operating System

[ ] macOS
[ ] Windows
[X] Linux

Operating System Version
Fedora 38
It happens on the web browser too?
No, it just happens on the Desktop app
Rocket.Chat Desktop App Version
3.9.9
Rocket.Chat Server Version
5.4.8
Describe the bug
Get Link appears to be broken due to a lack of permission on chromium and desktop app.
You will not be able to get a Link to a message using the 3 dots menu on a message -> more -> Get Link
How to Reproduce

Go to any message
Click on '....'
GetLink

Describe your Expected behavior
Link is copied to the clipboard
Anything else
it worked in 3.9.3, now with 3.9.9 it doesn't
Are you willing to submit a code contribution?

[ ] Yes, I am willing to submit a Pull Request!

Hi, we have the same problem with the Windows app (v 3.9.9) and server 6.4.4.

Same issue here on the Mac app 3.9.9 and server 6.4.5.  Works fine in browsers or mobile client.
Someone opened a ticket on the server as well, though it seems more likely to be a client issue since it only affects the desktop apps.  https://github.com/RocketChat/Rocket.Chat/issues/30724

@jeanfbrito - can you take a look at this issue and provide your assessment?

@Loki-Afro please test the version 3.9.10 of Desktop client.
@ebyrne242 Yes, this can be a cache issue on the update to 6.4.5.
I just checked and no issues happened on 3.9.9 and 6.4.5 for me, but if the issue continues, please remove the server and add again, this must fix it.
If not yet, please mention me.

@jeanfbrito working here on 3.9.10 right now, thank you!
what was the issue?

I really think that it was the cache issue that happened on server update. But if it happens again please reach me, I will be closing the issue then.


Add a failing test case for & within a nested function in a declaration value

Related to https://github.com/emotion-js/emotion/issues/2943

@Andarist didn't notice this when you opened it, (only the friendly ping): fixed in the head commit, you can merge/release this one.

Pull Request Test Coverage Report for Build 673315f00359b3ae65949786d475d88332f8149d-PR-307
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.006%) to 98.849%

Totals

Change from base Build bc0b1b03f5562eb8b38601e4e05461631a91c400:
0.006%

Covered Lines:
271

Relevant Lines:
273

💛  - Coveralls


RMET-3379 OSBarcodeLib - Fix UI bug when layout is portrait

Description

Fixes a UI bug where the darker background was incorrectly drawn, when the layout was portrait.

If layout is portrait, then we draw the Text composable even if no scanInstructions are provided, which fixes the background.

Context

References: https://outsystemsrd.atlassian.net/browse/RMET-3379
Type of changes

[x] Fix (non-breaking change which fixes an issue)
[ ] Feature (non-breaking change which adds functionality)
[ ] Refactor (cosmetic changes)
[ ] Breaking change (change that would cause existing functionality to not work as expected)

Platforms affected

[x] Android
[ ] iOS
[ ] JavaScript

Tests

Tested on Android 15 (Pixel 7), Android 13 (Samsung A51), Android 12 (Pixel 3XL), and on a Pixel C Tablet (Android 14) emulator.
MABS 10 build: https://intranet.outsystems.net/MABS/BuildDetail.aspx?BuildId=4b1ae98968e0acdc48d2060ec50187696ecf0071
Screenshots (if appropriate)

Checklist

[x] Pull request title follows the format RNMT-XXXX <title>
[x] Code follows code style of this project
[x] CHANGELOG.md file is correctly updated
[ ] Changes require an update to the documentation

[ ] Documentation has been updated accordingly

couldn't the same result be achieved by not adding ScanInstructions to the @Composable function?
it just seems weird that we need to have an empty Text to have a background

couldn't the same result be achieved by not adding ScanInstructions to the @Composable function? it just seems weird that we need to have an empty Text to have a background

@OS-martacarlos That's essentially how it was before, where we only checked if the parameters.scanInstructions text was empty, and if it was, we didn't even do anything in the ScanInstructions composable. But that way we have the UI bug that can be seen in the task related to this PR.
So we're not setting an empty Text to have a background, the background is there anyways, but a little part of it is missing (as can be seen in the image showing the bug).
So far, drawing the Text composable anyways when the layout is portrait was the only way I could fix the bug. This probably needs to be revisited in a tech debt task though.


0.0.14

lgtm. side question - where can we find list of current moderator addresses?

{
  moderators {
    id
  }
}

https://api.goldsky.com/api/public/project_cl6mb8i9h0003e201j6li0diw/subgraphs/resolutions-subgraph/0.0.13/gn


Netskope: Update Python dependencies

Changes:

Move to latest version of netskopesdk PIP package (0.0.30).
Update requests (fix GHSA-j8r2-6x86-q33q)
Thanks to netskopesdk update, fix GHSA-8gq9-2x98-w8hf

This might require some manual testing to ensure that the update didn’t break anything.


README typo(s).

At https://github.com/cliffordwolf/picorv32 (in README.md) I see:

A PCPI core that implements the `MUL[H[SU

I expected:

A PCPI core that implements the `MUL[H[SU |U]] `

(the fragment |U]] is missing).

Oh, it was there. The github markdown implementation just thought the | terminated the table cell. :) Fixed in d124abbacd655e449becb9a05cb70ff45c50fa9b.


nop numbered list in doc to use manual numbering

@lavalamp

@krousey for fast merge if @lavalamp OKs

@k8s-bot test this

I really don't like this. I guess I'll hold my nose and LGTM because we can search & replace later.

@lavalamp - replace with what?
On Jul 20, 2015 12:25 PM, "krousey"<EMAIL_ADDRESS>wrote:

Merged #11590
https://github.com/GoogleCloudPlatform/kubernetes/pull/11590.
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/pull/11590#event-360370178
.

I mean, when we fix our html generator to do the lists correctly, we can remove all the <nop>s in one go.


Fix import-workout-link parsing

Currently it only redirects to the workout editor, since it ignores the UUID-path param.
This has probably been broken since : https://github.com/sivertschou/dundring/commit/8b2af524e35c80af2a822a42eb58e79b80fc8fed
Since the routing stuff is restructered, this is the easiest way I could think of to fix it.
Test-link: https://preview-382.dundring.com/workout/7baa6a1c-63cc-43ff-a15e-369924d1b0b9
This pr:

Closed by #385


MockWebServer issues with github CI

Related to https://github.com/square/okhttp/pull/6811
Issue surfaces like miningmadness.com vs MiningMadness.com for <IP_ADDRESS>.  Imagine the host file has a bunch of blockholed hosts similar to https://gist.github.com/Jolg42/100b52fd6d88ac81740f2cb5086c9b55
Probably also causes delays.  But what should the behaviour be for MockWebServer.getHostName() and RecordedRequest.requestUrl which contains a hostname involving a reverse dns lookup.

This is currently failing the Windows CI jobs, hence the urgency.

I believe this is fixed here:
https://github.com/square/okhttp/pull/6919


Get branch action refactor

Description
This PR introduces new action get-ref-properties that expands the current get-branch functionality on retrieving the git tag name. That action is used in all workflows except feature envs, as those will be reworked in different PR.
Testing
Tests have been made on my fork. . Since binary build and cliain is tested in this PR, the only not tested directly was push to foundation repo workflow, yet this is indirectly tested by action itself.
Type of change
Please delete options that are not relevant.

New feature (non-breaking change which adds functionality)

Checklist:

I have created new documentation

I have added a simple bash based test to your branch.  It's something I mentioned few days, so nothing exciting.  In the end, I'm not sure if we actually need it.  Feel free to tweak or remove it entirely.  I'll leave it up to you.
Apart from that, I'll approve the code.  It seems to work just fine.


[MAT-10746] handle minus number case

MAT-10746

I'm not done reviewing yet, but you will also have to increment the version in setup.py so you can create a tag, and use that tag to set the version of this library in our codebase. Let me know if you want to go over how to do that live.

Awesome thanks!


update: the official apple  java6

correct java6 download url for matching its sha256
After making all changes to the cask:

[ ] brew cask audit --download {{cask_file}} is error-free.
[ ] brew cask style --fix {{cask_file}} left no offenses.
[ ] The commit message includes the cask’s name and version.

Please complete the steps in the PR template next time. Thanks for the PR!


Operator throws error that it cannot find StatefulSet

I get the following error message since version 2.13.0 of the operator:
kopf.objects         [ERROR   ] Timer 'ping_cratedb' failed with an exception. Will retry.
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/kopf/_core/actions/execution.py", line 283, in execute_handler_once
    result = await invoke_handler(
  File "/usr/local/lib/python3.8/site-packages/kopf/_core/actions/execution.py", line 378, in invoke_handler
    result = await invocation.invoke(
  File "/usr/local/lib/python3.8/site-packages/kopf/_core/actions/invocation.py", line 117, in invoke
    result = await fn(**kwargs)  # type: ignore
  File "main.py", line 188, in ping_cratedb
    await ping_cratedb_status(namespace, name, logger)
  File "/usr/local/lib/python3.8/site-packages/crate/operator/handlers/handle_ping_cratedb_status.py", line 45, in ping_cratedb_status
    desired_instances = await get_desired_nodes_count(namespace, name)
  File "/usr/local/lib/python3.8/site-packages/crate/operator/operations.py", line 76, in get_desired_nodes_count
    statefulset = await apps.read_namespaced_stateful_set(
  File "/usr/local/lib/python3.8/site-packages/kubernetes_asyncio/client/api_client.py", line 189, in __call_api
    raise e
  File "/usr/local/lib/python3.8/site-packages/kubernetes_asyncio/client/api_client.py", line 182, in __call_api
    response_data = await self.request(
  File "/usr/local/lib/python3.8/site-packages/kubernetes_asyncio/client/rest.py", line 193, in GET
    return (await self.request("GET", url,
  File "/usr/local/lib/python3.8/site-packages/kubernetes_asyncio/client/rest.py", line 187, in request
    raise ApiException(http_resp=r)
kubernetes_asyncio.client.exceptions.ApiException: (404)
Reason: Not Found
HTTP response headers: <CIMultiDictProxy('Audit-Id': 'd3d05d53-6632-4a88-b1c6-608ccee8275d', 'Cache-Control': 'no-cache, private', 'Content-Type': 'application/json', 'X-Kubernetes-Pf-Flowschema-Uid': '1a3ff758-6cfc-4d4d-94e5-00a5c2db0c49', 'X-Kubernetes-Pf-Prioritylevel-Uid': '37b126f9-ff88-4ed8-8297-6ddbfc19e47c', 'Date': 'Wed, 22 Jun 2022 12:36:27 GMT', 'Content-Length': '264')>
HTTP response body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"statefulsets.apps \"crate-data-hot-cratedb-cluster\" not found","reason":"NotFound","details":{"name":"crate-data-hot-cratedb-cluster","group":"apps","kind":"statefulsets"},"code":404}

As far as I have understood, the StatefulSet name to check was incorrectly hard-coded to "crate-data-hot-{name}" in change_compute.py
Operator Version: 2.13.0
CrateDB Version: 4.8.1
Kubernetes Version: 1.21.0

I've encountered this, and also a failure in the cluster creation method, when using a minikube cluster with version 1.25+. I don't see those errors on, say, a minikube cluster running Kubernetes v1.23.2. After some deeper diving, I noticed that some resources like the PodDisruptionBudget were not being created. The Kubernetes API has introduced deprecations and removals for several beta APIs. After updating the crate operator locally to use non-beta APIs, these errors went away for me. I'm currently blocked on validating further due to https://github.com/crate/crate-operator/issues/460.

If this appears again on recent versions, please reopen.


India News API

Can I know which API did you use to extract India specific news

Hey @VishalPallagani,
I'm using News API.


Argo Application Support in Weave GitOps

As a user, I want to:

Click on an Argo Application to view its details, so I can understand the current status and configuration of the application.
Acceptance Criteria:

Display Argo Application's name, namespace, source repository, path, and target cluster
Display the Argo Application's sync status, health status, and latest revision information
Show the time since the last sync and the last successful sync

Resume or suspend an Argo Application, so I can control the synchronization process of my applications.
Acceptance Criteria:

Display buttons to resume or suspend the Argo Application
Update the application's status accordingly after resuming or suspending

Force a synchronization of an Argo Application, so I can ensure my application is up-to-date with its desired state.
Acceptance Criteria:

Display a "Force Sync" button on the Argo Application details page
Trigger a synchronization when the button is clicked

View recent events related to an Argo Application, so I can quickly identify issues or changes made to the application.
Acceptance Criteria:

Display an "Events" tab on the Argo Application details page
Show a list of recent events with timestamps, types, reasons, and messages

View the YAML definition of an Argo Application, so I can see the full details and configuration of the application.
Acceptance Criteria:

Display a "YAML" tab on the Argo Application details page
Show the YAML content of the Argo Application in a read-only format

Visualize the workloads deployed by an Argo Application, so I can understand the relationship between the application and its deployed resources.
Acceptance Criteria:

Display a "Graph" tab on the Argo Application details page
Show a visual representation of the workloads and their relationships within the application

Maintain a consistent user experience across Kustomizations, Helm Releases, and Argo Applications, so I can easily navigate and use the Weave GitOps platform.
Acceptance Criteria:

Ensure the same look and feel for Argo Application details pages as Kustomizations and Helm Releases
Use the same patterns for actions, tabs, and information display

Having trouble getting the argo app through our backend - I have it showing in the argo UI though which is a good start.
Two questions about what might be going on:

Argo getting started guide has me switching kubectl contexts - would that mess with what our backend is looking at in any way?
The backend will crash if you ask for anything outside of scheme.AllKnownTypes - link
There's an Add function that I can use to slot argo stuff into our default kinds, but I'm REALLY struggling to find what the GroupVersionKind would be for these resources.

The backend will crash if you ask for anything outside of scheme.AllKnownTypes - link

This is very good point as we would also fix this scheme.AllKnownTypes things too so that WG OSS would be able support any kind of CRD without importing its dependency into the binary.

Closing in light of other priorities.


cc-proxy: Follow the latest API change

Hopefully the first and only client API change before we tag 2.1.
References: https://github.com/01org/cc-oci-runtime/pull/595
Signed-off-by: Damien Lespiau<EMAIL_ADDRESS>--
Of course, this PR is going to fail and the related PR in the runtime isn't merged yet.

01org/cc-oci-runtime#595 has been merged, so someone should probably re-trigger the travis checks on this PR (I don't seem to be able to do that).


Test command doesn't seem to work on win64

[X] I read the conda-forge documentation and could not find the solution for my problem there.

Issue:
Hi,
After installing parallel, my first try was to call it directly by its name but the command was not found. AfterI verifiying that .\env\Library\bin\parallel existed, I came here and found out in meta.yaml that it needs to be called with bash.
I have tried the command listed in your test but without sucess :

bash -c 'export SHELL=cygpath -u "$BASH"; parallel --plain --version || true'

What it is the correct way to call this command ?
Regards,
JR

Environment (conda list):

$ conda list
# packages in environment at D:\conda_env\json_env:
#
# Name                    Version                   Build  Channel
ca-certificates           2020.12.5            h5b45459_0    conda-forge
certifi                   2020.12.5        py39hcbf5309_0    conda-forge
m2-base                   1.0.0                         3    msys2
m2-bash                   4.3.042                       5    msys2
m2-bash-completion        2.3                           2    msys2
m2-catgets                1.1                           3    msys2
m2-coreutils              8.25                        102    msys2
m2-dash                   0.5.8                         2    msys2
m2-file                   5.25                          2    msys2
m2-filesystem             2016.04                       4    msys2
m2-findutils              4.6.0                         2    msys2
m2-gawk                   4.1.3                         2    msys2
m2-gcc-libs               5.3.0                         4    msys2
m2-gettext                0.19.7                        4    msys2
m2-gmp                    6.1.0                         3    msys2
m2-grep                   2.22                          4    msys2
m2-gzip                   1.7                           2    msys2
m2-inetutils              1.9.2                         2    msys2
m2-info                   6.0                           2    msys2
m2-less                   481                           2    msys2
m2-libasprintf            0.19.7                        4    msys2
m2-libcatgets             1.1                           3    msys2
m2-libcrypt               1.3                           2    msys2
m2-libgettextpo           0.19.7                        4    msys2
m2-libiconv               1.14                          3    msys2
m2-libintl                0.19.7                        4    msys2
m2-liblzma                5.2.2                         2    msys2
m2-libpcre                8.38                          2    msys2
m2-libreadline            6.3.008                       8    msys2
m2-libutil-linux          2.26.2                        2    msys2
m2-libxml2                2.9.2                         3    msys2
m2-mintty                 1!2.2.3                       2    msys2
m2-mpfr                   3.1.4                         2    msys2
m2-msys2-launcher-git     <IP_ADDRESS>0c495                2    msys2
m2-msys2-runtime          <IP_ADDRESS>80.65c939c               3    msys2
m2-ncurses                6.0.20160220                  2    msys2
m2-sed                    4.2.2                         3    msys2
m2-tftp-hpa               5.2                           2    msys2
m2-time                   1.7                           2    msys2
m2-ttyrec                 1.0.8                         2    msys2
m2-tzcode                 2015.e                        2    msys2
m2-util-linux             2.26.2                        2    msys2
m2-which                  2.21                          3    msys2
m2-zlib                   1.2.8                         4    msys2
massedit                  0.69.1                   pypi_0    pypi
msys2-conda-epoch         20160418                      1    msys2
nodejs                    15.3.0               h57928b3_0    conda-forge
openssl                   1.1.1i               h8ffe710_0    conda-forge
parallel                  20200322                      0    conda-forge
perl                      <IP_ADDRESS>             h57928b3_0    conda-forge
pip                       20.3.3           py39haa95532_0
python                    3.9.1                h6244533_2
python_abi                3.9                      1_cp39    conda-forge
setuptools                51.0.0           py39haa95532_2
sqlite                    3.33.0               h2a8f88b_0
tzdata                    2020d                h14c3975_0
vc                        14.2                 h21ff451_1
vs2015_runtime            14.28.29325          h5e1d092_0    conda-forge
wheel                     0.36.2             pyhd3eb1b0_0
wincertstore              0.2              py39h2bbff1b_0
zlib                      1.2.11               h62dcd97_4

Details about  conda and system ( conda info ):

$ conda info

    active environment : json_env
    active env location : D:\conda_env\json_env
            shell level : 2
       user config file : C:\Users\admjrmorreale\.condarc
 populated config files : C:\Users\admjrmorreale\.condarc
          conda version : 4.9.2
    conda-build version : not installed
         python version : 3.8.5.final.0
       virtual packages : __cuda=11.0=0
                          __win=0=0
                          __archspec=1=x86_64
       base environment : C:\ProgramData\Miniconda3  (writable)
           channel URLs : https://repo.anaconda.com/pkgs/main/win-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/win-64
                          https://repo.anaconda.com/pkgs/r/noarch
                          https://repo.anaconda.com/pkgs/msys2/win-64
                          https://repo.anaconda.com/pkgs/msys2/noarch
          package cache : C:\ProgramData\Miniconda3\pkgs
                          C:\Users\admjrmorreale\.conda\pkgs
                          C:\Users\admjrmorreale\AppData\Local\conda\conda\pkgs
       envs directories : D:\conda_env
                          C:\ProgramData\Miniconda3\envs
                          C:\Users\admjrmorreale\.conda\envs
                          C:\Users\admjrmorreale\AppData\Local\conda\conda\envs
               platform : win-64
             user-agent : conda/4.9.2 requests/2.25.1 CPython/3.8.5 Windows/10 Windows/10.0.17763
          administrator : True
             netrc file : None
           offline mode : False

Hello, I'm not sure either to be honest, the builds have been failing on windows for the past months, I tried many different things to fix on this PR: https://github.com/conda-forge/parallel-feedstock/pull/20, and made some progress but the test command still fails.
parallel needs the $SHELL variable to point to bash so it can use it but it seems like the path is in the windows format, I tried cygpath -u to convert the path but doesn't look like it worked.

Hello, I'm not sure either to be honest, the builds have been failing on windows for the past months, I tried many different things to fix on this PR: https://github.com/conda-forge/parallel-feedstock/pull/20, and made some progress but the test command still fails.
parallel needs the $SHELL variable to point to bash so it can use it but it seems like the path is in the windows format, I tried cygpath -u to convert the path but doesn't look like it worked.

Thanks for your reply @rvalieris, I doubt that I'll succeed where you've not, the cygwin team has also encountered problem with parallel packaging. I'll try to build Rust parallel which syntax is close to GNU parallel. Should I close this issue ?

Thanks for your reply @rvalieris, I doubt that I'll succeed where you've not, the cygwin team has also encountered problem with parallel packaging. I'll try to build Rust parallel which syntax is close to GNU parallel. Should I close this issue ?

its better to leave the issue open in case others find the same issue.
also ping @xhochy any help would be appreciated

its better to leave the issue open in case others find the same issue.
also ping @xhochy any help would be appreciated


The latest version is not stable

I have updated to the latest version but I see an error:

When I run data analysis with Data Classification, I often see errors that cannot complete the training and I have to retrain many times.
When I retrain, I often get an error where the training time count is faster than it actually is, so I have to turn off visualstudio and restart it.
Training results are not as good as the previous version

Hi @trancoc,
Can you please share the errors you're seeing?


Renamed SHIFT, Vigenere, and SUBST md files.

Vigenere_Cipher.md -> VIGINERE_CIPHER.md
SHIFT.md -> SHIFT_CIPHER.md
SUBST.md -> SUBSTITUTION_CIPHER.md
Resolves #7

This resolves #7. I will merge the pull request.
Thank you for your contribution.


Improve error logging for Umbraco 7, 8 and 9

Looks fine. It is done the exact same way as in V10 right?

Yes correct.


Reset git tags to work around vgo

Here are the current tags:
f5d8d856b31995567b637d6f8eaa78ae2e0f9206 refs/tags/v1.0.0
762af81012744b1461f57d414b82f3ae9a9c5b99 refs/tags/v1.0.1
f23d78362d188e111f34ce5db305cc53e7f1b932 refs/tags/v1.1.0
acbcebe1cd4c60fe20fd3a5a3d64accd53058f2e refs/tags/v1.2.0
a56998ff69437c015617474a7eaf3b0f6bb92b9e refs/tags/v1.3.0
01e72ff44254c3a85e6544295da4ce04be23c356 refs/tags/v2.0.0
29f1845f11cf8b48016865be7381299056393f72 refs/tags/v2.1.0
02e1ea193747d24d87b484473511ce0e4356946c refs/tags/v2.1.1

I really hate to do this, but I haven't been able to get vgo to recognize the fact that there is a v2 version of go-irc, so to work around it I'm going to be resetting these tags so v1.0.0 will become v0.1.0, v1.0.1 will become v0.1.1, v1.1.0 will become v0.2.0 etc. I really do apologize to anyone who runs into this, but I don't currently have a better workaround.

I've decided not to do this and will find a better way to move forward.


Update server to Node 8

I just got word that the production servers are running Node 9.4.0! This is awesome!
Let's get our new service framework merged so we can plunge ahead with #1358.
Todos before merging (deploy blockers = merge blockers):

[ ] Replace disabled Node 6 tests with Node 9 tests
[ ] Fix unit test failures with isValidStyle https://circleci.com/gh/badges/shields/2840

Todos after:

[ ] Update the tutorial
[ ] Move the tests and the services alongside each other… maybe something like this:

services/appveyor/appveyor.js (exports one or more services)
services/appveyor/appveyor.tester.js (exports a ServiceTester)
services/appveyor/appveyor.spec.js (describe()'s and it()'s for the helper functions, if any)

Anything we should add?
Also, I'm assuming we will merge this using a regular merge workflow to keep the history. Alternatively we could rebase this first, with a new, cleaner history. That'll be a bit of work, though. Thoughts?

Sounds good to me,
Maybe for the merges just rebase/fixup the double master merges.
(may be more effort than it's worth though)
isValidStyle was removed in #1429, have opened #1544 which i think fixes it on this branch.
I like the idea of the tests and service being alongside each other, sounds good to me.

Thanks!

may be more effort than it's worth though

Yea, that's what I'm feeling. IIRC there were some conflicts which would have to be solved again.
I guess we could also squash. In the end, this is a pretty small diff.

Warnings

:warning:

This PR modified package.json, but not package-lock.json - Perhaps you need to run npm install?

:warning:

This PR modified the server but none of the service tests. That's okay so long as it's refactoring existing code.

:warning:

This PR modified helper functions in lib/ but not accompanying tests. That's okay so long as it's refactoring existing code.

Messages

:book:

:sparkles: Thanks for your contribution to Shields, @paulmelnikow!

  Generated by :no_entry_sign: dangerJS

Let's track the opens in #1358.