text:
Trouble with runing an app which uses PythonCall

Hello!
I've an error when i'm trying to run an created app which uses PythonCall.
Code for MWE is published here: https://github.com/YuliyaCl/PythonCall_tst.jl.
To create an app run file deploy/compile_app.sh .
Tests and building proccess run correctly but when I'm runing PythonCall_tst.exe in cmd, an error occurs:
fatal: error thrown and no exception handler available.
InitError(mod=:C, error=ErrorException("no environment in the LOAD_PATH depends on CondaPkg"))
error at .\error.jl:33
_resolve_top_env at C:\Users\yzh\.julia\packages\CondaPkg\Olo5Y\src\resolve.jl:16
#resolve#37 at C:\Users\yzh\.julia\packages\CondaPkg\Olo5Y\src\resolve.jl:307
resolve at C:\Users\yzh\.julia\packages\CondaPkg\Olo5Y\src\resolve.jl:288
envdir at C:\Users\yzh\.julia\packages\CondaPkg\Olo5Y\src\env.jl:70
init_context at C:\Users\yzh\.julia\packages\PythonCall\XgP8G\src\cpython\context.jl:56
__init__ at C:\Users\yzh\.julia\packages\PythonCall\XgP8G\src\cpython\CPython.jl:21
jfptr___init___36506.clone_1 at C:\Users\yzh\.julia\dev\PythonCall_tst\PythonCallCompiled\lib\julia\sys.dll (unknown line)
jl_apply at /cygdrive/c/buildbot/worker/package_win64/build/src\julia.h:1788 [inlined]
jl_module_run_initializer at /cygdrive/c/buildbot/worker/package_win64/build/src\toplevel.c:73
_finish_julia_init at /cygdrive/c/buildbot/worker/package_win64/build/src\init.c:796
jl_init_with_image at /cygdrive/c/buildbot/worker/package_win64/build/src\jlapi.c:74 [inlined]
jl_init_with_image at /cygdrive/c/buildbot/worker/package_win64/build/src\jlapi.c:63 [inlined]
jl_init at /cygdrive/c/buildbot/worker/package_win64/build/src\jlapi.c:90
.text at C:\Users\yzh\.julia\dev\PythonCall_tst\PythonCallCompiled\bin\PythonCall_tst.exe (unknown line)
__tmainCRTStartup at C:\Users\yzh\.julia\dev\PythonCall_tst\PythonCallCompiled\bin\PythonCall_tst.exe (unknown line)
.l_start at C:\Users\yzh\.julia\dev\PythonCall_tst\PythonCallCompiled\bin\PythonCall_tst.exe (unknown line)
BaseThreadInitThunk at C:\windows\System32\KERNEL32.DLL (unknown line)
RtlUserThreadStart at C:\windows\SYSTEM32\ntdll.dll (unknown line)

OS: Windows 10
Do you have any ideas how to solve it? Thanks!
Yuliya

Addition information about the issue.
To reproduce the error itself you may compile an app and run the function:
using CondaPkg
PythonCallCompiled\\share\\julia\\Project.toml._resolve_top_env( [ pathToTheProjectToml ] )

pathToTheProjectToml - it's a path to Project.toml file inside folder with compiled app - "....\share\julia\Project.toml"
Also the difference in output occurs when run Base.manifest_uuid_path() with two Project files (to reproduce the error change the paths to yours)
pkg = Base.PkgId(Base.UUID("992eb4ea-22a4-4c89-a5bb-47a3300528ab"), "CondaPkg")
env_raw = "C:\\Users\\yzh\\.julia\\dev\\PythonCall_tst\\Project.toml" #inside the repo
env_compiled = "C:\\Users\\yzh\\.julia\\dev\\PythonCall_tst\\PythonCallCompiled\\share\\julia\\Project.toml" #inside the compiled app folder

out1 = Base.manifest_uuid_path(env_raw, pkg) # -> "C:\\Users\\yzh\\.julia\\dev\\CondaPkg"
out2 = Base.manifest_uuid_path(env_compiled, pkg)  # -> nothing

Place in CondaPkg.jl where this trouble occurs: https://github.com/cjdoris/CondaPkg.jl/blob/78f2a639b5bfb88920c7021c568e39d87c112950/src/resolve.jl#L9

Thanks for the answer!
I've compiled an app without any dependencies. Manifest.toml wasn't created

The problem is in CondaPkg. I've compile an app with only CondaPkg in the deps. It failed at line  CondaPkg.status()...
So redirect this issue to CondaPkg.jl ..


text:
🛑 IP Checker is down

In 8f6e4ca, IP Checker (https://ip.cjthedj97.me) was down:

HTTP code: 503
Response time: 31 ms

Resolved: IP Checker is back up in bf76762.

source: gharchive/issue

license: MIT

license_type: permissive

license_source: github-api


text:
Vk8s kubeconfig

vk8s kubeconfigs must be created with the namespace of the vk8s:
module "vk8s_consul" {
  source                    = "./modules/f5xc/v8ks"
  f5xc_tenant               = var.f5xc_tenant
  f5xc_api_url              = var.f5xc_api_url
  f5xc_api_token            = var.f5xc_api_token
  f5xc_vk8s_name            = format("%s-consul", var.project_prefix)
  f5xc_vk8s_namespace       = module.namespace_consul.namespace["name"]
  f5xc_namespace            = module.namespace_consul.namespace["name"]
  f5xc_create_k8s_creds     = true
  f5xc_k8s_credentials_name = format("%s-vk8s-consul-creds", var.project_prefix)
  f5xc_virtual_site_refs    = [module.virtual_site_consul.virtual-site["name"]]
  f5xc_vsite_refs_namespace = "shared"
}
output "kube_config" {
  value     = module.vk8s_consul.vk8s["k8s_conf"]
  sensitive = true
}

I got this error when applying:
odule.vk8s_consul.module.api_credential_kubeconfig[0].null_resource.apply_credential (local-exec): POST request url: https://volterra-corp.staging.volterra.us/api/web/namespaces/system/api_c
redentials
module.vk8s_consul.module.api_credential_kubeconfig[0].null_resource.apply_credential (local-exec): {
module.vk8s_consul.module.api_credential_kubeconfig[0].null_resource.apply_credential (local-exec):    "expiration_days": "10",
module.vk8s_consul.module.api_credential_kubeconfig[0].null_resource.apply_credential (local-exec):    "name": "uc01-vk8s-consul-creds",
module.vk8s_consul.module.api_credential_kubeconfig[0].null_resource.apply_credential (local-exec):    "namespace": "system",
module.vk8s_consul.module.api_credential_kubeconfig[0].null_resource.apply_credential (local-exec):    "spec": {
module.vk8s_consul.module.api_credential_kubeconfig[0].null_resource.apply_credential (local-exec):       "password": "",
module.vk8s_consul.module.api_credential_kubeconfig[0].null_resource.apply_credential (local-exec):       "type": "KUBE_CONFIG",
module.vk8s_consul.module.api_credential_kubeconfig[0].null_resource.apply_credential (local-exec):       "virtual_k8s_name": "uc01-consul",
module.vk8s_consul.module.api_credential_kubeconfig[0].null_resource.apply_credential (local-exec):       "virtual_k8s_namespace": "default"
module.vk8s_consul.module.api_credential_kubeconfig[0].null_resource.apply_credential (local-exec):    }
module.vk8s_consul.module.api_credential_kubeconfig[0].null_resource.apply_credential (local-exec): }
module.vk8s_consul.module.api_credential_kubeconfig[0].null_resource.apply_credential (local-exec): Response Status Code: 500 --> Response Message: {'code': 13, 'details': [{'type_url': 'type
.googleapis.com/ves.io.stdlib.server.error.Error', 'value': 'Gno vK8s cluster: uc01-consul found under tenant: volterra-corp-swkjijtd<2023-01-30 16:12:01.385091774 +0000 UTC m=+1300680.138963
711'}], 'message': 'There was a server error in processing request'}
module.vk8s_consul.module.api_credential_kubeconfig[0].null_resource.apply_credential: Creation complete after 6s [id=6881683356150900541]
module.vk8s_consul.module.api_credential_kubeconfig[0].data.local_file.state: Reading...
╷
│ Error: Read local file data source error

The proposed changes adds  f5xc_vk8s_namespace  and removes the hard coded 'default' to create the api-credential and the kubeconfig successfully:
$ terraform output kube_config |grep namespace
    server: https://volterra-corp.staging.volterra.us/api/vk8s/namespaces/uc01-consul/uc01-consul
    namespace: uc01-consul

My changes are only validated to get my script to pass. Likely I broke something else. Please review and suggest any changes.

Having an issue when running 'terraform apply' again without changes. I think this is unrelated to my merge request, but still an issue:
module.vk8s_consul.module.vk8s_wait_for_online.null_resource.check_vk8s_status: Destruction complete after 0s
module.vk8s_consul.module.vk8s_wait_for_online.null_resource.check_vk8s_status: Creating...
module.vk8s_consul.module.vk8s_wait_for_online.null_resource.check_vk8s_status: Provisioning with 'local-exec'...
module.vk8s_consul.module.vk8s_wait_for_online.null_resource.check_vk8s_status (local-exec): Executing: ["/usr/bin/env" "bash" "-c" "modules/f5xc/status/vk8s/scripts/check.sh https://volterra-corp.staging.volterra.us/api/config/namespaces/uc01-consul/virtual_k8ss/uc01-consul?response_format=GET_RSP_FORMAT_DEFAULT wba5qPf36emikbh6iPerh8FBZGA= volterra-corp-swkjijtd https://volterra-corp.staging.volterra.us/api/config/namespaces/uc01-consul/virtual_k8ss?label_filter=tf_vk8s_filter=uc01-consul"]
module.vk8s_consul.module.vk8s_wait_for_online.null_resource.check_vk8s_status (local-exec): Status check URL: https://volterra-corp.staging.volterra.us/api/config/namespaces/uc01-consul/virtual_k8ss?label_filter=tf_vk8s_filter=uc01-consul -H accept: application/data -H Access-Control-Allow-Origin: * -H Authorization: APIToken wba5qPf36emikbh6iPerh8FBZGA= -H x-volterra-apigw-tenant: volterra-corp-swkjijtd
module.vk8s_consul.module.vk8s_wait_for_online.null_resource.check_vk8s_status (local-exec): 200 OK. Good to go...
module.vk8s_consul.module.vk8s_wait_for_online.null_resource.check_vk8s_status (local-exec): Found labeled vK8s entry. Checking initializers now...
module.vk8s_consul.module.vk8s_wait_for_online.null_resource.check_vk8s_status (local-exec): vk8s instance created. Leaving...
module.vk8s_consul.module.vk8s_wait_for_online.null_resource.check_vk8s_status: Creation complete after 0s [id=8207086572359786576]
module.vk8s_consul.module.api_credential_kubeconfig[0].data.local_file.state: Reading...
╷
│ Error: Read local file data source error
│
│   with module.vk8s_consul.module.api_credential_kubeconfig[0].data.local_file.state,
│   on modules/f5xc/api-credential/data.tf line 1, in data "local_file" "state":
│    1: data "local_file" "state" {
│
│ The file at given path cannot be read.
│
│ +Original Error: open
│ modules/f5xc/api-credential/_out/uc01-vk8s-consul-creds/state.json: no such
│ file or directory
╵
Operation failed: failed running terraform apply (exit 1)

Another issue with api-credentials triggered via f5xc_create_k8s_creds  = true: They don't get removed when destroyed:

source: gharchive/pull-request


text:
Decrease bundle size

I've been running some bundle analyzers in the code to see what we can change to decrease the bundle size:

There is a lot of room for improvements, I'll use this issue to list my findings and track my progress

[x]  remove lodash.uniqBy
[x]  remove lodash.isequal
[x]  remove lodash.merge
[x]  remove lodash.once
[x]  remove lodash.isplainobject
[x]  remove lodash.result
[x]  figure out where this buffer module is coming from
[ ]  remove the process polyfill
[ ]  use babel-preset-env to improve our babel pipeline and avoid unnecessary polyfills
[ ]  test CommonsChunkPlugin for multiple bundles and async load of big dependencies
[ ]  try to remove clappr-zepto 🔥
[ ] use module field in package.json to es6 version of the code
[ ] only export plugins in the main and dont require all in the Loader
[ ] remove white spaces from template/css code

current bundle size is 521kb

The "main" property in package.json of clappr-zepto module is pointing to zepto.min.js. Maybe it worth a try to change the value to zepto.js and try to rebuild Clappr to see if it reduce size of bundle minified by uglifyjs.

@thiagopnts
Another idea is to add a release job to make a "light" version of Clappr which excludes FlashLS, as probably the majority of developers using Clappr don't even need Flash support at this point in 2017. (At least I hope so)
I have a fork of Clappr on my GitHub profile where I stripped out FlashLS entirely. See commit: https://github.com/michaelcunningham19/clappr/commit/a00b12ea0c27dbd5011f1b134a6bc2d2ea196f2e
The change resulted in a decent decrease in file size, which I will add here when I can! :)
If this sounds like a good idea I will gladly look into opening a PR to support a "light" build
Worth noting that hls.js also has a "light" build that they recently added: https://github.com/video-dev/hls.js#dependencies

@michaelcunningham19 I'm working on this here https://github.com/clappr/clappr/tree/skinny-clappr
it has a ~175kb light version

authors: kslimani michaelcunningham19 thiagopnts

repo: clappr/clappr

license_source: bigquery


text:
Javascript error on FireFox prevents loading player

Browser: FireFox 54.0.1 (64-bit)
OS: Windows 10
Clappr version as of 07 July 2017 via https://cdn.jsdelivr.net/clappr/latest/clappr.min.js
[error][MediaControl] error on event mediacontrol:hide trigger - TypeError: this.getCurrentContainer(...) is undefined
Stack trace:
O</e.prototype.onMediaControlShow@https://cdn.jsdelivr.net/clappr/latest/clappr.min.js:1:99569
i@https://cdn.jsdelivr.net/clappr/latest/clappr.min.js:1:1600
p@https://cdn.jsdelivr.net/clappr/latest/clappr.min.js:1:1957
g</t.prototype.trigger@https://cdn.jsdelivr.net/clappr/latest/clappr.min.js:1:3160
q</e.prototype.hide@https://cdn.jsdelivr.net/clappr/latest/clappr.min.js:1:118285
q</e.prototype.render/this.hideId<@https://cdn.jsdelivr.net/clappr/latest/clappr.min.js:1:123642
No issues whatsoever on Chrome, Opera, Edge, Android Chrome, IOS.

@Support-Vezca can you reproduce the error on http://clappr.io/demo/ ?
(or in the contrary, can you provide a demo page which reproduce the error ?)

@kslimani everything A+ on the demo page. I recently wrapped the iframe with a jquery fadein script in order to show a spinner until the actual iframe page loads (a html page with its own isolated clappr)... now although one would think this should not impact the iframe page as the fade logic is outside of the iframe html page, but it appears it does have an impact on clappr. I just removed the logic and everything is fine.
This is the code I added for the iframe:
 var theIframe = document.getElementById('v_' + assetid);         if (navigator.userAgent.indexOf("MSIE") > -1 && !window.opera) {             theIframe.onreadystatechange = function () {                 if (theIframe.readyState == "complete") {                     //$("#vcHolder").remove();                     $("#vcHolder").fadeOut(1000, function () { $(".vGlow_" + assetid).fadeIn(1000, function () { $("#vcHolder").remove() }); });                 }             };         } else {             theIframe.onload = function () {                 $("#vcHolder").fadeOut(1000, function () { $(".vGlow_" + assetid).fadeIn(1000, function () { $("#vcHolder").remove() }); });             };         }
The iframe is inside a div called 'vGlow', the div's inline style is set to 'display:none'... and of course the above code fades in that div once the iframe state changes to 'complete'.
Thus, it appears that on FireFox, if clappr is in an iframe which is inside a div which is set to 'display:none', the clappr javascript in the iframe page is unable to reference the div container on the page... ooo errrr??!
But none of this is an issue on other browsers, just FireFox it appears.
I'm going to quickly try something else, rather than the iframe parent div being set to display:none, I'll set it to visibility:hidden, and see if that makes a difference on FireFox.
If you have any opinions on any of the above, I'm all ears bud.

Ok, it works with visibility:hidden.
From the look of things, this appears to be an issue with how Firefox instantiates references to elements, ie if they are set to inline style of display:none at load then things go all pear shaped? or is Firefox following standards stringently and all the other browsers are being a little bit more flexible? no idea, but at least its all working.
Many thumbs up for Clappr, it really is an incredible feat of code for the massses without having to pay for commercial HLS/DASH player licenses.

A possible workaround may be to set width and height of the i-frame to 0x0 or 1x1 pixel while loading, and then properly resize it when loaded. (instead of not display)

authors: Support-Vezca kslimani


text:
onPlay/PLAYER_PLAY Not Firing When Loading New Source

Browser: Chrome Version 71.0.3578.98
OS: Windows 10
Clappr Version: 0.3.1
Steps to reproduce:

Load initial media source
Use player.load(newsource)
The onPlay/PLAYER_PLAY event is not firing when playback of the new source begins.  This was working prior to 0.3.

Did you try to reproduce this issue at http://cdn.clappr.io/
Yes, here is a link...
http://clappr.io/demo/#dmFyIHBsYXllckVsZW1lbnQgPSBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgicGxheWVyLXdyYXBwZXIiKTsKCnZhciBwbGF5ZXIgPSBuZXcgQ2xhcHByLlBsYXllcih7CiAgc291cmNlOiAnaHR0cDovL2NsYXBwci5pby9oaWdobGluZS5tcDQnLAogIHBvc3RlcjogJ2h0dHA6Ly9jbGFwcHIuaW8vcG9zdGVyLnBuZycsCiAgbXV0ZTogdHJ1ZSwKICBhdXRvUGxheTogdHJ1ZSwKICBoZWlnaHQ6IDM2MCwKICB3aWR0aDogNjQwLAogIGV2ZW50czogewoJCQlvblBsYXk6IGZ1bmN0aW9uKCkgewoJCQkJY29uc29sZS5sb2coJ3BsYXliYWNrIHN0YXJ0ZWQnKTsKCQkJfQoJCX0KfSk7CgpwbGF5ZXIuYXR0YWNoVG8ocGxheWVyRWxlbWVudCk7Cgp2YXIgbm9kZSA9IGRvY3VtZW50LmNyZWF0ZUVsZW1lbnQoImJ1dHRvbiIpOwp2YXIgdGV4dG5vZGUgPSBkb2N1bWVudC5jcmVhdGVUZXh0Tm9kZSgiQ2xpY2sgTWUiKTsKbm9kZS5hcHBlbmRDaGlsZCh0ZXh0bm9kZSk7CmRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCJvdXRwdXQiKS5hcHBlbmRDaGlsZChub2RlKTsKCm5vZGUub25jbGljayA9IGZ1bmN0aW9uKCkgewogIHBsYXllci5sb2FkKCdodHRwOi8vd3NlMS5yZXNvcnRjYW1zLmNvbS9saXZlL2JlZWNoc3VtbWl0LnN0cmVhbS9wbGF5bGlzdC5tM3U4Jyk7Cn07Cg==

I can also reproduce the issue with configure(). IT seems there is a regression in event binding when reloading a source. Demo code

@afonsocdaniel could you please re-open the issue, i confirm that calling player.configure() in 0.3.x seems to not "rebind" player events. (it is working in 0.2.100)

This issue should be fixed in next Clappr release. (fixed by #1778).

authors: kslimani thekendog


text:
fix: fixup download problem under Chrome iOS

can not download in Chrome iOS, because it will make a second request when you click download,
but the server has gone.
so, do not close the server, until the user decided to close it.
maybe related issue https://github.com/claudiodangelis/qrcp/issues/193

No，I tried keep-alive but it turns out doesn't work.

No，I tried keep-alive but it turns out doesn't work.

it does nothing to do with keep-alive

because when the first time Chrome loaded the image, the http server by qrcp has shutdown.
this PR try to solve the problem by not closing the server.

@claudiodangelis  with qrcp send -k this problem does resolved.
without -k, there's problem.

repo: claudiodangelis/qrcp


text:
Added possibility to use custom item names for DatSelect items.

PR suggestion for #31

Please add this new prop to the prop types definition for the component

Thanks. Added the optionLabels to prop types definitions!

@claus please cut a release when you can!

repo: claus/react-dat-gui

license: mit


text:
🛑 livevault is down

In 6b3f997, livevault (https://livevault.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: livevault is back up in 5f14e53.

repo: claytonplong/backup-uptime


text:
🛑 livevault is down

In efeda87, livevault (https://livevault.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: livevault is back up in d2c8cb9.


text:
🛑 livevault is down

In 2ce1d30, livevault (https://livevault.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: livevault is back up in 8c0568f.


text:
cli: Don't load config file when displaying help for sub-commands.

If the user simply want to see a usage statement for a sub-command, the
config file should not be loaded.
Related to #137.
Signed-off-by: James O. D. Hunt james.o.hunt@intel.com

Coverage decreased (-0.3%) to 34.936% when pulling a28053f0f1d48c3c12a9560ecc12d60914d6e50d on jodh-intel:dont-load-config-when-showing-subcommand-help into d9eeeda87b10bd13dbc2108e96cefacaeda1532e on clearcontainers:master.

lgtm

lgtm

authors: coveralls devimc dlespiau jodh-intel

repo: clearcontainers/runtime


text:
chore(clerk-js): Replace Avatar preview in OrganizationProfileAvatarUploader with Upload Button

Description
Replacing AvatarPreview in OrganizationProfileAvatarUploader with upload button in CreateOrganizationForm to avoid layout shift

Checklist

[ ] npm test runs as expected.
[ ] npm run build runs as expected.
[ ] (If applicable) JSDoc comments have been added or updated for any package exports
[ ] (If applicable) Documentation has been updated

Type of change

[ ] 🐛 Bug fix
[ ] 🌟 New feature
[ ] 🔨 Breaking change
[x] 📖 Refactoring / dependency upgrade / documentation
[ ] other:

Packages affected

[ ] @clerk/backend
[ ] @clerk/chrome-extension
[x] @clerk/clerk-js
[ ] @clerk/clerk-expo
[ ] @clerk/fastify
[ ] gatsby-plugin-clerk
[ ] @clerk/localizations
[ ] @clerk/nextjs
[ ] @clerk/clerk-react
[ ] @clerk/remix
[ ] @clerk/clerk-sdk-node
[ ] @clerk/shared
[ ] @clerk/themes
[ ] @clerk/types
[ ] build/tooling/chore

BEFORE
https://github.com/clerkinc/javascript/assets/14893769/83aa81b6-e1b2-41d1-90d2-d9adce39143e
AFTER
https://github.com/clerk/javascript/assets/14893769/facb344f-1d6a-48d1-8e37-0394ebebf417

Great stuff, i added a few minor comments

Thanks for the review @panteliselef
I addressed you comments and update after screenshot/video accordingly

repo: clerk/javascript


text:
fix(clerk-js): Show the long error message on Connected Accounts

Description
This PR brings also back the localization key userProfile.start.connectedAccountsSection.subtitle__reauthorize.
Desktop:

Mobile:

Checklist

[ ] npm test runs as expected.
[ ] npm run build runs as expected.
[ ] (If applicable) JSDoc comments have been added or updated for any package exports
[ ] (If applicable) Documentation has been updated

Type of change

[ ] 🐛 Bug fix
[ ] 🌟 New feature
[ ] 🔨 Breaking change
[ ] 📖 Refactoring / dependency upgrade / documentation
[ ] other:

!preview

Hey @octoper, your preview is currently deploying and should be available shortly.

Status
Preview
Updated (UTC)

:cook: Deploying...
Inspect
Feb 12, 2024 04:00 PM

authors: anagstef clerk-cookie octoper


text:
Is or will Elasticsearch 1.5 be supported in the future?

Hey guys,
I want to develop a web app using Elasticsearch and the Play Framework. The question I have is, if the newest version of elasticsearch which is 1.5 by the time of this post. Thanks!

+1 for elasticsearch 1.5.2 and/or Play 2.3.9/2.4.0

authors: mantsak mehrad-rafigh


text:
icepack crashes generating netpbm image on Windows

On Windows only, icepack -b (and other CRAM netpbm generating options) crashes after generating only the header. This bug doesn't appear to occur on Linux.
(The screenshot shows a version of icepack downloaded with apio, however I did recreate the issue with the latest source cloned from this repo and compiled)

When not run under a debugger this manifests itself as an opaque exit with no error message.
I've submitted a pull request that fixes this issue - the bug/fix is explained in detail within the commit message.

The relevant pull request
https://github.com/cliffordwolf/icestorm/pull/242

repo: cliffordwolf/icestorm

license: ISC


text:
Feature/pdct 633 add timeout exception to search api

Description
Please include:

Added timeout error handling
Added max_results query param and set default to 500
Updated family search to return 200 with empty response instead of 404 when no matching families found
Linear ticket PDCT-633

Type of change
Please select the option(s) below that are most relevant:

[ ] Bug fix
[x] New feature
[ ] Breaking change

How Has This Been Tested?
Unit & integration tests added.
Reviewer Checklist

[ ] The PR represents a single feature (small drive-by fixes are also ok)
[ ] The PR includes tests that are sufficient for the level of risk
[ ] The code is sufficiently commented, particularly in hard-to-understand areas
[ ] Any required documentation updates have been made
[ ] Any TODOs added are captured in future tickets
[ ] No FIXMEs remain

Would be good to chat, as it may also be an ideal to set the statement_timeout when we call create_engine here to something like 10s to improve the user experience. See https://stackoverflow.com/a/44936982

Addressed. Link to docs describing how we've configured this here https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNECT-CONNECT-TIMEOUT


text:
Come up with rewrite-clj logo

Originally raised by me https://github.com/lread/rewrite-cljc-playground/issues/69
Rewrite-cljc is dead, long live rewrite-clj.

Comment in issue from rewrite-cljc-playground:
@lread:
Current candidate:

Can always change later, at least we have something to start with.
@sogaiu:
Looks nice :)
Is there some hidden aspect of "change" in the logo (the looping back)?
@lread:
Thanks @sogaiu!

Is there some hidden aspect of "change" in the logo (the looping back)?

Like the arrow in rewrite-cljc logo, the arrow here supposed suggest rewriting.
One less character had me struggling with a short arrow and meant I could play with the j.
@sogaiu:
Have you tried playing with where the tip of the arrow ends?
For example:

@lread:
Had not thought of that, interesting idea!

Comment in issue from rewrite-cljc-playground:
@lread:
Current candidate:

Can always change later, at least we have something to start with.
@sogaiu:
Looks nice :)
Is there some hidden aspect of "change" in the logo (the looping back)?
@lread:
Thanks @sogaiu!

Is there some hidden aspect of "change" in the logo (the looping back)?

Like the arrow in rewrite-cljc logo, the arrow here supposed suggest rewriting.
One less character had me struggling with a short arrow and meant I could play with the j.
@sogaiu:
Have you tried playing with where the tip of the arrow ends?
For example:

@lread:
Had not thought of that, interesting idea!

I'm not in love with the new logo, but it is good enough for now.  Closing.

repo: clj-commons/rewrite-clj


text:
Add quotation marks

So that users can copy/paste the version string.
The canonical fix here is to use a clojars svg, but that has its failings.
Fixed up from #1

Thanks!
Just for the record:

I would write README: Add quotation marks, because then I see in the Git history where the change happened without --stat.

I don't like the Clojars SVG, because I can't copy and paste it… Or is there a trick?

authors: arrdem rmoehn

repo: clj-grenada/darkestperu


text:
Wef - "Could not establish trust relationship for the SSL/TLS"

Hey @clong,
Having this error while "vagrant-shell.ps1" is executing on wef, running on vmware-desktop and Vagrant:

This error occurs when reaching to line 142:
$config = Invoke-RestMethod -Uri "https://localhost/api/management/systemProfiles/gateways" -UseDefaultCredentials -UseBasicParsing
As a fix, you could add the following code:
add-type @"
using System.Net;
using System.Security.Cryptography.X509Certificates;
public class TrustAllCertsPolicy : ICertificatePolicy {
public bool CheckValidationResult(
ServicePoint srvPoint, X509Certificate certificate,
WebRequest request, int certificateProblem) {
return true;
}
}
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
Thanks!
Dvir

I think code that does effectively the same thing is right here: https://github.com/clong/DetectionLab/blob/master/Vagrant/scripts/install-microsoft-ata.ps1#L6-L26
I'm not able to reproduce this. Can you confirm that the script as written is not working for you?

Confirmed, a problem on my end.
Thanks @clong

@Dviros I am having the same issue. Could you go into some detail regarding the problem on your end? How did you fix this?

authors: Dviros clong lengers

repo: clong/DetectionLab


text:
GPGL issue for lamejs

We are using this module that comes under MIT licence, but this module is dependent on lamejs that comes under GPGL licence.
Do we have to confirm to lamejs for using this module?

Disclaimer: I'm not a lawyer and I don't know much about licenses, but:
Lame license is LPGL, actually. So if it's a commercial application, you probably need to fully acknowledge that you are using LAME, and link to their web site.

It seems that this package cannot/should not be licensed as "MIT".

authors: bradisbell buzinas quantaz


text:
ocm: move commands to script file

Move all commands to script file, then copy this file into orchestration host and then run it.
Description
Fixes

Murali, Harshith, Russ
is it possible to merge this PR  now, so that CI can run it today. OCM CI is already broken, so it won't cause any regression :slightly_smiling_face:
These code changes are  running successfully in my playground http://venkataanil-test-nocp-airflow.apps.sailplane.perf.lab.eng.rdu2.redhat.com/dags/ocm/grid?dag_run_id=scheduled__2022-11-17T01%3A00%3A00%2B00%3A00&task_id=api-load

repo: cloud-bulldozer/airflow-kubernetes


text:
Create Staged CI Pipeline

Description
This is a big one, so strap in. This PR adds a bunch of changes in order to test the quality and functionality of our code. I'll walk through the main changes one by one:
New pre-commit hooks for code quality and bug catching:
The goal with adding these additional pre-commit hooks is to add checks which will help keep our code clean and readable. I've been developing with these hooks setup for a couple of weeks now and not only have they have caught dozens of errors in my code, they've helped keep my code readable.

isort: works in the same way as black to automatically sort imports according to PEP standards
pylint: has checks which flake8 doesn't include; they are a good pair
pydocstyle: used for docstring enforcement.
mypy: ensures that type hints all agree with each other
pyupgrade: checks for older syntax expressions that can be refactored to take advantage of newer python syntax

I've disabled a lot of the more intrusive checks, but these hooks will break files and may need to be skipped until we have time to refactor our code. For instance, if I want to make a small change in a wrapper as a user, pre-commit may force me to fix a bunch of linting errors before being able to commit the change. Hooks can easily be skipped like so: SKIP=pylint git commit.
I understand these are intrusive, but I wanted to propose them because I feel in the long run they will be worth the extra effort. I think a nice compromise would be to not include the new hooks for now, but have our transitioned benchmark code be up-to-date with the new hooks' requirements.
Tox/Pytest Testing Structure
I created a structure to allow for unit and functional testing. It takes advantage of pytest and tox. Unit tests are located within the tests/unit directory while functional tests are located within tests/functional. I've configured tox with the following environments:

Unit tests: py36, py37, py38, py39
Documentation tests: docs
Functional tests: functional

I've also configured unit tests to generate coverage reports that can be sent off to codecov.com which allows us to visual which sections of our code are covered by our unit tests and which sections need some love.
Functional tests were a bit tricky to implement, but woah is the result cool. Under tests/functional there is the following directory structure:

tests/functional/benchmark: Folder containing functional test resources for a benchmark
tests/functional/benchmark/deploy.yaml: Kubernetes manifest which describes a pod to deploy before a test suite is run
tests/functional/benchmark/test_name.py: Module containing the actual tests to run

I've written a new fixture called manifest which is scoped at a module level. Whenever a test in a Python module uses this fixture, the fixture will find the companion deploy.yaml file that exists in the same directory as test module, deploy the manifest using rootless podman play kube, run all of the tests within the module, then tear-down any pods that were deployed with the label test=snafu. Unfortunately podman play doesn't have a teardown feature yet, so we have to delete pods manually by label.
An example of this structure can be seen in the Uperf tests that I've written for this PR.
What's cool about this is that we can use different pods for different tests, all for the same benchmark. And pods can be reused for multiple tests. For instance, if I wanted to have two different versions of elasticsearch while testing FIO, I could use the following directory structure:

tests/functional/fio/es6/{deploy.yaml,test_fio_es6.py}
tests/functional/fio/es7/{deploy.yaml,test_fio_es7.py}

All of the tests in test_fio_es6.py will use the same pod defined by es6/deploy.yaml and all of the tests within test_fio_es7.py will use the same pod defined by es7/deploy.yaml
Additionally, I've added two new command line arguments to pytest which control how pods are created and cleaned. Using --keep-pods will tell pytest to not delete pods after the test is complete, while using --use-existing-pods will tell pytest that the pod(s) for a test are already deployed and don't need to be setup. This means that I can run a test using tox -e functional -- --keep-pods and if the test fails, nothing is cleaned up, allowing for easy debug.
Finally, I've configured pytest to automatically mark functional tests with the appropriate benchmark name, which means that we can run all tests for ONLY a certain benchmark with the following: tox -e functional -- -k benchmark_name. The benchmark name is determined from the directory which follows tests/functional, so all tests under tests/functional/uperf will be marked with uperf.
This change allows us to test fully test snafu on our workstations, using just Python and rootless podman.
GitHub Actions CI
Lastly, I've created new workflow files which will run our linting, unit and functional tests within GitHub actions. The workflows are configured to run on a push or a pull_request and can be triggered manually. You can see example runs over at my fork: https://github.com/learnitall/benchmark-wrapper/runs/3089605349?check_suite_focus=true
The first workflow runs linting tests, an install test, unit tests and doc tests for Python 3.6-3.9. It's pretty much the same as the ci.yaml workflow that we had before, but with added pytest stuffs. I've configured this workflow to upload coverage reports to Codecov, so if we want to keep this feature we will need to setup codecov for snafu under cloud-bulldozer.
The second workflow (functional.yaml) will do the following:

Autodetect all Dockerfiles and Containerfiles within the repository and determine the associated benchmark (based on where it was found) and architecture (based on the extension).
Determine which images need to be built and tested based off of what files were changed
In parallel, for each of the changed images:

Build each of the container files
Push to quay.io, tagged with the GitHub commit SHA. Auth is configured through GitHub secrets
Run the associated functional tests

The auto-detect functionality is provided through a bash script located at ci/discover_cfs.sh, which outputs parsable-JSON to configure a GH actions matrix
The cool part about this is that:

We only run the tests for benchmarks that have been changed.
If a change impacts all benchmarks, then all benchmarks will be tested.
Built images are pushed to quay so we can perform further analysis as needed. To see an example of this, my quay account is rydrew
Images pushed to quay are identified by commit, therefore there is no potential for overlap between commits
We can manually trigger builds using the GH Actions UI.
Workflows can be run in forks, meaning PR can be thoroughly tested before they are submitted.

One awesome note is that I've configured the manual trigger to allow us to compare any two branches, not just between master. This can help development by allowing us to test differences between any two pieces of our code. In my fork I can create a branch, make some changes, create a branch off of that branch, make some changes, and only test the differences between those two branches. Can really help with the debug process if you're into branching.

There are a couple of notes that I have which we need to figure out before we can merge:

We need to modify the functional.yaml workflow so it works for our quay account and isn't linked to mine. Auth also needs to be setup within our secrets
The ppc64le builds take longer than an hour. I can move them to a separate workflow if we'd like?
The following AMD64 images currently have failing builds: linpack, oslat, cyclictest.

Thanks! Sorry for the wall of text!

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@d64c991). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #299   +/-   ##
=========================================
  Coverage          ?   20.51%
=========================================
  Files             ?       59
  Lines             ?     4358
  Branches          ?        0
=========================================
  Hits              ?      894
  Misses            ?     3464
  Partials          ?        0

Flag
Coverage Δ

3.8
20.51% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Continue to review full report at Codecov.

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

Looks like GH Actions ran for this PR, cool! I'll look into the errors on Monday.

I didn't like how the each job would appear in the UI- it was super messy having 15+ jobs all thrown in there. I consolidated the unit tests and documentation tests into one job, but kept our ability to run the tests against each Python version. Now:

Unit tests are ran within a different workflow than documentation tests
Image build tests will only run if unit tests succeed
Unit tests and documentation tests will run each suite of tests against Python 3.6, 3.7 and 3.8 sequentially. We lose parallel execution, but it only takes about 5 minutes anyways.

For now I am disabling having the functional tests be triggered by the successful completion of the "Unit Tests" workflow. Workflows can only be triggered by another workflow if they are in the default branch, therefore the functional tests right now will not run for this PR. Changing our setup temporarily so we can test out the functional test CI. After we merge, here is what the top of the functional.yml file needs to be changed to in order to enable the more 'staged' setup:
name: Build Images
on:
  workflow_run:
    workflows: ["Unit Tests"]
    types: [completed]
...
jobs:
  find-cfs:
    if: >-
        github.event_name != 'workflow_run' ||
        github.event_name == 'workflow_run' && github.event.workflow_run.conclusion == 'success'

I'm separating out the image build step from the image push step, in an effort to prevent "pwn requests", (https://securitylab.github.com/research/github-actions-preventing-pwn-requests/) as pushing images requires access to secrets.
Two items that we may need to figure out is are:

ppc64le builds all time out. This may be because I have the amd64 runners that GitHub provides emulating ppc64le in order to do the build. We could think about hosting our own GitHub runner that uses the architecture to speed things up or remove them from the CI.
I'm going to work tomorrow on integrating the 'ok-to-test' label in, as the CI is currently set to rebuild on every push and it is getting spammed like crazy while I'm trying to test.

I've disabled multi-arch builds while we figure out what we want to do with our ppc64le Dockerfiles. No point in running them over and over again if we know they time out.

This PR is super huge. I'm realizing that it needs to be split into different parts in order to make review a bit easier. Closing this out, will open new PRs this week.

authors: codecov-commenter learnitall

repo: cloud-bulldozer/benchmark-wrapper


text:
Can we fix the failing module.yaml change

Can we fix the failing module.yaml change

its fixed, but failing test, due to common services issue on the cluster. I've already raised an issue https://github.ibm.com/gsi-labs/industry-cloud-planning/issues/820 to recreate the cluster.

Fixed the common services issue on CP4I cluster, now ES passed successfully.

authors: JyotiRani mjperrins


text:
🛑 console.idcloudhost.com is down

In db8be7e, console.idcloudhost.com (https://console.idcloudhost.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: console.idcloudhost.com is back up in 986e7bf.

repo: cloudbip/upptime


text:
🛑 ach.id is down

In ff619d1, ach.id (https://ach.id) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ach.id is back up in f4098c4 after 18 minutes.


text:
🛑 berdu.id is down

In eae7c15, berdu.id (https://berdu.id) was down:

HTTP code: 0
Response time: 0 ms

Resolved: berdu.id is back up in aa7e567.


text:
🛑 lintas.net.id is down

In 4b44b3b, lintas.net.id (https://lintas.net.id) was down:

HTTP code: 0
Response time: 0 ms

Resolved: lintas.net.id is back up in cac94dd after 18 minutes.


text:
🛑 daeliweb.com is down

In 461cd50, daeliweb.com (https://daeliweb.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: daeliweb.com is back up in df99534.


text:
🛑 puskomedia.id is down

In b6cc92f, puskomedia.id (https://puskomedia.id) was down:

HTTP code: 0
Response time: 0 ms

Resolved: puskomedia.id is back up in 7665cbb after 8 minutes.


text:
🛑 hostingpas.com is down

In e624798, hostingpas.com (https://hostingpas.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: hostingpas.com is back up in 2c40855 after 8 minutes.


text:
🛑 member.idwebhost.com is down

In 42c2f55, member.idwebhost.com (https://member.idwebhost.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: member.idwebhost.com is back up in 296f044.


text:
🛑 cbn.id is down

In 5840403, cbn.id (https://cbn.id) was down:

HTTP code: 0
Response time: 0 ms

Resolved: cbn.id is back up in c166e2a.


text:
🛑 cbn.id is down

In e758663, cbn.id (https://cbn.id) was down:

HTTP code: 0
Response time: 0 ms

Resolved: cbn.id is back up in 60bf4c7.


text:
🛑 cbn.id is down

In 87b86c7, cbn.id (https://cbn.id) was down:

HTTP code: 0
Response time: 0 ms

Resolved: cbn.id is back up in 6115950.


text:
🛑 daeliweb.com is down

In d622ea3, daeliweb.com (https://daeliweb.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: daeliweb.com is back up in 20e5f5f.


text:
fix tests and update README

add dependency vendoring instructions
fix tests so that Travis starts passing

LGTM

authors: tangiel tbetbetbe

repo: cloudendpoints/endpoints-java


text:
Cloudflare page on paper_lantern

We have detected that the Cloudflare page under cPanel with paper_lantern them is not showing up correctly: http://www.awesomescreenshot.com/0b5594vb48
cPanel version: 11.50
CF plugin version: 5.3.6
Can you please advise?

Hi there,
Can you please open up a ticket by emailing partnersupport@cloudflare.com, and include the following information:

Output from running cat /usr/local/cpanel/etc/cloudflare.json
Output from running cat /usr/local/cpanel/etc/logs/error_log

This will ensure you receive the appropriate report!

I'm detecting that a new version has been made available since I've opened this issue, 5.3.8 - which apparently fixes the problem reported. :) The cloudflare_update.sh though has some bugs when going from 5.3.6 to 5.3.8 - which I'll report to that email address. Thanks much.

authors: lehels martijngonlag

repo: cloudflare/CloudFlare-CPanel


text:
Update index.md

add GitLab to overview page
cc @Ekwuno

Closing as the main page has already been changed to generic, Git provider

repo: cloudflare/cloudflare-docs


text:
Add firewall access rules endpoint

This PR implements the endpoint for firewall access rules (for a zone). Travis will fail because of:
/cloudflare-php/src/Endpoints/AccessRules.php:17  The method listRules has 11 parameters. Consider reducing the number of parameters to less than 10.

(Maybe the ExcessiveParameterList rule needs to set to >= 11).

Thanks for contributing. Two things before I merge:

We should have the configuration match the existing interface. If you want to refactor this, ideally we should refactor all configurations using that interface in a separate PR.
Please lint the code using make fix

I've incorporated your review. Let me know what you think.

authors: IcyApril kleisauke

repo: cloudflare/cloudflare-php


text:
h3: refactor Config API and remove priority placeholder setting

HTTP/3 draft-23 removed prioritization. This change
removes the "num placeholders" settings which
means that we slightly modify the public API for HTTP/3
config: h3::Config::new() and quiche_h3_config_new()
by removing that parameter.
Placeholders were a server-advertised feature, so this
change has the nice effect of making the API more sane
for clients.

LGTM however only concern I have is API change. This will break existing applications which use libquiche (I don't know how many in the field). Of course QUIC/H3 draft is still evolving so expecting a few more change like this, I think it's good time to think about how we keep backward compatibility of APIs or making APIs more extensible with such changes.

@junhochoi I agree with your concerns.
Since we are making a breaking change, I decided to go the whole hog and make the creation of the h3::Config option more extensible by adding functions to change specific properties. This gives us better granularity over changes to the properties available today, and sets a framework for future additions.

This looks great, though we can probably avoid calling set_max_header_list_size() explicitly in most places (benchmarks, examples, tests, ...). We were setting an explicit size before because we had to, but we don't need to anymore.

Good point!

LGTM. I think this API style is better.

Thanks to @LPardue's PR, curl is ready for the API change.

authors: LPardue bagder ghedo junhochoi

repo: cloudflare/quiche


text:
cloudflare_custom_hostname does not keep showing ownership_verification or validation_records after verification

Confirmation

[X] My issue isn't already found on the issue tracker.
[X] I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version
Terraform v1.0.11
on darwin_arm64
provider registry.terraform.io/cloudflare/cloudflare v3.9.1
provider registry.terraform.io/hashicorp/aws v3.74.2
Affected resource(s)

cloudflare_custom_hostname

Terraform configuration files
resource "cloudflare_custom_hostname" "sans" {
  zone_id  = "6a9006164edb31aca836cf6f4d0c6184"
  hostname = "custom.paradox.ai"
  ssl {
    method = "txt"
    settings {
      http2 = "on"
      tls13 = "on"
      min_tls_version = "1.2"
    }
  }
}

Debug output
2022-02-17T08:07:02.607-0700 [DEBUG] Adding temp file log sink: /var/folders/hj/sd6xmf7x62798sq7d6z6kp040000gn/T/terraform-log201296396
2022-02-17T08:07:02.607-0700 [INFO]  Terraform version: 1.0.11
2022-02-17T08:07:02.607-0700 [INFO]  Go runtime version: go1.16.4
2022-02-17T08:07:02.607-0700 [INFO]  CLI args: []string{"/Users/brian.dandoy/.asdf/installs/terraform/1.0.11/bin/terraform", "apply"}
2022-02-17T08:07:02.607-0700 [DEBUG] Attempting to open CLI config file: /Users/brian.dandoy/.terraformrc
2022-02-17T08:07:02.607-0700 [DEBUG] File doesn't exist, but doesn't need to. Ignoring.
2022-02-17T08:07:02.607-0700 [DEBUG] ignoring non-existing provider search directory terraform.d/plugins
2022-02-17T08:07:02.607-0700 [DEBUG] ignoring non-existing provider search directory /Users/brian.dandoy/.terraform.d/plugins
2022-02-17T08:07:02.607-0700 [DEBUG] ignoring non-existing provider search directory /Users/brian.dandoy/Library/Application Support/io.terraform/plugins
2022-02-17T08:07:02.607-0700 [DEBUG] ignoring non-existing provider search directory /Library/Application Support/io.terraform/plugins
2022-02-17T08:07:02.607-0700 [INFO]  CLI command args: []string{"apply"}
2022-02-17T08:07:02.608-0700 [DEBUG] New state was assigned lineage "d530782b-f7e8-fd4e-eae8-931ab1a62901"
2022-02-17T08:07:02.618-0700 [DEBUG] checking for provisioner in "."
2022-02-17T08:07:02.618-0700 [DEBUG] checking for provisioner in "/Users/brian.dandoy/.asdf/installs/terraform/1.0.11/bin"
2022-02-17T08:07:02.619-0700 [INFO]  Failed to read plugin lock file .terraform/plugins/darwin_arm64/lock.json: open .terraform/plugins/darwin_arm64/lock.json: no such file or directory
2022-02-17T08:07:02.619-0700 [INFO]  backend/local: starting Apply operation
2022-02-17T08:07:02.620-0700 [DEBUG] created provider logger: level=debug
2022-02-17T08:07:02.620-0700 [INFO]  provider: configuring client automatic mTLS
2022-02-17T08:07:02.642-0700 [DEBUG] provider: starting plugin: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.9.1/darwin_arm64/terraform-provider-cloudflare_v3.9.1 args=[.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.9.1/darwin_arm64/terraform-provider-cloudflare_v3.9.1]
2022-02-17T08:07:02.644-0700 [DEBUG] provider: plugin started: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.9.1/darwin_arm64/terraform-provider-cloudflare_v3.9.1 pid=17820
2022-02-17T08:07:02.644-0700 [DEBUG] provider: waiting for RPC address: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.9.1/darwin_arm64/terraform-provider-cloudflare_v3.9.1
2022-02-17T08:07:02.651-0700 [INFO]  provider.terraform-provider-cloudflare_v3.9.1: configuring server automatic mTLS: timestamp=2022-02-17T08:07:02.651-0700
2022-02-17T08:07:02.658-0700 [DEBUG] provider: using plugin: version=5
2022-02-17T08:07:02.658-0700 [DEBUG] provider.terraform-provider-cloudflare_v3.9.1: plugin address: address=/var/folders/hj/sd6xmf7x62798sq7d6z6kp040000gn/T/plugin1238446969 network=unix timestamp=2022-02-17T08:07:02.658-0700
2022-02-17T08:07:02.684-0700 [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"
2022-02-17T08:07:02.684-0700 [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.9.1/darwin_arm64/terraform-provider-cloudflare_v3.9.1 pid=17820
2022-02-17T08:07:02.684-0700 [DEBUG] provider: plugin exited
2022-02-17T08:07:02.685-0700 [INFO]  terraform: building graph: GraphTypeValidate
2022-02-17T08:07:02.685-0700 [DEBUG] ProviderTransformer: "cloudflare_custom_hostname.sans" (*terraform.NodeValidatableResource) needs provider["registry.terraform.io/cloudflare/cloudflare"]
2022-02-17T08:07:02.685-0700 [DEBUG] ReferenceTransformer: "cloudflare_custom_hostname.sans" references: []
2022-02-17T08:07:02.685-0700 [DEBUG] ReferenceTransformer: "provider["registry.terraform.io/cloudflare/cloudflare"]" references: []
2022-02-17T08:07:02.685-0700 [DEBUG] Starting graph walk: walkValidate
2022-02-17T08:07:02.686-0700 [DEBUG] created provider logger: level=debug
2022-02-17T08:07:02.686-0700 [INFO]  provider: configuring client automatic mTLS
2022-02-17T08:07:02.707-0700 [DEBUG] provider: starting plugin: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.9.1/darwin_arm64/terraform-provider-cloudflare_v3.9.1 args=[.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.9.1/darwin_arm64/terraform-provider-cloudflare_v3.9.1]
2022-02-17T08:07:02.709-0700 [DEBUG] provider: plugin started: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.9.1/darwin_arm64/terraform-provider-cloudflare_v3.9.1 pid=17821
2022-02-17T08:07:02.709-0700 [DEBUG] provider: waiting for RPC address: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.9.1/darwin_arm64/terraform-provider-cloudflare_v3.9.1
2022-02-17T08:07:02.716-0700 [INFO]  provider.terraform-provider-cloudflare_v3.9.1: configuring server automatic mTLS: timestamp=2022-02-17T08:07:02.715-0700
2022-02-17T08:07:02.723-0700 [DEBUG] provider: using plugin: version=5
2022-02-17T08:07:02.723-0700 [DEBUG] provider.terraform-provider-cloudflare_v3.9.1: plugin address: network=unix address=/var/folders/hj/sd6xmf7x62798sq7d6z6kp040000gn/T/plugin974722975 timestamp=2022-02-17T08:07:02.723-0700
2022-02-17T08:07:02.747-0700 [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"
2022-02-17T08:07:02.748-0700 [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.9.1/darwin_arm64/terraform-provider-cloudflare_v3.9.1 pid=17821
2022-02-17T08:07:02.748-0700 [DEBUG] provider: plugin exited
2022-02-17T08:07:02.748-0700 [INFO]  backend/local: apply calling Plan
2022-02-17T08:07:02.748-0700 [INFO]  terraform: building graph: GraphTypePlan
2022-02-17T08:07:02.748-0700 [DEBUG] ProviderTransformer: "cloudflare_custom_hostname.sans (expand)" (*terraform.nodeExpandPlannableResource) needs provider["registry.terraform.io/cloudflare/cloudflare"]
2022-02-17T08:07:02.748-0700 [DEBUG] ReferenceTransformer: "provider["registry.terraform.io/cloudflare/cloudflare"]" references: []
2022-02-17T08:07:02.748-0700 [DEBUG] ReferenceTransformer: "cloudflare_custom_hostname.sans (expand)" references: []
2022-02-17T08:07:02.749-0700 [DEBUG] Starting graph walk: walkPlan
2022-02-17T08:07:02.749-0700 [DEBUG] created provider logger: level=debug
2022-02-17T08:07:02.749-0700 [INFO]  provider: configuring client automatic mTLS
2022-02-17T08:07:02.771-0700 [DEBUG] provider: starting plugin: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.9.1/darwin_arm64/terraform-provider-cloudflare_v3.9.1 args=[.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.9.1/darwin_arm64/terraform-provider-cloudflare_v3.9.1]
2022-02-17T08:07:02.772-0700 [DEBUG] provider: plugin started: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.9.1/darwin_arm64/terraform-provider-cloudflare_v3.9.1 pid=17822
2022-02-17T08:07:02.773-0700 [DEBUG] provider: waiting for RPC address: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.9.1/darwin_arm64/terraform-provider-cloudflare_v3.9.1
2022-02-17T08:07:02.779-0700 [INFO]  provider.terraform-provider-cloudflare_v3.9.1: configuring server automatic mTLS: timestamp=2022-02-17T08:07:02.779-0700
2022-02-17T08:07:02.786-0700 [DEBUG] provider: using plugin: version=5
2022-02-17T08:07:02.786-0700 [DEBUG] provider.terraform-provider-cloudflare_v3.9.1: plugin address: address=/var/folders/hj/sd6xmf7x62798sq7d6z6kp040000gn/T/plugin66265373 network=unix timestamp=2022-02-17T08:07:02.786-0700
2022-02-17T08:07:02.815-0700 [WARN]  ValidateProviderConfig from "provider["registry.terraform.io/cloudflare/cloudflare"]" changed the config value, but that value is unused
2022-02-17T08:07:02.815-0700 [INFO]  provider.terraform-provider-cloudflare_v3.9.1: 2022/02/17 08:07:02 [INFO] Cloudflare Client configured for user: brian.dandoy@paradox.ai: timestamp=2022-02-17T08:07:02.815-0700
2022-02-17T08:07:02.815-0700 [INFO]  provider.terraform-provider-cloudflare_v3.9.1: 2022/02/17 08:07:02 [INFO] Using specified account id 15e289746610ed2683be104607b16e09 in Cloudflare provider: timestamp=2022-02-17T08:07:02.815-0700
2022-02-17T08:07:02.815-0700 [INFO]  provider.terraform-provider-cloudflare_v3.9.1: 2022/02/17 08:07:02 [INFO] Cloudflare Client configured for user: brian.dandoy@paradox.ai: timestamp=2022-02-17T08:07:02.815-0700
2022-02-17T08:07:02.815-0700 [DEBUG] ReferenceTransformer: "cloudflare_custom_hostname.sans" references: []
cloudflare_custom_hostname.sans: Refreshing state... [id=8d659fea-4024-4fc1-be35-f0967f898785]
2022-02-17T08:07:02.817-0700 [INFO]  provider.terraform-provider-cloudflare_v3.9.1: 2022/02/17 08:07:02 [DEBUG] Cloudflare API Request Details:
---[ REQUEST ]---------------------------------------
GET /client/v4/zones/6a9006164edb31aca836cf6f4d0c6184/custom_hostnames/8d659fea-4024-4fc1-be35-f0967f898785 HTTP/1.1
Host: api.cloudflare.com
User-Agent: terraform/1.0.11 terraform-plugin-sdk/2.10.1 terraform-provider-cloudflare/3.9.1
Content-Type: application/json
Accept-Encoding: gzip
-----------------------------------------------------: timestamp=2022-02-17T08:07:02.817-0700
2022-02-17T08:07:03.194-0700 [INFO]  provider.terraform-provider-cloudflare_v3.9.1: 2022/02/17 08:07:03 [DEBUG] Cloudflare API Response Details:
---[ RESPONSE ]--------------------------------------
HTTP/2.0 200 OK
Cf-Cache-Status: DYNAMIC
Cf-Ray: 6defec512cde5331-LAX
Content-Type: application/json; charset=UTF-8
Date: Thu, 17 Feb 2022 15:07:03 GMT
Expect-Ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Server: cloudflare
Set-Cookie: __cflb=0H28vgHxwvgAQtjUGU4vq74ZFe3sNVUZVUf2Da2uDrm; SameSite=Lax; path=/; expires=Thu, 17-Feb-22 17:37:04 GMT; HttpOnly
Set-Cookie: __cfruid=2e220f03cd3eb6e0e8d6bb1b9573c66d196bc752-1645110423; path=/; domain=.api.cloudflare.com; HttpOnly; Secure; SameSite=None
Vary: Accept-Encoding
X-Envoy-Upstream-Service-Time: 19
{
"result": {
"id": "8d659fea-4024-4fc1-be35-f0967f898785",
"hostname": "custom.paradox.ai",
"ssl": {
"id": "a4acf290-8642-4a6c-815b-3f9b223dbbd1",
"type": "dv",
"method": "txt",
"status": "active",
"hosts": [
"custom.paradox.ai"
],
"settings": {
"http2": "on",
"tls_1_3": "on",
"min_tls_version": "1.2"
},
"bundle_method": "ubiquitous",
"certificates": [
{
"issuer": "CloudflareInc",
"serial_number": "9788114406410918930987082525256964946",
"signature": "ECDSAWithSHA256",
"expires_on": "2023-02-16T23:59:59Z",
"issued_on": "2022-02-17T00:00:00Z",
"fingerprint_sha256": "9e266b7aa193c479fd7df08dd3a847f9f4aac80611b9ece39b533f34b1fbaf20",
"id": "b5dbe62c-3bb8-494e-ac6d-1ba16a5ea240"
},
{
"issuer": "CloudflareInc",
"serial_number": "10785380436403442802533380960677006285",
"signature": "SHA256WithRSA",
"expires_on": "2023-02-16T23:59:59Z",
"issued_on": "2022-02-17T00:00:00Z",
"fingerprint_sha256": "374f9c90720bb8a51ca8ba71f9fc04f1dcc2ac6ec3c3112cde2498b8d9b97ffe",
"id": "d8212a89-e081-4b59-8fd4-41b568667011"
}
],
"wildcard": false,
"certificate_authority": "digicert"
},
"status": "active",
"created_at": "2022-02-17T14:54:45.659754Z"
},
"success": true,
"errors": [],
"messages": []
}
-----------------------------------------------------: timestamp=2022-02-17T08:07:03.194-0700
2022-02-17T08:07:03.198-0700 [WARN]  Provider "registry.terraform.io/cloudflare/cloudflare" produced an invalid plan for cloudflare_custom_hostname.sans, but we are tolerating it because it is using the legacy plugin SDK.
The following problems may be the cause of any confusing errors from downstream operations:
- .custom_origin_server: planned value cty.StringVal("") for a non-computed attribute
- .ssl[0].custom_certificate: planned value cty.StringVal("") for a non-computed attribute
- .ssl[0].custom_key: planned value cty.StringVal("") for a non-computed attribute
- .ssl[0].wildcard: planned value cty.False for a non-computed attribute
- .ssl[0].type: planned value cty.StringVal("dv") for a non-computed attribute
- .ssl[0].settings[0].ciphers: planned value cty.SetValEmpty(cty.String) for a non-computed attribute
- .ssl[0].settings[0].early_hints: planned value cty.StringVal("") for a non-computed attribute
2022-02-17T08:07:03.199-0700 [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"
2022-02-17T08:07:03.200-0700 [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.9.1/darwin_arm64/terraform-provider-cloudflare_v3.9.1 pid=17822
2022-02-17T08:07:03.200-0700 [DEBUG] provider: plugin exited
No changes. Your infrastructure matches the configuration.
Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.
2022-02-17T08:07:03.201-0700 [INFO]  backend/local: apply calling Apply
2022-02-17T08:07:03.201-0700 [INFO]  terraform: building graph: GraphTypeApply
2022-02-17T08:07:03.201-0700 [DEBUG] ProviderTransformer: "cloudflare_custom_hostname.sans (expand)" (*terraform.nodeExpandApplyableResource) needs provider["registry.terraform.io/cloudflare/cloudflare"]
2022-02-17T08:07:03.202-0700 [DEBUG] ReferenceTransformer: "cloudflare_custom_hostname.sans (expand)" references: []
2022-02-17T08:07:03.202-0700 [DEBUG] ReferenceTransformer: "provider["registry.terraform.io/cloudflare/cloudflare"]" references: []
2022-02-17T08:07:03.202-0700 [DEBUG] pruneUnusedNodes: cloudflare_custom_hostname.sans (expand) is no longer needed, removing
2022-02-17T08:07:03.202-0700 [DEBUG] pruneUnusedNodes: provider["registry.terraform.io/cloudflare/cloudflare"] is no longer needed, removing
2022-02-17T08:07:03.202-0700 [DEBUG] Starting graph walk: walkApply
Apply complete! Resources: 0 added, 0 changed, 0 destroyed.
Panic output
No response
Expected output
resource "cloudflare_custom_hostname" "sans" {
    hostname                    = "custom.paradox.ai"
    id                          = "8d659fea-4024-4fc1-be35-f0967f898785"
    ownership_verification      = {
        "name"  = "_cf-custom-hostname.custom.paradox.ai"
        "type"  = "txt"
        "value" = "e300d99b-4d8d-4857-ae35-ae643ad4e207"
    }
    ownership_verification_http = {
        "http_body" = "e300d99b-4d8d-4857-ae35-ae643ad4e207"
        "http_url"  = "http://custom.paradox.ai/.well-known/cf-custom-hostname-challenge/8d659fea-4024-4fc1-be35-f0967f898785"
    }
    zone_id                     = "6a9006164edb31aca836cf6f4d0c6184"
    ssl {
        certificate_authority = "digicert"
        method                = "txt"
        status                = "pending_validation"
        type                  = "dv"
        validation_errors     = []
        validation_records    = [
            {
                cname_name   = ""
                cname_target = ""
                emails       = []
                http_body    = ""
                http_url     = ""
                txt_name     = "custom.paradox.ai"
                txt_value    = "ca3-db23df47239e4fb2a077d1e386578cfa"
            },
        ]
        wildcard              = false
        settings {
            ciphers         = []
            http2           = "on"
            min_tls_version = "1.2"
            tls13           = "on"
        }
    }
}

Actual output
resource "cloudflare_custom_hostname" "sans" {
    hostname                    = "custom.paradox.ai"
    id                          = "8d659fea-4024-4fc1-be35-f0967f898785"
    ownership_verification      = {
        "name"  = ""
        "type"  = ""
        "value" = ""
    }
    ownership_verification_http = {
        "http_body" = ""
        "http_url"  = ""
    }
    zone_id                     = "6a9006164edb31aca836cf6f4d0c6184"

    ssl {
        certificate_authority = "digicert"
        method                = "txt"
        status                = "active"
        type                  = "dv"
        validation_errors     = []
        validation_records    = []
        wildcard              = false

        settings {
            ciphers         = []
            min_tls_version = "1.2"
        }
    }
}

Steps to reproduce

Create a custom hostname
Add the txt records to your DNS provider
Refresh your terraform state

Additional factoids
We want to use the output of these records to make the txt records in AWS Route53. It works initially but since after the information is verified it is removed from the terraform state future runs attempt to change the AWS Route53 records since the values no longer exist in state.
References
No response

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.
This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

@jacobbednarz I have updated this issue with a full debug output

Hi all, I am experiencing a similar issue.
Terraform v1.3.6
on windows_amd64
+ provider registry.terraform.io/cloudflare/cloudflare v3.32.0

I am creating a cloudflare_custom_hostname resource, and using the ssl block values to populate a cloudflare_record resource:
resource "cloudflare_custom_hostname" "domain" {
  zone_id  = var.zone_id
  hostname = var.hostname
  custom_origin_server = var.origin_server
  wait_for_ssl_pending_validation = true

  ssl {
    method = "txt"
    wildcard = true
  }
}

resource "cloudflare_record" "domain" {
  zone_id =  var.zone_id
  name    = cloudflare_custom_hostname.domain.ssl[0].validation_records[0].txt_name
  value   = cloudflare_custom_hostname.domain.ssl[0].validation_records[0].txt_value
  type    = "TXT"
}

This works as expected when creating new resources. However, subsequent runs of terraform plan/terraform apply receive an error:
│ Error: Invalid index
│
│   on domains.tf line 16, in resource "cloudflare_record" "domain":
│   16:   name    = cloudflare_custom_hostname.domain.ssl[0].validation_records[0].txt_name
│     ├────────────────
│     │ cloudflare_custom_hostname.domain.ssl[0].validation_records is empty list of object
│
│ The given key does not identify an element in this collection value: the collection has no elements.
╵
╷
│ Error: Invalid index
│
│   on domains.tf line 17, in resource "cloudflare_record" "domain":
│   17:   value   = cloudflare_custom_hostname.domain.ssl[0].validation_records[0].txt_value
│     ├────────────────
│     │ cloudflare_custom_hostname.domain.ssl[0].validation_records is empty list of object
│
│ The given key does not identify an element in this collection value: the collection has no elements.

However, when running terraform state show 'cloudflare_custom_hostname.domain' it gives the following, which does have the ssl block populated as expected:
# cloudflare_custom_hostname.domain:
resource "cloudflare_custom_hostname" "domain" {
    custom_origin_server            = "redacted"
    hostname                        = "redacted"
    id                              = "redacted"
    ownership_verification          = {
        "name"  = "_cf-custom-hostname.redacted"
        "type"  = "txt"
        "value" = "redacted"
    }
    ownership_verification_http     = {
        "http_body" = "redacted"
        "http_url"  = "http://redacted/.well-known/cf-custom-hostname-challenge/redacted"
    }
    wait_for_ssl_pending_validation = true
    zone_id                         = "redacted"

    ssl {
        certificate_authority = "digicert"
        method                = "txt"
        status                = "pending_validation"
        type                  = "dv"
        validation_errors     = []
        validation_records    = [
            {
                cname_name   = ""
                cname_target = ""
                emails       = []
                http_body    = ""
                http_url     = ""
                txt_name     = "redacted"
                txt_value    = "redacted"
            },
        ]
        wildcard              = true

        settings {
            ciphers = []
        }
    }
}

Should I raise this as a new issue, or is this related to the above?

As a workaround to https://github.com/cloudflare/terraform-provider-cloudflare/issues/1466#issuecomment-1380593608 I used a try around the value throwing the error, and used ignore_changes for subsequent runs of terraform plan/terraform apply.
resource "cloudflare_record" "domain" {
  zone_id = var.zone_id
  name    = try(cloudflare_custom_hostname.domain.ssl[0].validation_records[0].txt_name, "")
  value   = try(cloudflare_custom_hostname.domain.ssl[0].validation_records[0].txt_value, "")
  type    = "TXT"

  lifecycle {
    ignore_changes = [
      name, value
    ]
  }
}

authors: bdandoy irmbrady jacobbednarz


text:
🐛 BUG: ✘ [ERROR] A request to the Cloudflare API ... failed.

Which Cloudflare product(s) does this pertain to?
Workers for Platforms, Workers Runtime, Wrangler core
What version(s) of the tool(s) are you using?
Wrangler 3.10.1, Wrangler Action 3.2
What version of Node are you using?
20.8.0
What operating system are you using?
Linux Ubuntu 22.04.3
Describe the Bug
Hi,
Wrangler Action was working 2 days ago, but now it shows error [ERROR] ParseError: A request to the Cloudflare API (/accounts/iiiiiiiiiiiiiiiiiiiidddddddddddd/workers/services/wordpress-plugins) failed., how can I fix it?
Please provide a link to a minimal reproduction
repository private
Please provide any relevant error logs
🚀 Running Wrangler Commands
  🚀 Executing command: npx wrangler deploy
   ⛅ wrangler 3.10.1
  -------------------
  Total Upload: 0.23 KiB / gzip: 0.18 KiB

  ✘ [ERROR] A request to the Cloudflare API (/accounts/iiiiiiiiiiiiiiiiiiiidddddddddddd/workers/scripts/wordpress-plugins) failed.

    Authentication error [code: 10000]

    If you think this is a bug, please open an issue at: https://github.com/cloudflare/workers-sdk/issues/new/choose

  Error: ✘ [ERROR] ParseError: A request to the Cloudflare API (/accounts/iiiiiiiiiiiiiiiiiiiidddddddddddd/workers/services/wordpress-plugins) failed.

        at throwFetchError (/home/runner/work/wordpress-plugins/wordpress-plugins/node_modules/wrangler/wrangler-dist/cli.js:121072:17)
        at fetchResult (/home/runner/work/wordpress-plugins/wordpress-plugins/node_modules/wrangler/wrangler-dist/cli.js:121024:5)
        at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
        at async deploy (/home/runner/work/wordpress-plugins/wordpress-plugins/node_modules/wrangler/wrangler-dist/cli.js:149579:31)
        at async Object.deployHandler [as handler] (/home/runner/work/wordpress-plugins/wordpress-plugins/node_modules/wrangler/wrangler-dist/cli.js:138908:3) {
      text: 'A request to the Cloudflare API (/accounts/iiiiiiiiiiiiiiiiiiiidddddddddddd/workers/services/wordpress-plugins) failed.',
      notes: [ { text: 'Authentication error [code: 10000]' } ],
      location: undefined,
      kind: 'error',
      code: 10000
    }

Error: `npx wrangler deploy` returned non-zero exit code.
Error: 🚨 Action failed
------------------------------------------------------------------------------------------
wrangler-action.yml
-------------------------------
name: Wrangler Action

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    name: Deploy
    steps:
      - uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 20

      - name: Deploy
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: "aaaaaaaaaapppppppppiiiiiiiii"
          accountId: "iiiiiiiiiiiiiiiiiiiidddddddddddd"
          wranglerVersion: "3.10.1"
          packageManager: "npm"

Hello 👋 This looks like an authentication error with the wrangler GitHub action. Did you set everything up per the instructions at https://github.com/cloudflare/wrangler-action?

Yes, it was working previously, now with version 3.2 it does not work, even when I go back to the old versions

@mmhdi I think it's an auth error, not a Wrangler/Action issue. Can you try setting a new API token per the instructions here: https://github.com/cloudflare/wrangler-action#authentication ?

authors: admah mmhdi

repo: cloudflare/workers-sdk


text:
🐛 BUG: Secrets don't seem to exist with wrangler dev?

What version of Wrangler are you using?
2.0.7
What operating system are you using?
Mac
Describe the Bug
Honestly, I'm not sure if this is a bug or a user error... Maybe I'm doing something wrong here, but for the life of me I cannot figure out how to correctly handle secrets. I'm wondering if maybe there is a bug?
When I run: wrangler secret list -e staging I see the secrets in question listed.
Dev command: wrangler dev -e staging
I have a test secret named MATT
The index file looks like this:
import type { Env } from './types';

const worker = {
  /**
   *
   * @param request
   * @param env
   * @param ctx
   */
  async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
    console.log(env);
    console.log(env.MATT);
    return new Response("HELLO");
  },
};

export default worker;

When I run wrangler dev -e staging env.MATT is always undefined. Even though it is showing up w/ wrangler secret list -e staging
Does anyone have any recommendations on how to best manage secrets during local development?

I wonder if this is the same as https://github.com/cloudflare/wrangler2/issues/1003?
Are you using routes in your wrangler.toml?

Hi @petebacondarwin ,
It might be? I am using routes but I've tried the workaround described in #1003 and still can't see any secrets. I could totally be doing the workaround incorrectly though... Maybe I'll hold off until #1003 and try again.

authors: mwisner petebacondarwin


text:
Convention for libraries to provide "workers" compatible bundle.

An issue that I regularly run up against when using Cloudflare Workers is that a library that I want to use provides both "node" and "browser" compatible bundles but neither of them work in the Cloudflare Workers environment because the bundles rely on node apis or DOM apis that are not available in Workers.
I think it would be great to establish some kind of convention that library authors can use to provide a third bundle that specifically lists itself as compatible with a "workers" style environment. While there would certainly be an advantage to marking a package specifically as "Cloudflare Workers" compatible, I think it would be cool if we could extend this to any DOM-less javascript environment like "service workers" or traditional "workers" in the browser. I'm not sure that makes sense but I figured would list it here as a possible area of exploration.
A great example of this issue can be found with the @emotion family of packages on NPM. Their package.json files look something like:
{
  "name": "@emotion/react",
  "version": "11.7.0",
  "main": "dist/emotion-react.cjs.js",
  "module": "dist/emotion-react.esm.js",
  "browser": {
    "./dist/emotion-react.cjs.js": "./dist/emotion-react.browser.cjs.js",
    "./dist/emotion-react.esm.js": "./dist/emotion-react.browser.esm.js"
  },
}

They are obviously trying to be good citizens by providing both node and browser compatible bundles (in both cjs and 'mjs` formats) but neither of those are compatible with workers because the node version uses node apis like "stream" that do not work in workers and the browser bundle uses some DOM apis. Here is a minimal reproduction repo of this issue with wrangler2 and emotion: https://github.com/nicksrandall/emotion-workers-example/tree/main

NOTE: This issue is a result of this twitter conversation: https://twitter.com/NickSRandall/status/1468991859267497988

Here is some related discussion in emotion package: https://github.com/emotion-js/emotion/issues/2554
Here is some related discussion in precontruct package: https://github.com/preconstruct/preconstruct/issues/431
Context: Emotion uses preconstruct to generate bundles so a fix to emotion would require a fix to preconstruct.

I think that the answer, for the most part, is to make use of package.json#exports.worker but yes - I believe this should be clearly stated somewhere here. For instance, at the moment this condition is not utilized by Cloudflare's Rollup starter - I've prepared a fix for this here: https://github.com/cloudflare/durable-objects-rollup-esm/pull/14 . IIRC the webpack starter take this fully into account but the Cloudlfare docs suggest that it does - or smth like that, I would have to refresh my memory on this part to be sure.

We could very easily use an exports field, and it'll be easier in wrangler2 assuming folks outsource module resolution etc to us. Just want to be certain what field we settle on. 'worker' usually implies a web worker, but of course we're not fully that either. anyway, I'll put a PR for this early next week.

@threepointone is this part of the docs up to date? is wrangler2 supporting webpack anyhow - I've glimpsed to the code and it seems that the dev and production builds are done using esbuild, right?
Either way - I've checked the esbuild's code and docs and luckily it already supports conditions: https://esbuild.github.io/api/#conditions
Note that you could also make use of browser, worker, production and development conditions. Since this is what other bundlers (like webpack) might do with target: 'webworker'

We could very easily use an exports field, and it'll be easier in wrangler2 assuming folks outsource module resolution etc to us.

If they don't - well, it's up to them to configure stuff on their own. I would only make sure that your existing boilerplates are configured in the same way as wrangler2 is (when it comes to this resolution stuff).

Just want to be certain what field we settle on. 'worker' usually implies a web worker, but of course we're not fully that either.

That is true - I wonder though, is there any notable difference for people? From what I understand you are taking the high road and you are staying away from implementing any custom APIs etc and you are all about web standards. Is there anything that webworkers can do that is not supported on Cloudflare (and vice-versa)? I'm just a little bit worried about introducing too many conditions to the world - this stuff is not that easy to handle for package authors as JS can run in so many environments.

None of the docs reflect wrangler2 just yet. Maybe webworker should be enough. We're close enough to it that it shouldn't matter (except when it actually does, haha).

Maybe webworker should be enough.

Just a word of caution - IIRC the condition is 'worker' while the target in webpack is 'webworker'.

it shouldn't matter (except when it actually does, haha).

Put that on my tombstone.

ugggh. we have separate work underway to eject the webpack stuff from wrangler 1 projects. I'll make sure to limit the splash there.

FWIW, esbuild supports custom package exports conditions so you could support this today by adding conditions: ['worker'] to wrangler's esbuild config.
IIRC, the list is in order of preference so you could add something even more specific to the front of the list that could fix a conflict between worker (ie webworker) and Cloudflare workers.
Maybe something like this?:
{
  conditions: ['cloudflare-worker', 'worker', 'browser', 'module', 'default']
}

See: https://esbuild.github.io/api/#conditions

webworker is different enough from cloudflare workers that we shouldn't overload it -- we have several differences from the service-worker API, and module workers aren't service workers at all!

Is there anything that webworkers can do that is not supported on Cloudflare

A big one is threads, so tooling that assumes the "webworker" target allows their use tends to break. The vast majority of things don't do this, but IIRC emscripten surprised me by generating something that tried to use them when you enabled it's webworker target.

@xortive I understand (and agree) that web-worker compatibility does not guarantee cloudflare worker compatibility. If a library wanted to explicitly support cloudflare workers then it would make sense to use the explicit conditional, whatever we decide that to be. That said, if that explicit conditional is not present but a "worker" conditional is, I think it is highly likely that we would want to use that since it is the closest environment to cloudflare.
I guess what I'm saying is that I think we could make a strong case to support both, in order of preference.

@threepointone I'm happy to submit PRs for the esbuild stuff if you think that this is worth pursuing.

That said, if that explicit conditional is not present but a "worker" conditional is, I think it is highly likely that we would want to use that since it is the closest environment to cloudflare.

I agree on that one. If a more specific condition has to be introduced in the future (or even now) - it can be done. But "worker" should be used as a fallback, and even maybe a "browser" (with lower priority than "worker", ofc). At least this is how it works in webpack for target: 'webworker' and this has been "promoted" in the Cloudflare docs for Wrangle v1. So at least nothing would be that surprising about this - unless you think that this is an entirely bad idea.

I'm going to mark this issue as closed. Of course libraries will have to provide bundles with worker exports, and we'll have to eventually come up with something specific for cloudflare, but I'm grateful for @nicksrandall and @Andarist for the PR we just landed in #93. Thanks thanks thanks!

authors: Andarist nicksrandall threepointone xortive


text:
Pages Functions Compiler

This PR open-sources our functions compiler which compiles a folder of functions into a single Worker script (previously this was done with the @cloudflare/pages-functions-compiler package).
It also adds support for sourcemaps (as requested in #138) and automatically watches all dependents (fixes #49).
Still to follow in a subsequent PR is a command which performs just this compile step once (which will be used by production builds). I'm thinking of having two modes:

wrangler functions compile which builds functions will a fallback of fetch
wrangler functions compile --service=SOME_SERVICE which builds functions with a fallback of env.SOME_SERVICE.fetch.

So Pages things would use wrangler functions compile --service=ASSETS.
This small piece of extra work would allow any user to use functions folder syntax to generate a Worker ✨

I'll review in a bit, but can start by saying this should probably be under pages, i.e- wrangler pages functions ...

To clarify, I haven't added any new commands yet. This PR is entirely built into wrangler pages dev. I was just talking about additionally exposing it in a different command in the future. I'm relatively indifferent to that being wrangler pages functions ... vs. wrangler functions .... Only thing I would say is that if people are using it outwith a Pages project, it's maybe a bit unexpected to use wrangler pages.

authors: GregBrimble threepointone


text:
KotlinVersion is not being taken correctly to the classpath

If you override the kotlin version like this:
autoConfigure {
    kotlin {
        kotlinVersion.set("1.6.21")
    }
}

Then you still have the latest kotlin version on the classpath.
If you run the tracker report you see the following:
    "compile": [
        {
            "artifact": "org.jetbrains.kotlin:kotlin-bom:1.6.21",
            "classifier": null,
            "type": "bom",
            "trail": [
            ]
        },
        {
            "artifact": "org.jetbrains.kotlin:kotlin-stdlib:1.7.10",
            "classifier": null,
            "type": "jar",
            "trail": [
                "org.jetbrains.kotlin:kotlin-bom:1.6.21",
                "org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10"
            ]
        },
        {
            "artifact": "org.jetbrains.kotlin:kotlin-stdlib-common:1.7.10",
            "classifier": null,
            "type": "jar",
            "trail": [
                "org.jetbrains.kotlin:kotlin-bom:1.6.21",
                "org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10",
                "org.jetbrains.kotlin:kotlin-stdlib:1.7.10"
            ]
        },
        {
            "artifact": "org.jetbrains:annotations:13.0",
            "classifier": null,
            "type": "jar",
            "trail": [
                "org.jetbrains.kotlin:kotlin-bom:1.6.21",
                "org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10",
                "org.jetbrains.kotlin:kotlin-stdlib:1.7.10"
            ]
        },
        {
            "artifact": "org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.7.10",
            "classifier": null,
            "type": "jar",
            "trail": [
                "org.jetbrains.kotlin:kotlin-bom:1.6.21",
                "org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10"
            ]
        },
        {
            "artifact": "org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10",
            "classifier": null,
            "type": "jar",
            "trail": [
            ]
        }
    ]

That means, we are applying org.jetbrains.kotlin:kotlin-bom with the correct version, but someone (probably the Kotlin plugin) is also adding org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.7.10, and that is overriding the version.
The problem seem to be in the KotlinConfigurePlugin in that block:
        kotlin.sourceSets.maybeCreate("main").dependencies {
            // see https://kotlinlang.org/docs/gradle.html#dependency-on-the-standard-library
            // as we allow clients to override the Kotlin Version, (i.e. to 1.5.20), we also want to ensure
            // that all kotlin standard libraries from exactly that Kotlin version is being added
            // to the dependencies. That's why we add the kotlin-bom in exactly our version here.
            // Without those lines, we would always add the stdlib in the version
            // of the underlying Kotlin Gradle Plugin (1.7.10 at the time of that writing)
            this.implementation(kotlinConfigureExtension.kotlinVersion
                .map { project.dependencies.platform("org.jetbrains.kotlin:kotlin-bom:$it") }
            )
            this.implementation(kotlinConfigureExtension.kotlinVersion
                .map { "org.jetbrains.kotlin:kotlin-stdlib-jdk8" }
            )

It seems that the correct kotlinVersion is not being taken here

it seems that this has to to with the autoConfigure plugin, because there is a KotlinConfigurePluginTest with a single-kotlin-module-override-kotlinversion fixture and that only applies the io.cloudflight.autoconfigure.kotlin-configure plugin:
kotlinConfigure {
    kotlinVersion = "1.5.20"
}

Probably the AutoConfigureExtension erronously overrides that.

released in version 0.7.0


text:
docs(stroybook-refactoring): refactor p-badge & p-collapsible-list

To Reviewers

[ ] Skipping review is not a problem (style, chore ONLY)
[ ] Not that difficult

Type of Change

[ ] New feature
[ ] Bug fixes
[x] Feature improvement

[ ] These changes require a usage change

[x] Others (performance improvement, refactoring, CI/CD, etc.)

Checklist

[x] Updated Storybook documents
[x] Tested with console

Description

storybook refactoring
change p-badge component to single-file-component
change p-collapsible-list two way binding hook

Things to Talk About

:tada: This PR is included in version 1.1.0-beta.393 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

authors: admin-cloudforet piggggggggy

repo: cloudforet-io/mirinae


text:
Errand broker-registrar fails because it can't access system domain API endpoint (connect timeout)

Below is the output from the errand log. Should I setup something to enable access from the kafka-service-broker VM to the system domain API endpoint? I can access the system API endpoint from other deployments but from this particular one it appears to be blocked.
Thanks.
ubuntu@ops-manager-vm:~/kafka-service-broker-boshrelease$ bosh run-errand broker-registrar
Using environment '10.0.0.10' as client 'ops_manager'
Using deployment 'kafka-service-broker'
Task 386
Task 386 | 18:29:31 | Preparing deployment: Preparing deployment
Task 386 | 18:29:32 | Warning: Ambiguous request: the requested errand name 'broker-registrar' matches both a job name and an errand instance group name. Executing errand on all relevant instances with job 'broker
-registrar'.
Task 386 | 18:29:33 | Preparing package compilation: Finding packages to compile (00:00:00)
Task 386 | 18:29:33 | Preparing deployment: Preparing deployment (00:00:02)
Task 386 | 18:29:33 | Creating missing vms: broker-registrar/afa3b5a8-6374-4144-945f-ecd2e5e9eb8b (0) (00:01:16)
Task 386 | 18:30:49 | Updating instance broker-registrar: broker-registrar/afa3b5a8-6374-4144-945f-ecd2e5e9eb8b (0) (00:00:13)
Task 386 | 18:31:02 | Running errand: broker-registrar/afa3b5a8-6374-4144-945f-ecd2e5e9eb8b (0) (00:00:15)
Task 386 | 18:31:17 | Fetching logs for broker-registrar/afa3b5a8-6374-4144-945f-ecd2e5e9eb8b (0): Finding and packing log files (00:00:01)
Task 386 Started  Sun May 26 18:29:31 UTC 2019
Task 386 Finished Sun May 26 18:31:18 UTC 2019
Task 386 Duration 00:01:47
Task 386 done
Instance   broker-registrar/afa3b5a8-6374-4144-945f-ecd2e5e9eb8b
Exit Code  1
Stdout     CF_API_URL=https://api.sys.pcf.pvtl.dev
           CF_SKIP_SSL_VALIDATION=false
           CF_ADMIN_USERNAME=admin
           BROKER_NAME=starkandwayne-kafka
           BROKER_URL=http://10.0.8.18:8080
           BROKER_USERNAME=broker
           Setting api endpoint to https://api.sys.pcf.pvtl.dev...
           Request error: Get https://api.sys.pcf.pvtl.dev/v2/info: dial tcp 35.244.254.11:443: i/o timeout
           TIP: If you are behind a firewall and require an HTTP proxy, verify the https_proxy environment variable is correctly set. Else, check your network connection.
           FAILED

Stderr     -
1 errand(s)
Errand 'broker-registrar' completed with error (exit code 1)
Exit code 1

Yeah that’s strange. I wonder why your errand VM cannot reach the 35.x.y.z IP.

authors: drnic odedia


text:
Unable to use database prefix when submitted with credentials

With prefixes, dbclient successfully resolves the database urls when we do not have any authentication information in the url. However, if we have authentication information in the url,  the password is considered as a placeholder and is replaced with undefined.
export COUCHDB=https://username:password@username.cloudant.com/prefix-:name
# results in
abacus-dbclient 789 Using db https://usernameundefined@username.cloudant.com/prefix-abacus-collector-collected-usage-0-201510 in write mode

Fixed in f5c7afb.

authors: jsdelfino rajkiranrbala

repo: cloudfoundry-incubator/cf-abacus


text:
ERR Error: invalid schema, expected mongodb

Getting this error while using mongodb on CF.
ERR Error: invalid schema, expected mongodb

Usually this is caused by wrong URL in one of the env.variables for DB configuration, described here: https://github.com/cloudfoundry-incubator/cf-abacus/blob/master/doc/conf.md#database
Please check if your

DB is a valid mongo URL, such as mongodb://user:password@10.11.21.248:27017,10.11.21.249:27017,10.11.21.250:27017/dbname?replicaSet=replicaSetName
DBCLIENT is set to abacus-mongoclient

I have followed the steps here. Removed the DB variable as given here. And created the service instance of mongodb and binded it to every application of abacus.
https://github.com/cloudfoundry-incubator/cf-abacus/blob/master/doc/conf.md#cloud-foundry-configuration

Can you please run cf env on one of the abacus applications and post the sanitized VCAP_SERVICES section?

Yes I checked it. It's having the mongo credentials in VCAP_SERVICES.

The service instance bound to the apps should be called 'db' as the env. variable in the manifest.yml

My instance name was not 'db' before. Changed it to db now. It's working fine now. Thanks.
But service instance name should be customizable rignt?

In general it should be customizable. We use a naming convention for the service instance name to enable adding more db storage (mongo dbclient only) in production.
Potentially there will be a problem if you need to bind another service with name db to Abacus apps. Since we do not require or support more DBs I regard this as improbable scenario and will close the issue.
In case you need to have more services bound to Abacus apps with the name db please reopen it.

Error!Error: Invalid schema, expected mongodb or mongodb+srv

@mrsinghda Can you share if this happens locally on your computer or on CF? What version of abacus are you using?

authors: cfmagnum hsiliev mrsinghda


text:
Add dependencies to vendor directory

fixes #14

@apoydence I am not sure we want to vendor dropsonde. Since dropsonde acts on the package level for most things, when a consumer calls dropsonde.Initialize() it isn't initializing the same package.

@bradylove I've updated the commit to remove dropsonde from the vendors.

authors: apoydence bradylove

repo: cloudfoundry-incubator/go-loggregator


text:
CI: Remove Bazel usage from the pipeline and port sample-values test to bash build system

Description

Substitute Bazel with Bash build system for lint & build jobs in the pipeline.
Use splatform/catapult container image instead of thulioassis/bazel-docker-image in those jobs.
Port functionality of bazel test //deploy/helm/kubecf:values_doc_test into make kubecf-build.
Only print errors when testing the sample values.yaml, to leave make kubecf-build output unchanged.

Motivation and Context

Part of https://github.com/cloudfoundry-incubator/kubecf/issues/1010.
How Has This Been Tested?

Testing in https://concourse.suse.dev/teams/main/pipelines/kubecf-rmbazel
lint, build, publish should be green in master (maybe publish will fail because the tar is already there). The pr tab is used for updating this PR's github statuses.
Manual tests for the change in testing sample values doc tests have been performed:

Bazel:

true positive by running bazel test //deploy/helm/kubecf:values_doc_test
true negative by running bazel test //deploy/helm/kubecf:values_doc_test and
removing comment for system_domain in deploy/helm/kubecf/values.yaml

Bash build scripts:

true positive by running make kubecf-build
true negative by running make kubecf-build and removing comment for
system_domain in deploy/helm/kubecf/values.yaml

Screenshots (if appropriate):
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] My code has security implications.
[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.

Testing blocked by  #1095, hence, opened as draft.

Can be tested by approving, and then pinning this PR in https://concourse.suse.dev/teams/main/pipelines/kubecf-rmbazel?group=pr. This will update the github statuses here.

The bash build system downloads on its own shellcheck, yamllint, bosh, instead of using any of those binaries from the CI catapult image: https://concourse.suse.dev/teams/main/pipelines/kubecf-rmbazel/jobs/lint-viccuad-rm-bazel-ci/builds/5
We should fix that to speed up ci runs, or to not fail on GH blocking us after several downloads. But it doesn't need to block this card.

The bash build system downloads on its own shellcheck, yamllint, bosh, instead of using any of those binaries from the CI catapult image

It should only do this when you have set PINNED_TOOLS=1 before you invoke the linters. If you don't set this, then the build scripts will check if the installed version satisfies the minimum version requirements, and if satisfied, will use whatever you have in the PATH. I assume catapult is setting this, as I don't see any code in your PR doit it.
PINNED_TOOLS=1 exists to match the Bazel behaviour of always downloading a specific version of the tools (which only worked when all dependencies were specified correctly, otherwise Bazel was also pulling things from PATH).

Tackled the review commits, flown the pipeline again, https://concourse.suse.dev/teams/main/pipelines/kubecf-rmbazel/jobs/lint-viccuad-rm-bazel-ci/builds/11 onwards.

sigh, the make lint call fails, I don't see why: https://concourse.suse.dev/teams/main/pipelines/kubecf-rmbazel/jobs/lint-viccuad-rm-bazel-ci/builds/17
But I need to leave, I will leave this undone, sorry.

Thanks for the review!
Fixed make arguments, removed left-over repository key on *catapult-image yaml pointer, added shellcheck and yamllint to catapult image, and bumped the image's tag being pinned in this pipeline.

authors: jandubois viccuad

repo: cloudfoundry-incubator/kubecf


text:
Deployment Fails with BOSH CLIv1 and Director version 259.0.0

Hi,
I am trying to install kubo using BOSH CLIv1 with a preinstalled Director version 259.0.0. I've prepared a deployment manifest compatible with the version.
However when I do bosh deploy it fails giving below error:
Deprecation: Ignoring cloud config. Manifest contains 'networks' section.
Started preparing deployment > Preparing deployment. Failed: 419: unexpected token at '"etcd.' (00:00:00)
Error 100: 419: unexpected token at '"etcd.'
are the kubo releases not compatible with older versions of BOSH or something I am missing?

Hi @nitinpadalia,
We do not support bosh-cli v1. All of the scripts assume that we're using cli v2.
In addition to that, BOSH 259 is also not supported, as we use some features (like credhub integration).  The minimum required version of BOSH is 262.

authors: akshaymankar nitinpadalia

repo: cloudfoundry-incubator/kubo-deployment