text:
Network issue

Udeler | Udemy Course Downloader
1.12.7
Account Type?
Business
Steps to reproduce
when using a portal based token the issue is caused.
✔ Expected Behavior
network error
🔍 Additional context
8/29/2023, 3:11:36 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 3:11:35 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:55:12 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:59 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:58 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:58 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:58 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:58 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:58 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:58 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:58 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:58 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:58 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:58 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:58 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:58 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:58 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:58 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:57 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:57 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:57 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:57 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:57 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:57 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:57 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:57 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:57 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:57 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:57 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:57 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:57 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:57 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:57 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:57 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:56 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:56 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:56 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:56 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:56 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:56 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:56 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:56 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:56 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:56 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:56 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:56 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:56 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:56 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:56 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:55 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:55 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:55 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:55 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:55 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:55 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:55 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:55 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:55 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:55 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:55 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:55 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:55 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:55 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:55 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:54 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:54 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:54 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:54 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:54 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:54 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:54 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:54 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:54 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:54 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:54 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:54 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:54 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:54 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:54 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:53 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:53 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:53 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:53 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:53 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:53 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:53 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:53 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:53 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:53 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:53 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:53 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:53 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:53 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:53 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:52 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:52 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:52 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:52 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:52 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:52 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:52 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:52 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:52 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:52 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:52 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:52 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:52 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:52 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:52 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:51 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:51 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:51 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:51 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:51 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:51 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:51 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:51 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:51 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:51 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:51 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:51 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:51 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:51 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:51 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:50 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:50 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:50 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:50 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:50 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:50 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:50 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:50 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:50 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:50 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:50 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:50 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:50 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:50 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:50 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:50 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:49 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:49 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:49 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:49 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:49 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:49 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:49 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:49 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:49 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:49 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:49 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:49 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:49 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:49 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:49 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:48 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:48 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:48 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:48 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:48 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:48 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:48 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:48 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:48 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:48 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:48 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:48 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:48 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:48 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:48 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:47 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:47 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:47 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:47 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:47 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:47 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:47 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:47 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:47 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:47 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:47 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:47 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:47 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:47 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:47 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:46 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:46 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:46 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:46 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:46 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:46 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:46 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:46 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:46 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:46 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:46 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:46 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:46 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:46 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:45 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:45 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:45 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:45 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:45 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:45 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:45 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:45 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:45 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:45 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:45 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:45 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:45 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:45 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:45 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:44 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:44 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:44 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:44 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:44 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:44 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:44 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:44 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:44 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:44 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:44 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:44 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:44 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:44 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:43 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:43 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:43 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:43 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:43 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:43 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:43 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:43 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:43 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:43 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:43 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:43 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:43 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:42 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:42 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:42 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:42 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:41 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:41 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:41 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:39 PM - search_Error: ERR_NETWORK(0): Network Error
8/29/2023, 2:54:10 PM - search_Error: ERR_NETWORK(0): Network Error

Were you able to connect, did you enter the subdomain of your business account?

Were you able to connect, did you enter the subdomain of your business account?

I'm trying to but getting an empty white screen

Were you able to connect, did you enter the subdomain of your business account?

I'm trying to but getting an empty white screen and it doesn't allows me to paste the access token into the input

Wow, it doesn't even show the login screen when you start the application?

Were you able to connect, did you enter the subdomain of your business account?

I'm trying to but getting an empty white screen and it doesn't allows me to paste the access token into the input

Wow, it doesn't even show the login screen when you start the application?

Found why, after debugging it awhile, it was that I had been logged in, when started the application in dev mode , it started to work.
But I'm unable to use this application due to RDP rulles. IDK how to surpass them.

I believe it is resolved in the latest version

authors: HackPoint heliomarpm samascience

repo: heliomarpm/udemy-downloader-gui


text:
[Addition]: Mysterious Candy Sealion

Hotspot b58 Addresses
112NeZwGBeGBKsScsZhGTsEiTiCDW6iGXQ9tse453Aci6t15fioE
Discord Handle
JM17#0801
Reason(s)
Witness with hotspots at 30/37km while it is physicaly impossible to be in line of sight. So Mysterious Candy Sealion location is false one.

Not enough data to go on. At the moment.

source: gharchive/issue

repo: helium/denylist

license_type: permissive

license_source: github-api


text:
it itches

down there, to be exact
help

nvm fixed

license: MIT


text:
trying to fix the marshall error

What does this PR do?
trying to fix the marshall error

wtf

:shipit:

source: gharchive/pull-request

authors: italolelis kieranajp

repo: hellofresh/janus

license: mit

license_source: bigquery


text:
[stable/elasticsearch]: Can I get this chart to work with elasticsearch version 5.5.3?

Is this a request for help?:
Yes
Is this a BUG REPORT or FEATURE REQUEST? (choose one):
Neither.  It's a request for information.

Version of Helm and Kubernetes:
Helm Client only version 2.10.0
Kubernetes 1.9.7-gke.6
Which chart:
stable/elasticsearch
What happened:
I've been trying to get Elasticsearch running on K8s using this newly-promoted-to-stable helm chart, which works fine, BTW, for elasticsearch v 6.4.2. However, we're tied to a grails app that requires elasticsearch v 5.5.3, which we don't have the ability to upgrade. I've downgraded the elasticsearch image version in the chart to 5.5.3 (and also tried v 5.6.12) but it fails to start.
Client pods fail with inability to connect to elasticsearch-discovery headless service.
master-0 (the only master that attempts to start) fails with:
1) Error injecting constructor, ElasticsearchException[java.io.IOException: failed to read [id:15, legacy:false, file:/usr/share/elasticsearch/data/nodes/0/_state/global-15.st]]; nested: IOException[failed to read [id:15, legacy:false, file:/usr/share/elasticsearch/data/nodes/0/_state/global-15.st]]; nested: ElasticsearchException[Unknown license version found, please upgrade all nodes to the latest elasticsearch-license plugin];
  at org.elasticsearch.gateway.GatewayMetaState.<init>(Unknown Source)
  while locating org.elasticsearch.gateway.GatewayMetaState
    for parameter 4 at org.elasticsearch.gateway.GatewayService.<init>(Unknown Source)
  while locating org.elasticsearch.gateway.GatewayService
Caused by: ElasticsearchException[java.io.IOException: failed to read [id:15, legacy:false, file:/usr/share/elasticsearch/data/nodes/0/_state/global-15.st]]; nested: IOException[failed to read [id:15, legacy:false, file:/usr/share/elasticsearch/data/nodes/0/_state/global-15.st]]; nested: ElasticsearchException[Unknown license version found, please upgrade all nodes to the latest elasticsearch-license plugin];

My question is, is there a way to make this chart work with v 5.5.3 and, if so, can someone outline the necessary steps?
Many thanks!
What you expected to happen:
This is not unexpected.
How to reproduce it (as minimally and precisely as possible):

helm template <this-char> ... with all defaults.
Change all elasticsearch image versions from 6.4.2 to 5.5.3 (note I used the std elasticsearch docker image: docker.elastic.co/elasticsearch/elasticsearch:6.4.2)
kubectl apply --recursive -f elasticsearch/templates/

Anything else we need to know:
Any help is greatly appreciated and I know it's a long shot. Thanks!

Any news on this one?

We ended up using a variation of the "multi-node" solution found in this Medium post -- no SSD and disabled boot checking.
This is not the high availability provided by this chart but we needed to keep an old app running for a while longer before we can upgrade ES.  I do not support this solution any farther than just getting you by.  Clearly, the way forward for HA ES is to use this chart or the ES Operator.
I will close this issue.

authors: RuriRyan graziergeek

repo: helm/charts


text:
Feature/daemonset

What this PR does / why we need it:
Which issue this PR fixes
Support for DaemonSet in Traefik (see #9797)
Special notes for your reviewer:
hostNetwork:
enabled: true
deployType: "DaemonSet"
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[X] DCO signed
[X] Chart Version bumped
[X] Variables are documented in the README.md

Thanks for that, there is a very minor issue with this but it got me, in the Readme it is hostNetwork.enable while in the config hostNetwork.enable*d* is used

LGTM!

When can we expect this to be reviewed and merged? :-)

It's a shame that this isn't merged yet.

Activity!

It's a bit annoying how the bot marks it stale when it's waiting on Helm devs themselves rather than the community.

@sylvainblot @nmengin 🔢
just a notification reminder,
expected this feature 2 years ago

Hello everyone,  Should we make assign this PR to the chart owners? Please fix the conflicting, I'd like to help on this, thanks.

Any reviewers able to allocate time on this issue? (Or reject PR if this is out of scope for the chart)
cc'ing all reviewers from https://github.com/helm/charts/blob/master/stable/traefik/OWNERS
@emilevauge
@dtomcej
@timoreimann
@vdemeester
@nmengin
@mmatur
@ldez
@Juliens
@jbdoumenjou
@geraldcroes
@SantoDE
@errm

Hello All,
Despite not posting on this PR, we have been discussing this question a lot within the Traefik team.
I will share some of our conclusions here.
Traefik version 1 is in maintenance mode, and the v2 release will be imminent. This is why work on the v1 helm chart has been minimal since the spring, as most people will want to upgrade to v2 once it is GA. For this reason, we are hesitant to make any large changes to this chart.
Traefik v2 will not support LetsEncrypt in multi-node mode, so the option of a daemonset will not work if users want to use LE. For this reason, it makes more sense to use a deployment with anti-affinity to push pods to all nodes instead of using a daemonset.
Due to issues with root users, privileged ports, etc, it is unlikely that we will want to use host networking, or host ports on a public and production-recommended chart.
It is more likely that the v2 chart will move in the opposite direction, and move entirely to non-root, and non-privileged ports, with the option to override if your environment supports them.
Another reason against a daemonset is that many users don't require the same number of Traefik pods as they have nodes to handle traffic. Usually a few will suffice. If not, then the resource limits should be tweaked, or run a few more replicas. With people running on public clouds, resources = $$$. We should be aiming to be efficient, and scale up when needed, not down.
Finally, the examples in the Traefik v2 documentation etc will be deployment only (for the reasons above). It would make sense to keep the configuration similar to assist users with their needs. We haven't come across a compelling reason to add a daemonset requirement for v2, so until that time, we will proceed with deployment only.
I hope this gives some clarity into this issue, and how we view it moving forward.
Thanks,
The Traefik Team.

@dtomcej Thanks for the clear follow-up.
Waiting for Traefik v2 seems like the better option, and using anit-affinity should work quite well.
The only issue I see is that you might end up with 2 traefik pods on a node if you use a deployment and the number of replicas are same as number of nodes. There is an option that will be implemented in kubernetes 1.15 that will solve this (https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-even-pods-spreading.md)
Since you are deprecating multi-node setup with LetsEncrypt. I'm guessing the replacement option will be to run cert-manager + and have traefik point to cert-manager certificates?

not stale

@sylvainblot
Could you rebase and resolve conflict files please? Thank you.
stable/traefik/Chart.yaml
stable/traefik/README.md
stable/traefik/templates/deployment.yaml
stable/traefik/templates/service.yaml
stable/traefik/values.yaml

Is the only thing needed to rebase and solve conflicts? i can do it now.
This would be really usefull

Happy New Year!

The deployment defaults to 1 replica, which has the full feature support. This was one of the main reasons to use the deployment in the first place.

Yes of course, but I guess no all users of Traefik use Lets Encrypt and set 1 to replica isn't for production.

it makes more sense to use a deployment with anti-affinity to push pods to all nodes instead of using a DaemonSet

It's exactly the same (let's encrypt not supported too), except the config is more complex

that many users don't require the same number of Traefik pods as they have nodes to handle traffic

So not all users, plus like i say earlier, i've already experiment issue when you don't have enough replica or well spread in the cluster with compute autoscaling. DaemonSet ensure you always have one pod (if your cluster still have one node)

Agree with @Eraac and other posters here (inc me above :slightly_smiling_face:).
The decision to ignore / move away from (additional) daemonset support is not a good one. The project owners appear to only be considering one specific use case, but others do need the ability to run as a daemonset for at least the several reasons / scenarios given above.
Traefik maintainers, is there any harm in allowing this feature that people need?

Hello All,
Despite not posting on this PR, we have been discussing this question a lot within the Traefik team.
I will share some of our conclusions here.
Traefik version 1 is in maintenance mode, and the v2 release will be imminent. This is why work on the v1 helm chart has been minimal since the spring, as most people will want to upgrade to v2 once it is GA. For this reason, we are hesitant to make any large changes to this chart.
Traefik v2 will not support LetsEncrypt in multi-node mode, so the option of a daemonset will not work if users want to use LE. For this reason, it makes more sense to use a deployment with anti-affinity to push pods to all nodes instead of using a daemonset.
Due to issues with root users, privileged ports, etc, it is unlikely that we will want to use host networking, or host ports on a public and production-recommended chart.
It is more likely that the v2 chart will move in the opposite direction, and move entirely to non-root, and non-privileged ports, with the option to override if your environment supports them.

This is a valid argument for hostNetwork assumming the node running traffic doesn't have an additional firewall (or securityGroup). Firewall or not, hostNetwork opens the admin port, which is not good.
hostPort support in this chart or the v2 chart would be great (with or without daemonset). There is no security risk in opening hostPort 80/443. In a cloud environment, it is not the best option but there are other use cases that need it.

Another reason against a daemonset is that many users don't require the same number of Traefik pods as they have nodes to handle traffic. Usually a few will suffice. If not, then the resource limits should be tweaked, or run a few more replicas. With people running on public clouds, resources = $$$. We should be aiming to be efficient, and scale up when needed, not down.
Finally, the examples in the Traefik v2 documentation etc will be deployment only (for the reasons above). It would make sense to keep the configuration similar to assist users with their needs. We haven't come across a compelling reason to add a daemonset requirement for v2, so until that time, we will proceed with deployment only.
I hope this gives some clarity into this issue, and how we view it moving forward.
Thanks,
The Traefik Team.

authors: Aisuko Bessonov EdanBrooke Eraac MrD2 dfang dtomcej hlascelles leifcr onedr0p simon-jouet simonwh strigazi sylvainblot zanhsieh


text:
[stable/kiam] fix README typo

Signed-off-by: Yusuke Komahara euno.tb@gmail.com

What this PR does / why we need it:
Just fixed a typo on README.md in stable/kiam.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped

/assign
/ok-to-test

/lgtm

authors: davidkarlsen euno7 maorfr


text:
[stable/metallb] Fix helm warnings

What this PR does / why we need it:
Fixed helm warnings about configInline not being a table (when set).
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/chart])

Mentioning @danderson as he is listed as a maintainer.
This fixes CI/CD pipelines that break due to helm warnings.

/ok-to-test
/assign

authors: cpanato winromulus


text:
[stable/metrics-server] Enhance doc/example for priorityClassName (#2…

…1485)
Signed-off-by: rootsami rootsami@gmail.com

What this PR does / why we need it:
Which issue this PR fixes

fixes #21485

Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[ ] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

/assign @kennethaasan

/assign @olemarkus

/lgtm

authors: olemarkus rootsami


text:
[stable/jenkins] Add runAsUser and runAsGroup to podTemplate

Is this a new chart

NOTE: We're experiencing a high volume of PRs to this repo and reviews will be delayed. Please host your own chart repository and submit your repository to the Helm Hub instead of this repo to make them discoverable to the community. Here is how to submit new chart repositories to the Helm Hub.

No
What this PR does / why we need it:
Adds ability to configure user/group for Jenkins agent containers. Currently it's impossible to do using Jenking Configuration as a Code because of those missing values, causing failure of custom agent sidecar containers with different default user.
Special notes for your reviewer:
@lachie83 Hey, first time making a PR to charts repo so not really sure how it works, should I tag all maintainers here?
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[X] DCO signed
[X] Chart Version bumped
[X] Variables are documented in the README.md
[X] Title of the PR starts with chart name (e.g. [stable/mychartname])

/assign @viglesiasce

@wmcdona89 Isn't it already possible to configure it using podTemplate?
In that case it could be better to add an example rather than introducing yet another field.

@torstenwalter that's true, it is possible to configure using agent.podTemplates. However, this doesn't suit my usecase that well.
I need to define common "base" configuration that then can have specific fields overwritten depending on environment. Since agent.podTemplates is essentially a string I cannot simply overwrite for example image attribute without redefining whole structure again. I could introduce some rendering mechanism but that introduces additional complexity to my configuration and I would like to avoid it if possible.
I also can't see a reason why it should be possible to do it using podTemplates but not additionalAgents. From a user perspective I think that's misleading since both of them claim to do the same thing - configure additional kubernetes pod templates.

/ok-to-test

@torstenwalter lgtm

/lgtm

/retest

/retest

/retest

/retest

/retest

authors: janekbaraniewski scottrigby torstenwalter unguiculus wmcdona89


text:
Correct typos related to AWS deployments

What this PR does / why we need it:
This corrects typos related to AWS deployments specifically related to Secrets Manager and Systems Manager that result in errors during install/upgrade and prevent the correct values from being set.
Which issue this PR fixes

fixes #8153

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped

/assign @frodenas

@frodenas and @william-tran is there a chance that you will have time to look at this pull request?

@tareks can you give me a hint on how to test your changes? I am still new to helm.

/ok-to-test

@tareks can you give me a hint on how to test your changes? I am still new to helm.

@Jeeppler What I've been doing is cloning the latest chart code with the fixes you need from github, then once you have that, you can install the helm chart from the local directory (assuming it's in the current working directory and called "concourse") as follows:
helm install ./concourse -n concourse --namespace concourse --values concourse-values-aws.yaml

Note that the ./concourse is just the source code for the chart:
$ ls concourse
charts  Chart.yaml  OWNERS  README.md  requirements.lock  requirements.yaml  templates  values.yaml

Finally, if you are using the internal postgres database, you might need to copy the source for the stable/postgres chart into the ./concourse/charts directory to satisfy the pre-requisite. You can get that from the helm hcarts repo under: master/stable/postgresql
Hope this helps!

@tareks left some review notes on other places where awsSsmSessionToken needs to be changed to awsSecretsManagerSessionToken.

@tareks left some review notes on other places where awsSsmSessionToken needs to be changed to awsSecretsManagerSessionToken.

@topherbullock Cheers. I'm not seeing any notes. Do you know roughly which files or lines need those? Most of my testing was done with role based access, so any feedback related to how these changes impact session tokens or key/secret auth would be appreciated.

@topherbullock thanks for pitching in! So many PRs so little time...

/assign @topherbullock

I made a few changes to resolve conflicts with new code merged into master.

Just noticed that this PR might be doing something very similar to #8934 ...

@tareks I constantly run into the issue below, while trying to install concourse:
$ helm install ./concourse -n concourse --namespace concourse --values values.yaml
Error: found in requirements.yaml, but missing in charts/ directory: postgresql

I am not able to figure out how to go around it.

@tareks  I could have swore I clicked "Submit Review" before 🙃

@tareks I constantly run into the issue below, while trying to install concourse:
$ helm install ./concourse -n concourse --namespace concourse --values values.yaml
Error: found in requirements.yaml, but missing in charts/ directory: postgresql

I am not able to figure out how to go around it.

@Jeeppler Did you copy the postgresql chart directory into ./concourse/charts? This is just a quick fix to satisfy the dependency requirement? The postgresql chart can be found in the same helm charts repo under stable/postgresql.
Hope this helps.

Modified Chart.yaml to fix a merge conflict related to the chart version number again.

/lgtm

authors: Jeeppler frodenas tareks topherbullock william-tran


text:
Add chart for YOURLS app

Signed-off-by: Léo Colombaro git@colombaro.fr

What this PR does / why we need it:
Th PR add a chart for YOURLS app.
It will help deploying YOURLS image (https://hub.docker.com/_/yourls/) with k8s.
Which issue this PR fixes
N/A
Special notes for your reviewer:
💌
This chart use WordPress chart as a template.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md

/assign @viglesiasce

@darend Thanks, fixed. Also I fixed some other env variables, should be much better.

/assign @lachie83

@darend Done via d74df29. Not sure about the content, good enough?

/assign @linki @mgoodness @foxish @scottrigby
Adding more assignees in an attempt to move the PR forward

@goruha Thanks a lot for your review! 👍 I fixed all the "trivial" things.
For the others, everything is from the WordPress chart that I used as a template. It may be improved for sure but I'm not experienced enough to suggest different approaches...

/lgtm
/approve

@foxish can you help push this through?

Thanks a lot @YKWeyer! 👍
It should be fixed. (And sorry, I didn't got the time yet to run it on my own and check everything is fine...)
If you're on it, could you confirm that it's working correctly? If so, don't hesitate to reply with /approve. Thanks again!

Hi @LeoColomb ,
I am happy to report we now use your chart in our test instance.
One thing I needed was the possibility to store additional environment variables in a Kubernetes secret, and it was quite easy to extend your chart by by wrapping it in an umbrella chart and mount the secrets values it using the extraEnv parameter.
We currently don't use the internal database, metrics, ingress or persistent storage. But as far as I am concerned, I am happy with your template :+1:
/approve

While looking at the current states of PR for new charts in this repo, I'm not more sure anymore if this one will be merge even in a far future.
And since I opened this PR, the Helm Hub has been launch, so I'm thinking of moving the content of this PR in a YOURLS hosted repository and submit the repo to the hub.
What do you think about this, @darend?

While looking at the current states of PR for new charts in this repo, I'm not more sure anymore if this one will be merge even in a far future.
And since I opened this PR, the Helm Hub has been launch, so I'm thinking of moving the content of this PR in a YOURLS hosted repository and submit the repo to the hub.

@LeoColomb 💯

Chart files moved to YOURLS/charts.
Submitted to the Helm Hub via https://github.com/helm/hub/pull/53.
Available (soon) at https://hub.helm.sh/charts/yourls.
Thanks all!

authors: LeoColomb YKWeyer darend


text:
[test] Fix setting Helm timeout

The --timeout flag was replaced with the more general --helm-extra-args.
Signed-off-by: Reinhard Nägele unguiculus@gmail.com

/lgtm

authors: cpanato unguiculus


text:
Default tiller namespace for a kube context?

Is it possible to define a default tiller namespace for a kube context somewhere? If we are following a standard RBAC setup of having a tiller per namespace, then the tiller namespace likely matches the namespaces in the kube config get-contexts, or has a 1-1 mapping to it.
It's not a huge problem, it just means that everyone has to also set the TILLER_NAMESPACE evar as part of swapping contexts before using helm (without it being annoying).

Yes, but we'll still need to connect to a kube cluster so the context is still necessary. ;)
This sounds like a good feature if someone wants to tackle this. We have previous work that ties into the kube context's configured namespace via #2808 and #1400 so there's some historical context (ha) here.

This feature request only applies to Helm v2, and that's closed for new features.

authors: TBBle bacongobbler clux

repo: helm/helm


text:
helm generate --force prints out templates

I don't think this is intentional:
><> helm generate workflow-dev --force
#helm:generate helm tpl $HELM_GENERATE_DIR/tpl/deis-controller-secret-builder-key-auth.yaml --out $HELM_GENERATE_DIR/manifests/deis-controller-secret-builder-key-auth.yaml
apiVersion: v1
kind: Secret
metadata:
  name: builder-key-auth
  namespace: deis
  labels:
    heritage: deis
type: Opaque
data:
  builder-key: QTlYXSdNfFJ+V1FZZ3NQaH4tJGZeIlI9NXZEYW99ZT1aY1plYzY/NkkvLlV6d1R1bDQ0bkB1SjdHJ1JDSzZ6ew==
#helm:generate helm tpl $HELM_GENERATE_DIR/tpl/deis-controller-secret-django-secret-key.yaml --out $HELM_GENERATE_DIR/manifests/deis-controller-secret-django-secret-key.yaml
apiVersion: v1
kind: Secret
metadata:
  name: django-secret-key
  namespace: deis
  labels:
    heritage: deis
type: Opaque
data:
  secret-key: cjBDOHFVOFlEU0pkRlRmZUReOyonTUZQa2tGdz0pUDsrRUB8fXI5YC9eLE1rZHQvekFdMUZASzVDUm5hInNHKQ==
#helm:generate helm tpl $HELM_GENERATE_DIR/tpl/deis-database-secret-creds.yaml --out $HELM_GENERATE_DIR/manifests/deis-database-secret-creds.yaml
apiVersion: v1
kind: Secret
metadata:
  name: database-creds
  namespace: deis
  labels:
    app: deis-database
    heritage: deis
data:
  user: ckFYMEppOFJ5cnY0a2NXWVQ1cDkxSlJoVGNWVFRsVzU=
  password: NGlZRElBU3Fub3NoQXFPQTFqS1FEMnlWVU02akdOaFg=
---> Ran 13 generators.

It looks like v0.6.0 isn't templating secrets at all. They're just printed to stdout.

Found the issue after turning on --debug in the template itself:
[DEBUG] File: /home/bacongobbler/.helm/workspace/charts/workflow-dev/tpl/deis-controller-secret-django-secret-key.yaml, Command: helm --debug tpl /home/bacongobbler/.helm/workspace/charts/workflow-dev/tpl/deis-controller-secret-django-secret-key.yaml --out /home/bacongobbler/.helm/workspace/charts/workflow-dev/manifests/deis-controller-secret-django-secret-key.yaml
[ERROR] File /home/bacongobbler/.helm/workspace/charts/workflow-dev/manifests/deis-controller-secret-django-secret-key.yaml already exists. To overwrite it, please re-run this command with the --force/-f flag.
panic: File /home/bacongobbler/.helm/workspace/charts/workflow-dev/manifests/deis-controller-secret-django-secret-key.yaml already exists. To overwrite it, please re-run this command with the --force/-f flag.

goroutine 1 [running]:
panic(0xae6780, 0xc820298510)
        /usr/local/go/src/runtime/panic.go:464 +0x3e6
github.com/helm/helm/log.Die(0xc8201a96c0, 0xc9, 0x0, 0x0, 0x0)
        /home/bacongobbler/go/src/github.com/helm/helm/log/log.go:46 +0xe1
github.com/helm/helm/cli.glob.func13(0xc8201def00)
        /home/bacongobbler/go/src/github.com/helm/helm/cli/template.go:66 +0x2a3
github.com/helm/helm/vendor/github.com/codegangsta/cli.Command.Run(0xd5e6f0, 0x8, 0x0, 0x0, 0x139edc0, 0x1, 0x1, 0xe026e0, 0x21, 0x0, ...)
        /home/bacongobbler/go/src/github.com/helm/helm/vendor/github.com/codegangsta/cli/command.go:179 +0x1399
github.com/helm/helm/vendor/github.com/codegangsta/cli.(*App).Run(0xc8202138c0, 0xc82000a0c0, 0x6, 0x6, 0x7efdcf87c028, 0xc820298520)
        /home/bacongobbler/go/src/github.com/helm/helm/vendor/github.com/codegangsta/cli/app.go:196 +0x137c
github.com/helm/helm/vendor/github.com/codegangsta/cli.(*App).RunAndExitOnError(0xc8202138c0)
        /home/bacongobbler/go/src/github.com/helm/helm/vendor/github.com/codegangsta/cli/app.go:207 +0x54
main.main()
        /home/bacongobbler/go/src/github.com/helm/helm/helm.go:6 +0x25
[ERROR] Failed to complete generation: failed to execute helm --debug tpl /home/bacongobbler/.helm/workspace/charts/workflow-dev/tpl/deis-controller-secret-django-secret-key.yaml --out /home/bacongobbler/.helm/workspace/charts/workflow-dev/manifests/deis-controller-secret-django-secret-key.yaml (/home/bacongobbler/.helm/workspace/charts/workflow-dev/tpl/deis-controller-secret-django-secret-key.yaml): exit status 2

So it looks like a chicken-and-egg problem. We need to enable --force to helm template if helm generate has --force enabled.

Helm generate -f is working even helm template -f its a behavior from codegansta cli where it considers the value we are giving next to a flag is the value provided to that flag
For example:
$ helm template -f -o deis-database-secret-creds.yaml  /Users/smothiki/.helm/workspace/charts/workflow-dev/tpl/deis-database-secret-creds.yaml
smothikis-MacBook-Pro:helm smothiki$ cat deis-database-secret-creds.yaml
#helm:generate helm tpl $HELM_GENERATE_DIR/tpl/deis-database-secret-creds.yaml --out $HELM_GENERATE_DIR/manifests/deis-database-secret-creds.yaml
apiVersion: v1
kind: Secret
metadata:
  name: database-creds
  namespace: deis
  labels:
    app: deis-database
    heritage: deis
data:
  user: ZVplM08zaEVzSDFvb2VkT3RaMnVXT01IbUthV0FhSHU=
  password: a0wwQ0cyU2xsVDJUZ3RTUTVJdkNsS3FLSGR0WWZzUGs=

works because after -f there -o another flag
 helm template -f /Users/smothiki/.helm/workspace/charts/workflow-dev/tpl/deis-database-secret-creds.yaml -o deis-database-secret-creds.yaml
#helm:generate helm tpl $HELM_GENERATE_DIR/tpl/deis-database-secret-creds.yaml --out $HELM_GENERATE_DIR/manifests/deis-database-secret-creds.yaml
apiVersion: v1
kind: Secret
metadata:
  name: database-creds
  namespace: deis
  labels:
    app: deis-database
    heritage: deis
data:
  user: SURsaUU0UGpibnY2YklaRGJmSEFncFdSRk5ERzhTU2k=
  password: YUFSVGh1TlZPVHI3cE9rMVVjQk5EVTNTbnRQcFJLWVc=

the above command doesnt work cause it thinks   /Users/smothiki/.helm/workspace/charts/workflow-dev/tpl/deis-database-secret-creds.yaml  is a value to the flag -f . which messes up stuff . Either we have to change the commands in the deis charts or execute -f at the end .

I've got a fix incoming

turns out it's our own incorrect usage of helm tpl in our charts. The fix is in https://github.com/deis/charts/pull/239. Closing!

authors: bacongobbler smothiki


text:
cannot validate certificate for xxx because it doesn't contain any IP SANs

Hi,
I have a custom kubernetes cluster v1.11.3 with selfsigned certificates, everything looks fine untill install tiller.
tiller can be successfully installed in k8s cluster with helm init but I can do nothing:
$ helm list
Error: forwarding ports: error upgrading connection: error dialing backend: x509: cannot validate certificate for 10.10.100.20 because it doesn't contain any IP SANs

$ kubectl cluster-info
Kubernetes master is running at https://10.10.100.20:6443
CoreDNS is running at https://10.10.100.20:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

$ helm version
Client: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}
Error: forwarding ports: error upgrading connection: error dialing backend: x509: cannot validate certificate for 10.10.100.20 because it doesn't contain any IP SANs

Please help, thanks.

Seems like an issue with the self-signed certificates provided with your API server. Go is very strict about certificate validation and will not accept a certificate for an IP address unless its properly listed in the certificate as a Subject Alternative Name (SAN).

@bacongobbler Certificate used for kube-apiserver? Looks I have desired SAN defined there:

I'm wondering is it saying the kubelet certificate does not contain IP SANs?
$ kubectl get pod --namespace kube-system
NAME                            READY     STATUS    RESTARTS   AGE
coredns-69bcbbf897-2gngq        1/1       Running   0          23h
coredns-69bcbbf897-dnscn        1/1       Running   1          23h
tiller-deploy-85cb87cf7-rv4sw   1/1       Running   0          18h
weave-net-j5r7j                 2/2       Running   0          19h
weave-net-n92b8                 2/2       Running   0          23h
weave-net-nr8bl                 2/2       Running   0          19h
$ kubectl logs tiller-deploy-85cb87cf7-rv4sw --namespace kube-system
Error from server: Get https://10.10.100.20:10250/containerLogs/kube-system/tiller-deploy-85cb87cf7-rv4sw/tiller: x509: cannot validate certificate for 10.10.100.20 because it doesn't contain any IP SANs

@bacongobbler I did a couple of tests and found it was a kubelet certificate issue, now I disabled kubelet https and everything works fine.

Disabling kubelet https doesn't sound like a good workaround for this? I am seeing this issue too after upgrading to kubernetes v1.11.5 on EKS

Yes, AWS EKS 1.11.5 (1.11.8 master now) throwing same error

@MarkFreebairn @asloan7  I am facing the same issue. How did you guys resolve it?

@AnkurJain10 I haven't resolved it, I am still using kubernetes v1.10.11 as I can't upgrade because of this issue. I am not sure if it is fair to say it is an issue with helm or if it is an issue with kubernetes.

@AnkurJain10  I started using AWS EKS approved AMI which has the  TLS bootstrap, currently listed here: https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html

Hey all.  I'm having the same issue.  Based on this thread it seems like the workarounds are:

(@yongzhang 's post ) Disable kubelet HTTPS
(@asloan7 's post) Use an EKS approved AMI.
Dont upgrade.

I'm not in a position to downgrade and I've re-deployed my AMI to one in Asloan's list and disabling HTTPS is not an option either.


text:
Report all errors back to the user when creating a release

I am trying to install a chart with a user that doesn't have write permissions in a namespace:
▶ helm install test bitnami/apache -n kubeapps
Error: create: failed to create: secrets is forbidden: User "system:serviceaccount:kubeapps:kubeapps-view" cannot create resource "secrets" in API group "" in the namespace "kubeapps"

The problem is that if I give permissions one by one, every time I execute the command, I get a different error:
▶ helm install test bitnami/apache -n kubeapps
Error: services is forbidden: User "system:serviceaccount:kubeapps:kubeapps-view" cannot create resource "services" in API group "" in the namespace "kubeapps"

The interesting part is that if I add the --atomic flag to delete the release in case of failure, helm tries to delete all the elements of the chart. It returns an error with the element that failed to be created and all the elements that failed to be deleted:
▶ helm install test2 bitnami/apache -n kubeapps --atomic
Error: an error occurred while uninstalling the release. original install error: services is forbidden: User "system:serviceaccount:kubeapps:kubeapps-view" cannot create resource "services" in API group "" in the namespace "kubeapps": uninstallation completed with 2 error(s): services "test2-apache" is forbidden: User "system:serviceaccount:kubeapps:kubeapps-view" cannot delete resource "services" in API group "" in the namespace "kubeapps"; deployments.apps "test2-apache" is forbidden: User "system:serviceaccount:kubeapps:kubeapps-view" cannot delete resource "deployments" in API group "apps" in the namespace "kubeapps"

In other words, it would be helpful for the install command to behave as the uninstall does.
Also, it would be useful to return the error in a structured way rather than as a big string message to be able to parse it easily.
Output of helm version:
▶ helm version
version.BuildInfo{Version:"v3.0.2", GitCommit:"19e47ee3283ae98139d98460de796c1be1e3975f", GitTreeState:"clean", GoVersion:"go1.13.5"}

Output of kubectl version:
▶ kubectl version
Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.1", GitCommit:"d224476cd0730baca2b6e357d144171ed74192d6", GitTreeState:"clean", BuildDate:"2020-01-14T21:04:32Z", GoVersion:"go1.13.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.0", GitCommit:"70132b0f130acc0bed193d9ba59dd186f0e634cf", GitTreeState:"clean", BuildDate:"2020-01-14T00:09:19Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.):  Kind

To anyone looking to implement this, the SelfSubjectAccessReview API might be useful:
https://kubernetes.io/docs/reference/access-authn-authz/authorization/#checking-api-access

Hi, @andresmgot - thanks for this idea! I'm closing this issue because we now have a recommended path forward for proposals: if you'd like to formally propose this idea, please file a Helm Improvement Proposal to discuss it with the community. Thanks!

authors: andresmgot bridgetkromhout jlegrone


text:
--set-file adding newline

For some reason it seems --set-file adds a newline to variables in question.
% helm version
version.BuildInfo{Version:"v3.3.0", GitCommit:"8a4aeec08d67a7b84472007529e8097ec3742105", GitTreeState:"dirty", GoVersion:"go1.14.7"}
% kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.8", GitCommit:"9f2892aab98fe339f3bd70e3c470144299398ace", GitTreeState:"clean", BuildDate:"2020-08-14T11:09:22Z", GoVersion:"go1.14.7", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"17+", GitVersion:"v1.17.9-eks-4c6976", GitCommit:"4c6976793196d70bc5cd29d56ce5440c9473648e", GitTreeState:"clean", BuildDate:"2020-07-17T18:46:04Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
EKS 1.17
I am trying to load files via --set-file, which does work, however when using in _helper, I see the variables include a newline which is not in the file itself.
% cat dh.username
myusername
%

helm template $NAME --set namespace=$NAME -f jakku-values.yaml \
--set-file=imageCredentials.username=dh.username \
--set-file=imageCredentials.password=dh.password \
--set=imageCredentials.email=my@email.com\
--set-file=admin.password=ch.password \
--set-file=admin.username=ch.username \
.

In the helper:
{{/*
Provide Docker registry information
*/}}
{{- define "imagePullSecret" }}
{{- with .Values.imageCredentials }}
{{- printf "{\"auths\":{\"%s\":{\"username\":\"%s\",\"password\":\"%s\",\"email\":\"%s\",\"auth\":\"%s\"}}}" (.registry | trim) .username .password .email (printf "%s:%s" .username .password | b64enc) | b64enc }}
{{- end }}
{{- end }}

This produces output where each 'with' variable has a newline (which breaks docker registry format).  I had to use trim to work around this.
{{/*
Provide Docker registry information
*/}}
{{- define "imagePullSecret" }}
{{- with .Values.imageCredentials }}
{{- printf "{\"auths\":{\"%s\":{\"username\":\"%s\",\"password\":\"%s\",\"email\":\"%s\",\"auth\":\"%s\"}}}" (.registry | trim) (.username | trim) (.password | trim) (.email | trim) (printf "%s:%s" .username .password | b64enc) | b64enc }}
{{- end }}
{{- end }}

I don't see anything about the newline in the docs.  Any thoughts what my misstep is?

For reference, the full implementation for --set-file can be found here:
https://github.com/helm/helm/blob/9b42702a4bced339ff424a78ad68dd6be6e1a80a/pkg/cli/values/options.go#L74-L82
I think this may have more to do with your Go template than --set-file. All --set-file does is set the value to the contents of the file.
From https://golang.org/pkg/text/template/#hdr-Text_and_spaces

By default, all text between actions is copied verbatim when the template is executed. For example, the string " items are made of " in the example above appears on standard output when the program is run.

However, to aid in formatting template source code, if an action's left delimiter (by default "{{") is followed immediately by a minus sign and ASCII space character ("{{- "), all trailing white space is trimmed from the immediately preceding text. Similarly, if the right delimiter ("}}") is preceded by a space and minus sign (" -}}"), all leading white space is trimmed from the immediately following text. In these trim markers, the ASCII space must be present; "{{-3}}" parses as an action containing the number -3.

For instance, when executing the template whose source is

"{{23 -}} < {{- 45}}"

the generated output would be

"23<45"

For this trimming, the definition of white space characters is the same as in Go: space, horizontal tab, carriage return, and newline.

Have you tried modifying your template? I notice in some places you're using {{-, and in others you're using }}. The former will strip all preceding newline characters, while the latter will not. Try playing around with your template a bit and see if you can find a workable solution that way.

authors: bacongobbler ronaldpetty


text:
Update using_helm.md

In docs/using_helm.md, it says on line 214 that you can pass in a YAML formatted file, but the example commands following that sentence create JSON code but names the file with a .yml extension. For clarity, I propose saying that it will accept JSON or YAML but clarify in the code that for the example we're making a JSON file.

@pmcanseco Thanks for the contribution. On Helm we use a DCO. Could you please provide signoff on your commit. Directions are on the checks tab of the PR.

@pmcanseco Thanks for the contribution. On Helm we use a DCO. Could you please provide signoff on your commit. Directions are on the checks tab of the PR.

done!

-f only accepts YAML as input so the docs are wrong in this case. Can we instead make the output of the echo properly-formed YAML? https://github.com/helm/helm/blob/1801fa0074a0207f4d5724667858b53d52c486f8/cmd/helm/install.go#L197

ping

authors: bacongobbler mattfarina pmcanseco


text:
Update react-sortable-hoc

We'll need to update react-sortable-hoc to the lates version.
There is a collapse issue with SidebarCollapsibleCard though. The card doesn't collapse during the sort phase. It looks like the library changed it's rendering methods to clone the DOM node during sorting. It doesn't look like we can get React to re-render things when sorting happens.
Hopefully we can tap into the new updateBeforeSortStart callback to resolve this.

Bump, for @plbabin

repo: helpscout/hsds-react


text:
Remove Helix import

This PR removes the helix library import that was added on https://github.com/helpscout/hsds-react/releases/tag/v2.87.0 to avoid increasing bundle size.
The imported module was not being used so I assume we won't have any issues :)

Pull Request Test Coverage Report for Build 3056

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 3055:
0.0%

Covered Lines:
154

Relevant Lines:
154

💛  - Coveralls

authors: Charca coveralls


text:
Add possibility to set random seed for smoothed p-values

Hi,
In order to ensure repdoducability of experiments, it would be useful to be able to set a random seed for the computation of smoothed p-values. In particular when working with small datasets. One solution might be to pass the seed as an optional argument to WrapClassifyer/WrapRegressor.

I would like to second this request. I have an issue requesting this functionality in calibrated-explanations, where we get different explanations for the same instance depending on whether we make a batch explanation of multiple instances or explain one instance at a time.

Hi,
Thanks for the suggestion! This has now been fixed in version 0.7.1; please take a look!
Best regards,
Henrik

repo: henrikbostrom/crepes


text:
decouple get .env file from two parent folders of the project.

I do not have a .env file in the project folder, but I have one in a folder at the top parent directory outside of project folder. Decouple are reading this file.
/home/user/repository/
    | .env # decouple should not read this file
    | github/
        | projects/
            | myproject /
                | manage.py
                | myproject/
                    | settings.py
                    | urls.py
                    | wsgi.py
                | app1/

Yes, decouple searches recursively for a .env file.
What different behavior do you need?

I expect him to read recursively only within the current project folder, not the any parent folder of current project folder.
It took me a long time to figure out where he was getting the configuration, because, in the folder of the current project, there is no .env file and none of the directories parent of the current project folder is listed in PYTHONPATH.
It is a completely unexpected behavior

Eu espero que ele leia recursivamente somente dentro da pasta do projeto atual, não a pasta pai da pasta qualquer projeto atual.
Levei muito tempo para descobrir onde ele estava recebendo a configuração, porque, na pasta do projeto atual, não há nenhum arquivo .env e nenhum dos diretórios pai da pasta do projeto atual está listado em PYTHONPATH.
É um comportamento completamente inesperado

Maybe we could make it more explicit on the docs.

Decouple knows nothing about the python path.
I plan to improve the Config class so you can define a specific path without recursion.
The generic config is a AutoConfig instance and it's supposed to search recursively for the .env file.

I'm no free time at the moment, but then I try to create a sample project to try to reproduce the problem.

Acho que eu entendi o seu problema. Só que há um conflito entre a forma q
vc organiza suas coisas e o comportamento padrão do decouple.

oh God, havia esquecido completamente disto aqui.

@fandrefh
**remove os.path.sep **
`import os
from decouple import AutoConfig
CONFIG_DIR = os.path.join(os.path.dirname(file), 'config')
config = AutoConfig(search_path=CONFIG_DIR)
SECRET_KEY = config('SECRET_KEY')
`

@henriquebastos aparentemente, AutoConfig não está respeitando search_path
tendo um arquivo .env com o seguinte conteudo:
SECRET_KEY=segredosecreto

e tendo a seguinte estrutura de diretórios:
(myproject) fabio@luzfcb:~/projects$ tree myproject -L 2
myproject
├── .env
├── README.md
├── backend
│   ├── README.md
│   ├── myproject/
│   ├── configure_django.py  # decouple está aqui
│   └── serverless.yml
├── buildspec.yaml
├── cloudformation
│   └── dev-resources.yaml
├── codecov.yml
├── requirements.txt
├── requirements_dev.txt
├── setup.cfg
├── testspec.yaml
└── tox.ini

em configure_django.py
import os
from decouple import AutoConfig

PROJECT_ROOT = os.path.dirname(os.path.dirname(__file__))

config = AutoConfig(search_path=PROJECT_ROOT)

SECRET_KEY = config('SECRET_KEY')
print("SECRET_KEY: {}".format(SECRET_KEY))

se, dentro da pasta myproject/backend eu fizer:
(myproject) fabio@luzfcb:~/projects/myproject/backend$ python configure_django.py
SECRET_KEY=segredosecreto

e depois executar mover o arquivo .env para o HOME
(myproject) fabio@luzfcb:~/projects/myproject/backend$ mv ../.env $HOME/.env

e fizer novamente
(myproject) fabio@luzfcb:~/projects/myproject/backend$ python configure_django.py
SECRET_KEY=segredosecreto

authors: henriquebastos luzfcb solababs

repo: henriquebastos/python-decouple


text:
Create 0000-01-02-henry-chen.md

adding new file
anotther edit?

more commentsd?dfdfdg

repo: henry-chen/github-slideshow


text:
Clean up dependencies

#105

Although not perfect, this PR at least accomplishes two things:

Replace GLMakie with CairoMakie in testing to avoid precompilation and test failure;
Loosen the related package version limitation caused by GLMakie.

When I checked the recent TestParticleMakie CI runs, they all showed green while they actually failed.

Although not perfect, this PR at least accomplishes two things:

Replace GLMakie with CairoMakie in testing to avoid precompilation and test failure;
Loosen the related package version limitation caused by GLMakie.

When I checked the recent TestParticleMakie CI runs, they all showed green while they actually failed.
Let's make a quick tagged version for this.

All checks of TestParticleMakie CI should have passed, are the failures you mentioned referring to those warnings?

Although not perfect, this PR at least accomplishes two things:

Replace GLMakie with CairoMakie in testing to avoid precompilation and test failure;
Loosen the related package version limitation caused by GLMakie.

When I checked the recent TestParticleMakie CI runs, they all showed green while they actually failed.
Let's make a quick tagged version for this.

All checks of TestParticleMakie CI should have passed, are the failures you mentioned referring to those warnings?

Those warnings related to TestParticleMakie are part of the testing itself.


text:
modify decaptcha.py to support tesseract "3.04.00"

tesseract 3.04 has slightly changed its output of --version
both branches dev and master are affected

+1

+1


text:
Remove debugging-deletes.md

debugging-deletes.md shouldn't be relevant anymore, as we're now two releases past the version that had problems, and we've added code to remove the finalizer that caused the problem.  Remove and re-gen the docs without it.

Fixed by #653 #655

repo: heptio/ark


text:
添加 payer的时候报错： 请确保该值小于等于2147483647

测试了下，是可以添加这么长的account Id的。


text:
Not possible to add multiple kernel parameters with the same name.

I need to add the kernel parameters console=tty0 console=ttyS0 to my kernel boot options. I tried this:
kernel_parameter { "console":
value => "tty0",
}
kernel_parameter { "console":
value => "ttyS0",
}
But this does not work because I am not allowed to define kenel_parameter["console"] twice.

Pass an array of values instead: value => ['tty0', 'ttyS0']
https://github.com/hercules-team/augeasproviders_grub/#manage-parameter-with-multiple-values
http://augeasproviders.com/documentation/examples.html#kernelparameter-provider

You are right, I just discovered this in the documentation after submitting this. Sorry, I should have checked this earlier.

authors: domcleal fhimpe

repo: hercules-team/augeasproviders


text:
HARP-13852 Increase precision, otherwise tilt is too inaccurate

Improve the epsilon used when comparing the dot product.
When the tilt animation has finished, a final check is done to see if the targeted tilt is reached, and if not, we apply the delta needed to reach the desired tilt.

@atomicsulfate , I agree, I will put the test in a separate PR, so we can at least get this into the release.

@atomicsulfate , I agree, I will put the test in a separate PR, so we can at least get this into the release.

retest this please

retest this please


text:
OLPEDGE-383. Shared libs ON. Libsegfault lib added.

Shared libs tuned ON.
Linux libsegfault library added for segmentation fault crash identification in logs.
Resolves: OLPEDGE-383

Fixed comment and updated branch with latest master fixes.

repo: heremaps/here-olp-edge-sdk-cpp


text:
🛑 T.A.R.L.A. Yardım Masası is down

In f0313b9, T.A.R.L.A. Yardım Masası ($TARLA_YARDIM) was down:

HTTP code: 0
Response time: 0 ms

Resolved: T.A.R.L.A. Yardım Masası is back up in 8627f63 after 15 days, 21 hours, 24 minutes.

repo: hermesthecat/hermes-uptime


text:
Convert heroku/buildpacks-jvm to GitHub Actions

Pipeline migrated from Circle CI :tada:
Manual steps
Perform the follow steps to complete the migration:
heroku/buildpacks-jvm/ci

[ ] Ensure a runner with the following labels exists: sfdc-hk-ubuntu-latest
[ ] Ensure a runner with the following labels exists: sfdc-hk-ubuntu-20.04-large

Will be implemented by #397

authors: Malax mgomes

repo: heroku/buildpacks-jvm


text:
Introduce jvm-engine buildpack

The existing heroku/jvm buildpack both provides and requires itself unconditionally. That means if you put heroku/jvm in a build order it will always run even if it is specified as optional.
What does that mean? Most build packs will always provide a resource (like "ruby") but only require it if it has a positive signal (such as presence of a Gemfile on disk). The JVM buildpack is different because the JVM ecosystem can be used with wildly different JVM applications, many of them do not have a single file that would indicate it needs the JDK. To support this set of various use cases it always installs the JVM.
This always-install behavior is a problem for the Ruby buildpack due to JRuby support. JRuby is provided by the same buildpack as Ruby the only difference is that it needs the JVM installed (and it downloads a jruby binary from S3). To install the JVM the heroku/ruby builder has heroku/jvm specified as an optional dependency. Due to existing behavior that means the JVM is installed for ALL ruby applications even if is not using the JVM. This eats up disk space and takes up build time.
There are possible fixes:

A: Introduce an only-provide buildpack and change the existing heroku/jvm buildpack to be a no-op that always requires the other buildpack. Then the heroku/ruby (and any other build packs) can optionally depend on the JVM through the regular require interface.
B: Introduce a new JRuby buildpack that fails to detect if jruby is not detected (via inspecting the Gemfile.lock). Use this to make a new group along with the heroku/jvm and place that group above the existing heroku/ruby group. Remove the heroku/jvm group from the heroku/ruby group. This would have the effect of only installing the JVM for JRuby apps.
C: Edit: Only require jvm when a valid file is matched on disk (https://github.com/heroku/buildpacks-jvm/pull/541)
D: Some other option

This PR implements option A. It moves the existing logic to a heroku/jvm-engine buildpack and removes its require. Then the heroku/jvm buildpack is stripped of all logic and all it does is require the jvm provided by the heroku/jvm-engine.
The upside of this approach is that any buildpack can use the heroku-jvm-engine much like the heroku-nodejs-engine to install the JVM optionally. As long as the existing heroku/jvm builder is updated with both build packs then this should be a non-breaking change save if someone was using the heroku/jvm buildpack directly (not through the builder), they'll now need to also add the heroku/jvm-engine buildpack as well.
Other thoughts
This interface is really funky. It's a very-round about way of expressing what should be a seemingly common use case. Having the builder separated from the buildpack and provide/require be based on a string instead of a specific resource leads to very difficult to reason about resolution logic.
Another option (but it won't meet our timescale) could be a change to the builder spec: For instance we could expose the optional flag to a buildpack in the detect phase to let a buildpack know if it is being treated as optional or not and change its behavior accordingly.
Longer term it's worth experimenting with alternative interfaces that we could build on top of these three primitives (builder, buildpack, provide/require build plans). I've proposed a theoretical middleware like interface (Rack middleware would be my design inspiration as I come from Ruby) but I've not sketched up any kind of implementation ideas.

C: Some other option

Another option would be to not add another buildpack, but instead:

Change the heroku/jvm buildpack so it only requires itself if some Java-related files are found
Make the heroku/java buildpack and other Java-related buildpacks explicitly require the JVM (just in case no Java related files are found in the project)
Make the Ruby buildpack conditionally require the JVM if the Ruby project is found to be a JRuby project

The only disadvantage of this approach would be that anyone using heroku/jvm directly (and not via heroku/java etc) would need to ensure they have a known Java-related files in their app source, or heroku/jvm would no longer pass detection.
However, to me this still seems preferable to creating an empty buildpack just for the sake of requires/provides.

Change the heroku/jvm buildpack so it only requires itself if some Java-related files are found

Manuel had this to say before "There is no "Java package manager" like there is for other languages. Many Java customers also install the JVM standalone without using any package manager. The last point is actually the main reason for requiring itself: sometimes it's the only thing a customer wants, there is no other buildpack that could ever require it."
To that end, one of the ways I think about usability is the number of steps something takes. I.e. declaring "use heroku/jvm as a buildpack" is one step and so is setting an env var or writing a file to disk. Another option could be:

Introduce a pseudo standard for declaring your app needs/wants the JVM

This is somewhat similar to the history of Procfile, and we also have app.json (maybe that could be utilized?) I would ideally propose something that gets checked in with the repo. Possibly just an empty system.properties file. Then we could have the jvm buildpack execute for every build group optionally, much like nodejs.

Make the Ruby buildpack conditionally require the JVM if the Ruby project is found to be a JRuby project

I don't think that's possible without a second builder. It's what we're doing today:

https://github.com/heroku/builder/blob/ec92d59f464e1e2e32638e9808c3c767ea1022bd/builder-22/builder.toml#L69-L72
https://github.com/heroku/buildpacks-ruby/blob/2022e5d2fea4acb3d082e121d95b99f8382da85e/buildpacks/ruby/src/main.rs#L52-L54

I intend(ed) to make a second PR to the Ruby buildpack to explore what it looks like to have a jruby-detect (or similar buildpack) that could be used to generate a second grouping that is non-optional. Something like this:
[[order]]
  [[order.group]] # Proposed jruby buildpack ordering
    id = "heroku/nodejs-engine"
    version = "0.8.24"
    optional = true
  [[order.group]]
    id = "heroku/nodejs-yarn"
    version = "0.4.4"
    optional = true
  [[order.group]]
    id = "heroku/jvm"
    version = "1.0.10"
    optional = true
  [[order.group]] # Fails if does not detect jruby in order
    id = "heroku/jruby-detect"
    version = "2.0.0"
  [[order.group]]
    id = "heroku/ruby"
    version = "2.0.0"
  [[order.group]]
    id = "heroku/procfile"
    version = "2.0.0"
    optional = true
  [[order.group]] # Current heroku/ruby buildpack minus the JVM buildpack
    id = "heroku/nodejs-engine"
    version = "0.8.24"
    optional = true
  [[order.group]]
    id = "heroku/nodejs-yarn"
    version = "0.4.4"
    optional = true
  [[order.group]]
    id = "heroku/ruby"
    version = "2.0.0"
  [[order.group]]
    id = "heroku/procfile"
    version = "2.0.0"
    optional = true

[[order]] # Current buildpack grouping without jvm
  [[order.group]]
    id = "heroku/nodejs-engine"
    version = "1.1.0"
    optional = true
  [[order.group]]
    id = "heroku/nodejs-yarn"
    version = "1.1.0"
    optional = true
  [[order.group]]
    id = "heroku/ruby"
    version = "2.0.0"
  [[order.group]]
    id = "heroku/procfile"
    version = "2.0.0"
    optional = true

Though now that I'm thinking of implementation, I see a failure mode:

If the JRuby group fails detection (due to some bug) then it would still pass detection for the regular ruby group, but the JVM wouldn't be installed yet. I guess that's not technically any different than what I've got today and I'm not doing anything to improve that failure mode. So while that behavior might be surprising, it's not worse than what we've got today.

Manuel had this to say before "There is no "Java package manager" like there is for other languages. Many Java customers also install the JVM standalone without using any package manager. The last point is actually the main reason for requiring itself: sometimes it's the only thing a customer wants, there is no other buildpack that could ever require it."

Yeah I wasn't meaning check for a package manager, but instead for say the presence of .jar files in the app source, or say a system.properties file (given that specifying an explicit JVM version should really be best practice, so if someone wants to run a JVM without a package manager, then it seems reasonable to say they have to have a system.properties file perhaps, if the .jar file idea isn't viable etc?).

Here's a spike on that idea @edmorley https://github.com/heroku/buildpacks-jvm/pull/541

Apart from issue I see with the engine naming, I think we should invert this and create an explicit jvm-standalone buildpack that users can opt-in to if they need the JVM for any reason when it's not required by another buildpack. This keeps things simple both for us implementation wise and the user.
I have the required changes locally already and will open a PR soon that implements ☝🏻. This should unblock @schneems' use-case with the Ruby buildpack.
I'm closing this in favor of the strategy I outlined before. Feel free to re-open if you disagree.

Linking PRs https://github.com/heroku/buildpacks-jvm/pull/545

authors: Malax edmorley schneems


text:
Feature/Bump RBNaCl dependency up to v7.1.1

Bumped major version of rbnacl gem

RBNaCl gem bumped from 6.0.1 to 7.1.1
Gets rid of the following warnings in test specs for other projects using this dependency: [DEPRECATION] Struct layout is already defined for class RbNaCl::HMAC::State. Redefinition as in <YOUR_GEMS_PATH>/gems/ruby-3.2.1/gems/rbnacl-6.0.1/lib/rbnacl/hmac/sha512256.rb:103:in `<class:State>' will be disallowed in ffi-2.0.
Added faraday-retry v2.2 gem to project
Gets rid of this silly octokit warning: To use retry middleware with Faraday v2.0+, install `faraday-retry` gem
More info on this here
Updated vendor/cache
Added .tool-versions to switch ruby version to 2.7.7 locally when loading the project from the terminal
Bumped project gem version to 0.4.5

Work Item: W-13904643

I'm good if you are! I'll bump it up.


text:
🛑 Software Center - Test 1 is down

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

HTTP code: 0
Response time: 0 ms

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

repo: herrphon/upptime


text:
🛑 Software Center - Test 1 is down

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

HTTP code: 0
Response time: 0 ms

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


text:
🛑 Auth-Bridge - Test 1 is down

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

HTTP code: 0
Response time: 0 ms

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


text:
🛑 Software Center - Test 1 is down

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

HTTP code: 0
Response time: 0 ms

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


text:
🛑 Auth-Bridge - Test 1 is down

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

HTTP code: 0
Response time: 0 ms

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


text:
🛑 Auth-Bridge - Test 1 is down

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

HTTP code: 0
Response time: 0 ms

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


text:
🛑 Software Center - Test 1 is down

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

HTTP code: 0
Response time: 0 ms

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


text:
🛑 Software Center - Test 1 is down

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

HTTP code: 0
Response time: 0 ms

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


text:
🛑 Software Center - Test 1 is down

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

HTTP code: 0
Response time: 0 ms

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


text:
🛑 Software Center - Test 1 is down

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

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 70c7d0c after 672 days, 16 hours, 16 minutes.


text:
🛑 Auth-Bridge - Test 1 is down

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

HTTP code: 0
Response time: 0 ms

Resolved: Auth-Bridge - Test 1 is back up in 8e8724f after 10 minutes.


text:
🛑 Auth-Bridge - Test 1 is down

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

HTTP code: 0
Response time: 0 ms

Resolved: Auth-Bridge - Test 1 is back up in 505bd37 after 10 minutes.


text:
🛑 Software Center - Test 1 is down

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

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in fff542a after 1 hour.


text:
🛑 Software Center - Test 1 is down

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

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in b6c6ae8 after 27 minutes.


text:
🛑 Software Center - Test 1 is down

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

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 08049d2 after 22 minutes.


text:
🛑 Software Center - Test 1 is down

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

HTTP code: 0
Response time: 0 ms

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


text:
🛑 Software Center - Test 1 is down

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

HTTP code: 0
Response time: 0 ms

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


text:
🛑 Software Center - Test 1 is down

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

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in b002049 after 22 minutes.


text:
🛑 Auth-Bridge - Test 1 is down

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

HTTP code: 0
Response time: 0 ms

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


text:
Dutch translation

I provide a translation into dutch. Some words such tag cloud and powered by are not translated because the translations are rarely used and sound to artificial.

look good.

authors: Xuanwo cgerull

repo: hexojs/hexo-theme-landscape


text:
Change theme mnh demo address

Check List
Please read and check followings before submitting a PR.

[*] I want to publish my theme on Hexo official website.

[*] I have read the theme publishing doc.
[*] name is unique.
[*] link URL is correct.
[*] preview URL is correct.
[*] preview URL web site is rendered correctly.
[*] Add a screenshot to source/themes/screenshots.
[*] Screenshot filename is same as value of name.
[*] Screenshot size is 800 * 500.
[*] Screenshot file format is png.

[ ] I want to publish my plugin on Hexo official website.

[ ] I have read the plugin publishing doc.
[ ] name is unique.
[ ] link URL is correct.

[ ] Others (Update, fix, translation, etc...)

Languages:
[ ] en English
[ ] ru Russian
[ ] zh-cn simplified Chinese
[ ] zh-tw traditional Chinese

Note
No need to translate ko, pt-br, th languages if you submit a PR for documentation.

Warning
ko, pt-br, th languages document are inactive. Please, submit issue if you want to continuous contribution to them.

My blog has changed its theme, but I will still maintain this theme. Therefore, I am migrating the demo page to another subroute.

repo: hexojs/site


text:
Add Russian as Estonian language

Russian is very common in Estonia.

29.7% of people in Estonia speak Russian.  I think this is a practical addition.

authors: martinholmin rposborne

repo: hexorx/countries


text:
Consider Adding support for RSX

Is your feature request related to a problem? Please describe.
I've been using Dioxus a lot recently, and I was wondering if there was a possibility that this could support "RSX" style formatting. Syntactically, it's extremely similar to JSX, so I don't think adding the ability to support it would be that much of an ask.
RSX Example:
div {
    class: "mx-auto max-w-fit flex justify-center bg-black text-white",
    ...
}

Describe the solution you'd like
From what I can tell, it's likely that Headwind just doesn't know to run when a .rs file is open.
In the tailwindCSS extension for vscode, this is solved by changing the setting tailwindCSS.includeLanguages
"tailwindCSS.includeLanguages": {
  "rust": "html"
}

Perhaps Headwind could implement something similar? Then this would apply to future JSX-like language formats.
Describe alternatives you've considered
I can't really think of anything other than trying to write everything in JSX or similar and then having my program do some hacky read from a file stuff.
Additional context
For what it's worth, I have tried adding regex to the headwind.classRegex setting like so, but that seems to do nothing.
"headwind.classRegex": {
  ...
  "rust": "class: \"(.*)\""
}

I've also attempted an edited JSX regex from #85
"headwind.classRegex": {
  "rust": "(?:\\b(?:class)(?::(?:{\\s*)?)?[\\\"]([\\w\\s\\-\\:\\[\\]]+)[\\\"])"
}

@alice-werefox
I am also working with dioxus. Adding the following to setting.json fixed it for my situation.
You have to make sure to kill all the vscode process and restart, so that regex will be effective.
  "headwind.classRegex": {
    "rust": "\\bclass\\s*:\\s*[\\\"\\']([_a-zA-Z0-9\\s\\-\\:\\/]+)[\\\"\\']"
  }

authors: Ameyanagi alice-werefox

repo: heybourn/headwind


text:
[ 问题咨询 ] MySQL的实例账号密码应该授予什么权限

问题描述
wiki中的数据库管理中，建议提供下账号权限的说明，目前为空。
版本信息

应用版本/分支：Release v1.8.2
部署方式：Docker

问题描述
wiki中的数据库管理中，建议提供下账号权限的说明，目前为空。
版本信息

应用版本/分支：Release v1.8.2
部署方式：Docker

我实际使用过程中，觉得最好是专用账号，给all权限，如果要用到archery授权，还要有grant option权限

repo: hhyo/Archery


text:
HHH-14541 SessionFactoryObserver#sessionFactoryClosing() gets called after the session factory is marked as closed

https://hibernate.atlassian.net/browse/HHH-14541

@Sanne FYI I would like to backport this to 5.4, too. No problem with that?

repo: hibernate/hibernate-orm


text:
HSEARCH-3588 Clean up TODOs in the code

https://hibernate.atlassian.net//browse/HSEARCH-3588
@fax4ever There's no point in reviewing this, I'll just wait for the Sonar report, fix things if necessary and merge.

@yrodiere sounds good

Pull Request Test Coverage Report for Build 1

0 of 0   changed or added relevant lines in 0 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.02%) to 89.022%

Files with Coverage Reduction
New Missed Lines
%

mapper/orm/src/main/java/org/hibernate/search/mapper/orm/impl/HibernateSearchContextService.java
1
83.02%

Totals

Change from base Build 261:
0.02%

Covered Lines:
18116

Relevant Lines:
20350

💛  - Coveralls

authors: coveralls fax4ever yrodiere

repo: hibernate/hibernate-search


text:
gitlab: asking every time

I think I have something wrong.
I added a token for a (on-premise) gitlab-repository and configured accordingly:
[credential]
	helper = cache --timeout 72000
	helper = oauth
[credential "https://gitlab.my.tld"]
	oauthClientId = d1dced4c03ef4f8axxxxxxxxxxxxxxxxxxxxxxb2216e3a
	oauthAuthURL = /oauth/authorize
  oauthTokenURL = /oauth/token
  oauthScopes = write_repository

Every time I run for example git pull (or maybe: at the first run in a terminal?) the browser pops up and I have to authorize the access. I assume this is not the intended behavior? How to fix that? Thanks!

GitLab requires the username be 'oauth2'. Check your remote URL  git remote -v and remove any username.

I have the remote "origin	https://gitlab.mytld/sgw/myrepo.git"
git config credential.username returns nothing.
I googled a bit and added the line "username = oauth" to the section "remote" in .git/config (in my cloned/local repository) . Might work, so far it does without asking again. I test that, thanks!

Great. Please reopen if you have further problems.

Unfortunately I see this again.
I share my config:
# in ~/.gitconfig

[credential]
	helper = cache --timeout 7200
	helper = oauth
[credential "https://gitlab.my.tld"]
  oauthClientId = 59286d8534aexxx
  oauthScopes = write_repository

# in the repository
# cat .git/config
[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
[remote "origin"]
	url = https://gitlab.my.tld/sgw/somerepo.git
  fetch = +refs/heads/*:refs/remotes/origin/*
  username = oauth
[branch "master"]
	remote = origin
	merge = refs/heads/master
[pull]
	rebase = false

It seems it has to be:
[remote "origin"]
	url = https://gitlab.stefanselbach.com/sgw/it-todos.git
  fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
	remote = origin
	merge = refs/heads/master
[pull]
	rebase = false
[credential]
	helper = store
[user]
	name = oauth

testing ...

helper = cache --timeout 7200

Try increasing the cache timeout from 7200 seconds (2 hours) to 72000 seconds (20 hours).
Note that "Credentials are forgotten sooner if the cache-daemon dies, for example if the system restarts" https://git-scm.com/docs/git-credential-cache

helper = store

This won't work well, because helper git-credential-store is unable to save the OAuth refresh token.

You told me to use username "oauth2", that was also wrong, I assume.
I test with this now:
[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
[remote "origin"]
	url = https://gitlab.my.tld/some.git
  fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
	remote = origin
	merge = refs/heads/master
[pull]
	rebase = false
[credential]
	helper = cache --timeout 72000
[user]
	name = oauth2

I'll see after the next reboot or so ... thanks so far

authors: hickford stefangweichinger

repo: hickford/git-credential-oauth


text:
🛑 kiwifarms.st is down

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

HTTP code: 0
Response time: 0 ms

Resolved: kiwifarms.st is back up in 7217327 after 9 minutes.

repo: hickoryhouse/kf


text:
🛑 kiwifarms.pl is down

In b9939fc, kiwifarms.pl (https://kiwifarms.pl) was down:

HTTP code: 502
Response time: 939 ms

Resolved: kiwifarms.pl is back up in 3d5f583.


text:
Updated workflows

Mac wheel building is updated to use cibuildwheel. cibuildwheel version is upgraded to the latest. Support for arm64 arch added for macOS.

Does it make sense to also add wheels for macos-12?

The wheels are the same for macos11 and macos12.
Bharat Medasani
Engineer
Princeton Plasma Physics Lab (PPPL)
On Sat, Jan 14, 2023 at 3:17 PM Matt Landreman @.***>
wrote:

Does it make sense to also add wheels for macos-12?
—
Reply to this email directly, view it on GitHub
https://github.com/hiddenSymmetries/simsopt/pull/284#issuecomment-1382906229,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA62VEETQDUKUDFW6D6BUZ3WSMCXDANCNFSM6AAAAAAT25UWYA
.
You are receiving this because you authored the thread.Message ID:
@.***>

authors: landreman mbkumar

repo: hiddenSymmetries/simsopt


text:
drag event is not triggered on mobile web browser

As title, any solution?

Bump... Facing same issue. Please help.

Using http://jsfiddle.net/highcharts/AyUbx/3789/show/ I am able to see both drag and drop events on the iPhone. Can you show a live demo of the problem?

I am able to drag columns but not able to drag points. Do you face same problem or you are able to drag points as well?
Also, Demo would not be possible as it is a local environment.

I am able to drag points as well... Did you test the demo in my previous post?

authors: TorsteinHonsi akshaysinha samir-kamble

repo: highcharts/draggable-points


text:
Shop Zone - Basic Theft Prevention

This PR introduces basic theft prevention to the shop.
Testplan: https://highfidelity.testrail.net/index.php?/cases/view/1931

Tessting

PASS

authors: Nex-Pro thoys

repo: highfidelity/hifi-content


text:
(python) syntax highlighting bug

See https://chromium-review.googlesource.com/c/infra/infra/+/489582/10/infra/tools/dockerbuild/platform.py and https://bugs.chromium.org/p/gerrit/issues/detail?id=6652

I can't make any sense of this or these links. If there is a bug with a specific language syntax please tell us which and if you could provide a jsfiddle reproducing the issue that'd be great:
Template you can use:
https://jsfiddle.net/ajoshguy/nagkqytv/
Is this a duplicate of https://github.com/highlightjs/highlight.js/issues/1964 ?

I now understand that the site in question uses Highlight.js but we still really could use a much smaller reproducible example in something like jsfiddle.  We're very limited on time and the more direct information you provide the more likely an issue is to get addressed sooner rather than later.
Tagging this beginner friendly if a beginner wants to figure out the exact issue and create some smaller reproducible examples.

For example doing something like:
class Platform(collections.namedtuple('Platform', (
    'name', # The name of the platform.
    'manylinux_name', # If the platform is "manylinux', the "manylinux" Docker
                      # image build name (e.g., "cp27-cp27mu").
    'wheel_abi', # The Python wheel ABI.
    'wheel_plat', # The Python wheel platform.
    'dockcross_base', # The "dockcross" base image (can be None).
    'dockcross_base_upstream', # Does the "dockcross" base image exist upstream?
                               # XXX: REMOVE once all do.
    'openssl_target', # The OpenSSL "Configure" script build target.
    'packaged', # Do Python wheels get packaged on PyPi for this platform?
    'cipd_platform', # The name of the CIPD platform to use.
    ))):

Causes everything to be blue. The comments are not highlighted (is plain black).
Then when it does:
# If the platform is "manylinux', the "manylinux" Docker
# image build name (e.g., "cp27-cp27mu").

It causes the second line to be blue and a mixture of blue on the first.
Also all text after cipd_platform is blue so e.g doing:
  @property
  def dockcross_base_image(self):
    if not self.dockcross_base:
      return None
    return 'dockcross/%s' % (self.dockcross_base,)

See screenshot:

Looks like comments aren't detected inside function arguments... thanks for better examples. :-)


text:
(js/ts) JSX/TSX support master thread

This is a master thread created to track the overall discussion of our JSX/TSX support.

https://github.com/highlightjs/highlight.js/issues/1625 (comment highlighting)
https://github.com/highlightjs/highlight.js/issues/2324 (inline code)
https://github.com/highlightjs/highlight.js/issues/2721 (JSX inside inline code, ad infinitum)

Support for JSX/TSX is not a single thing.  We already include "basic" support for embedded XML/HTML fragments using the xml sublanguage.  We do not support comments or embedded JS.
This has all been attempted several times and is a very hard problem.  This thread exists to talk about the high level problem instead of the individual mini-problems.

Pulling this form discussion on https://github.com/highlightjs/highlight.js/pull/2412.

I'm pretty sure I became persuaded sublanguage is NOT the correct way to handle this.  JSX is NOT simply XML embedded inside Javascript (as it's handled now).  It's literally an extension to the JS language that also allows JS line comments, inline code, etc... this means the proper way to do it is to treat it as HTML tags within the JS language/grammar.
The problem then becomes you need an actual syntax parser to track the state, count tags (so you know when you leave the JSX fragment and are back in JS land - also accounting for comments, inline JS, JSX inside inline JS, etc)... and full blown parsing is not what we do.
This is made harder by the fact that JS/TS is supported by a single underlying grammar. Plus TSX is also a thing as well.  So a proper solution here has to be able to distinguish between type annotations/casting Array<number> and embedded JSX. Hence the current hasClosingTag logic...


text:
Add ISBL language

Add new language:

ISBL built-in language DIRECTUM
Add New style:
ISBL editor light
ISBL editor dark

What have I done wrong?

@MedvedTMN
Be careful! Do not rebase it! Back up the file ISBL.
Because according to Fred de Villamil:

Well, because git documentation says you shouldn’t. Quoting The Perils of Rebasing,
"Do not rebase commits that exist outside your repository.
If you follow that guideline, you’ll be fine. If you don’t, people will hate you, and you’ll be scorned by friends and family.
When you rebase stuff, you’re abandoning existing commits and creating new ones that are similar but different. If you push commits somewhere and others pull them down and base work on them, and then you rewrite those commits with git rebase and push them up again, your collaborators will have to re-merge their work and things will get messy when you try to pull their work back into yours."

The best is to do is:

Open the terminal:
a. git clone https://github.com/MedvedTMN/highlight.js old-project
b. git clone https://github.com/highlightjs/highlight.js new-project

cd new-project && mkdir new-project && git mv !(new-project) new-project

git commit -a -S -m “Moving new project into its my own old subdirectory”

If you see the error, do not worry.

cd ../old-project
git remote add new-project ../new-project
git fetch new-project
git checkout -b feature/merge-new-project
git merge -S --allow-unrelated-histories new-project/master

And type your GitHub username and your password.

git push origin feature/merge-new-project

git remote rm new-project

Open your repository page here

Select the branch and change the branch master to feature/merge-new-project

Click in "pull request", your selected branch (feature/merge-new-project) will be selected and compared to.. And select the branch master of your repository.

Submit the pull request and then merge it to your master branch.

Put the backed up file ISBL.

Create the new pull request.

authors: MedvedTMN gusbemacbe