container problem

Hello,
I'm getting an error when I do the following compose. I've attached the container log. What could be the problem?
services:
 submanager:
  image: dh1011/subscription-manager:1.0.0
  container_name: subs-manager
  healthcheck:
      test: timeout 10s bash -c ':> /dev/tcp/<IP_ADDRESS>/3000' || exit 1
      interval: 10s
      timeout: 5s
      retries: 3
      start_period: 90s
  ports:
   - 3541:3000
  environment:
   NODE_ENV: production
   HOST: <IP_ADDRESS>
  volumes:
   - /volume1/docker/submanager/subscriptions.db:/app/subscriptions.db:rw
  restart: on-failure:5
  networks:
      - subscription_network

networks:
  subscription_network:
    name: subscription
    ipam:
      config:
        - subnet: <IP_ADDRESS>/24

container logs:
><EMAIL_ADDRESS>dev
> concurrently "npm run server" "npm run client"
[0]
[0] ><EMAIL_ADDRESS>server
[0] > node server/server.js
[0]
[1]
[1] ><EMAIL_ADDRESS>client
[1] > react-scripts start
[1]
[0] Server running on port 5000
[0] Database initialized successfully
[1] Attempting to bind to HOST environment variable: <IP_ADDRESS>
[1] If this was unintentional, check that you haven't mistakenly set it in your shell.
[1] Learn more here: https://cra.link/advanced-config
[1]
[1] Invalid options object. Dev Server has been initialized using an options object that does not match the API schema.
[1]  - options.allowedHosts[0] should be a non-empty string.
[1] npm run client exited with code 1
npm error path /app
npm error command failed
npm error signal SIGTERM
npm error command sh -c concurrently "npm run server" "npm run client"
npm error A complete log of this run can be found in: /root/.npm/_logs/2024-10-07T12_49_46_522Z-debug-0.log
><EMAIL_ADDRESS>dev
> concurrently "npm run server" "npm run client"
[0]
[0] ><EMAIL_ADDRESS>server
[0] > node server/server.js
[0]
[1]
[1] ><EMAIL_ADDRESS>client
[1] > react-scripts start
[1]
[0] Server running on port 5000
[0] Database initialized successfully
[1] Attempting to bind to HOST environment variable: <IP_ADDRESS>
[1] If this was unintentional, check that you haven't mistakenly set it in your shell.
[1] Learn more here: https://cra.link/advanced-config
[1]
[1] Invalid options object. Dev Server has been initialized using an options object that does not match the API schema.
[1]  - options.allowedHosts[0] should be a non-empty string.
[1] npm run client exited with code 1

try using just this:
services:
submanager:
image: dh1011/subscription-manager:1.0.0
container_name: Subscription-Manager
healthcheck:
test: timeout 10s bash -c ':> /dev/tcp/<IP_ADDRESS>/3000' || exit 1
interval: 10s
timeout: 5s
retries: 3
start_period: 90s
ports:

3541:3000
environment:
NODE_ENV: production
HOST: <IP_ADDRESS>
volumes:
/volume1/docker/submanager/subscriptions.db:/app/subscriptions.db:rw
restart: on-failure:5

nothing has changed. there is no problem with the network. there is a problem when testing healtcheck 3000 because the port inside the container is running at 5000. when I fix it as below the problem goes away.
test: timeout 10s bash -c ':> /dev/tcp/<IP_ADDRESS>/5000' || exit 1

Hi @caglaryalcin,
Thank you for raising the issue,
I'm not entirely sure what the root cause of this issue is, but it seems that using Docker's default network allows the health check on port 3000 to function correctly.
Here’s a brief overview of the underlying setup:
The app uses npm's concurrently to run both an Express.js server on port 5000 (for data handling) and a React front-end on port 3000. To avoid CORS issues, I’ve configured Express.js to proxy requests to the React front-end.

Thank you @dh1011! When should I test it again?


Package request: rtl-sdr-blog

Project description
rtl-sdr-blog is a fork of rtl-sdr with support for the RTL-SDR-BLOG dongles. The upstream rtl-sdr does not support the RTL-SDR-BLOG-V4. rtl-sdr is already packaged.
I'm not sure of the correct way to handle this. Upstream and said fork are mostly compatible for downstream users, but have mildly diverged (+79/-10 commits). For now I have been doing a package override:
nixpkgs.config.packageOverrides = pkgs: {
  # Replace rtl-sdr with rtl-sdr-blog, because the vanilla version does not appear to work with the rtl-sdr-blog dongle.
  rtl-sdr = pkgs.rtl-sdr.overrideAttrs (oldAttrs: {
    src = pkgs.fetchFromGitHub {
      owner = "rtlsdrblog";
      repo = "rtl-sdr-blog";
      rev = "V1.3.4";
      hash = "sha256-4Qeawd8V68j9Gfw+AgLXHhiiTpyJM1/eb16AZCTa0Vc=";
    };
  });
};

...which 'works', but which forces me to rebuild every downstream package. (And requires manual updates.) (And prevents me from using the vanilla rtl-sdr library without additional work although that is not an issue for me currently.)
Metadata

homepage URL: https://www.rtl-sdr.com/rtl-sdr-quick-start-guide/
source URL: https://github.com/rtlsdrblog/rtl-sdr-blog
license: gpl2
platforms: linux, darwin

Add a :+1: reaction to issues you find important.

I have installed both and while the rtl-sdr-osmocom did allow me to receive signal from the dongle, it was overly saturated. Even with a 0 db gain the waterfall in SDR++ was bright yellow.
On the other hand, with the packageOverride @nonnull-ca describes, I was able to use the dongle.
Did you do anything specific to make it work @crazyminecuber ?
I also think it would be nice to have the rtl-sdr-blog modified library available as a binary. While most CLI applications and SDR++ are fairly okay to build I had to give up on building SDRAngel on an older laptop as it would have taken hours for the build to finish.
I couldn't find any discussions about integrating the specific modifications made by the rtl-sdr-blog team to the upstream osmocom version and so I'm doubtful it will happen in the near future.

I did this to overlay the osmocom driver since gqrx for example is built against it.
nixpkgs.overlays = [
   (final: prev: {
     rtl-sdr = prev.rtl-sdr-osmocom;
   })
 ];

But I have not tested that it works 100 % perfectly but at least it seemed to be working and I did not find any obvious issues with oversaturation. How did you "install" the driver?
What specific modifications are you talking about that the blog driver has done exactly? This and a few later commits seem to add support for the v4 dongle in the osmocom driver https://gitea.osmocom.org/sdr/rtl-sdr/commit/1261fbb285297da08f4620b18871b6d6d9ec2a7b

Fixed by https://github.com/NixOS/nixpkgs/pull/304063


Ability to delete notifications without opening said app

It would be really nice, if I could delete notifications without it opening the corresponding app

I have added a way in latest release which lets you swipe left to right when overlay is closed to delete a notification


[WIP] Monkey patch MiqUtil.runcmd to prevent shelling out in test.

In #2277, we noticed that some of the database introspection tests were shelling out to run df.
Specifically, spec/models/vmdb_index_spec.rb and friends.
I'll use this PR to find all places we're not stubbing MiqUtil.runcmd and possibly keep this code even after the callers are fixed.  Maybe we can do the same thing with backtick and AwesomeSpawn.run.

even better, I don't need to prepend a module...

We already have something similar in AwesomeSpawn's own specs here.  In the past, we had it on Kernel.spawn (which is used by backtick), here

I've had this as an open feature request on AwesomeSpawn for a while, but haven't found a nice way to expose to the API.  https://github.com/ManageIQ/awesome_spawn/issues/1

It looks like we have a few implementations of runcmd:
lib/../runcmd.rb (MiqUtil)
lib/../miq_generic_mount_session.rb
vmdb/lib/../miq_postgres_admin.rb
they take similar arguments. Wonder if we can converge them
(NOTE: I did find a few references to 2>&1 but those were interesting at best)
Only 1 system seemed interesting from evm_test_helper.rb
Would also be cool if we could just call into awesome spawn and stub external calls in one place.


Job not rescheduled after reboot on Android 8/9 emulator

On my Android 8 or 9 emulator (tested with both) I'm scheduling a DailyJob using
val builder = JobRequest.Builder(TAG)
val startTime = TimeUnit.HOURS.toMillis(16) + TimeUnit.MINUTES.toMillis(8)
val endTime = TimeUnit.HOURS.toMillis(16) + TimeUnit.MINUTES.toMillis(30)
DailyJob.schedule(builder, startTime, endTime)

I initialize the JobManager from my Application:
JobManager.create(this)
Timber.i("We have ${JobManager.instance().allJobRequests.size} job requests")
JobManager.instance().addJobCreator(notesJobCreator)
Timber.i("JobCreator added")

I'm using 1.2.6 and I don't have the GCM & WorkManager dependencies in my project. After a reboot log shows that the BOOT-receiver works and the job request still exists:
We have 1 job requests
JobCreator added

However, the job never executes (it has a log statement in it so I check on that) and it never shows anything about rescheduling, as you mentioned to look for in #142. Any idea what to check?

It seems to work after all! Maybe I tried to often and the system decided to block/defer background jobs. I don't really have any idea, but right now the jobs are executed after a reboot so everything seems fine.


Add magnetometer support to Android via Input.get_magnetometer()

Someone please review.

Is there a case where the computer might have more than 1 magnetometer?
Like on a PC or a console where you attach peripherals?
On 10 March 2016 at 19:54, fluffrabbit<EMAIL_ADDRESS>wrote:

Someone please review.
You can view, comment on, or merge this pull request online at:
https://github.com/godotengine/godot/pull/4010
Commit Summary

Adds magnetometer support to Android via Input.get_magnetometer()
fixed some line ending bullshit for @tomreyn

File Changes

M core/os/input.cpp
https://github.com/godotengine/godot/pull/4010/files#diff-0 (1)
M core/os/input.h
https://github.com/godotengine/godot/pull/4010/files#diff-1 (3)
M main/input_default.cpp
https://github.com/godotengine/godot/pull/4010/files#diff-2 (14)
M main/input_default.h
https://github.com/godotengine/godot/pull/4010/files#diff-3 (5)
M platform/android/godot_android.cpp
https://github.com/godotengine/godot/pull/4010/files#diff-4 (29)
M platform/android/java/src/org/godotengine/godot/Godot.java
https://github.com/godotengine/godot/pull/4010/files#diff-5 (13)
M platform/android/java/src/org/godotengine/godot/GodotLib.java
https://github.com/godotengine/godot/pull/4010/files#diff-6 (1)
M platform/android/java_glue.cpp
https://github.com/godotengine/godot/pull/4010/files#diff-7 (11)
M platform/android/java_glue.h
https://github.com/godotengine/godot/pull/4010/files#diff-8 (1)
M platform/android/os_android.cpp
https://github.com/godotengine/godot/pull/4010/files#diff-9 (9)
M platform/android/os_android.h
https://github.com/godotengine/godot/pull/4010/files#diff-10 (5)

Patch Links:

https://github.com/godotengine/godot/pull/4010.patch
https://github.com/godotengine/godot/pull/4010.diff

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/pull/4010.

Loving the new smilies.
Hmm. On mobile devices, no. Even if an OTG magnetometer were plugged in, Android and probably other platforms will favor their one internal magnetometer for instance in orientation calculations since it reflects the angle of the device. This works the exact same way as Input.get_accelerometer() (a lot of copying and pasting). For PCs and such, this is an unknown. Maybe there are controllers with accelerometers and magnetometers (PS3 controller or something) and if multiple controllers were plugged in then there would be multiple input sources, but AFAIK Input.get_accelerometer() doesn't account for this possibility as it only applies to internal mobile accelerometers (and now magnetometers). Maybe some functions could be renamed or whatever and I can't speak for all platforms but I know that the way Android is set up it really likes to pretend that its own internal magnetometer (if available) is the only one in the world.

 Based on that and tonight's logs (http://godot.eska.me/irc-logs/devel/2016-03-12.log), I think you really need to review your attitude. We don't merge code from people that don't respect the rest of the community. If it's a wanted feature, I very much welcome another contributor to cherry-pick the changes, merge them all into one and remove offensive comments from the commit logs.


Debugging with Webstorm ?

I'm very new to Nodejs and webpack .. so this might be a silly feature request. Is it possible to have this project to run and debugged under Webstorm ?

Hey! Please see https://github.com/gaearon/react-hot-boilerplate/issues/18 for a discussion.
This project is based on that boilerplate.

The discussion conclusion is that webpack support will be available for Webstorm 11. I'm just wondering how do you debug this project without using print statements ?
I can't find a way to start webpack without packing all the js files into one bundle.js file. Is it possible to tell webpack just to boot up nodejs server without packing it so that Webstorm can debug it ? Please help!

The discussion conclusion is that webpack support will be available for Webstorm 11. I'm just wondering how do you debug this project without using print statements ?

Not sure I understand your question. I use Chrome DevTools for debugging.

I can't find a way to start webpack without packing all the js files into one bundle.js file. Is it possible to tell webpack just to boot up nodejs server without packing it so that Webstorm can debug it ? Please help!

That's how Webpack works. It bundles files into one JS file because they're modular. All modern tools work this way.


Ratelimiter does not keep process running until all requests are finished

Problem example
Here it shows a Promise.all does not longer keep the process alive, it terminates... I guess this ratelimiter was implemented with daemonized scripts in mind?
const axios = require('axios')
const rl = require('axios-rate-limit');

// sets max 2 requests per 1 second, other will be delayed
const http = rl(axios.create(), { maxRequests: 2, perMilliseconds: 1000 });

Promise.all([
  http.get('http://httpbin.org/get').then(x => {console.log(1); return x}),
  http.get('http://httpbin.org/get').then(x => {console.log(2); return x}),
  http.get('http://httpbin.org/get').then(x => {console.log(3); return x}),
]).then(x => {
  console.log('after')
})

Problem workaround
If you count yourself how many requests you scheduled and if they are all finished or just add a global timeout to keep the process alive it works:
const axios = require('axios')
const rl = require('axios-rate-limit');

// sets max 2 requests per 1 second, other will be delayed
const http = rl(axios.create(), { maxRequests: 2, perMilliseconds: 1000 });

Promise.all([
  http.get('http://httpbin.org/get').then(x => {console.log(1); return x}),
  http.get('http://httpbin.org/get').then(x => {console.log(2); return x}),
  http.get('http://httpbin.org/get').then(x => {console.log(3); return x}),
]).then(x => {
  console.log('after')
})

setTimeout(function() {
  console.log('kept alive for 5s')
}, 5000)

No, the bug was introduced in #13. I just released version 1.1.3 with the fix. Could you confirm everything is working as expected now?

That works for me, thanks alot!

If someone knows how to test ref and unref calls or it's sideeffects in Jest, please let me know. The PR is missing tests.


Generated code mutability

The generated photon client can be a single output file which can live anywhere in the repository or a dedicated folder photon/, which may get deleted and re-created from scratch on each code generation.
1) Immutable photon directory
This will put everything photon-related into the photon/ directory, and the user is not allowed to edit anything in this directory. This prevents mixing user code with generated code.
Major caveats:

You would have to generate a single, immutable/read-only directory, and you’d have to/re-create the package each time. This means we would have to delete the directory, which may result in confusing and unwanted behavior, like file system issues (recursively deleting files, accidentally deleting /) or accidentally deleting user code. This also means that users could not add anything to the photon package, which some users may want. For example, you may want to extend a User type to an Admin and Moderator type, and then you could add your own functions in your own user.go file in the same photon package, which would make it impossible to add custom code which may result in inconvenience. *

Note: There was a suggestion to just add "plugins" or functionality to programmatically add custom code which lives somewhere else can be added to the configuration, which could also result in auto-generated code on, for example, each model struct. However, we're far away from a plugin system or custom code generators, and it also adds a lot of complexity to the whole photon go library complex and you'll have “magic” code which may be hard for beginners.

2) Individual generated file
This will generate a single file in a given package, e.g. photon/photon_gen.go. However, you can also add your own go files into the photon package to extend photons functionality.
Useful custom code ideas:

helper methods
extend a User model to Admin and Moderator models
attach methods to photon model structs to satisfy interfaces
custom constructors or wrappers
writing providers for dependency injection

Related: single vs multiple packages (edit: fixed link)

I'd keep the possibility to add custom code to the package, since it doesn't seem to have any disadvantages.

I agree with @darioielardi and propose to close this issue until #3 is decided, since this issue is entirely dependent on #3.
If it is decided to output everything into a single file, then it wouldn't make sense to make the directory immutable.
If the decision is to organize the output in multiple sub-packages, then they (the directories) must be read-only.
Lest you want to end up with weird issues where someone deleted something from the schema but on your computer the generated code still exists - even after repeatedly regenerating the library. Then you use it in the code and end up with strange "works on my machine" scenarios.

@robojones is right, this depends on #3. I'll still keep this open until we have a decision for #3, and then I'll add the findings here for future readers.

Closed in favour of the decisions in #3.


Blazor WASM breakpoints in OnInitialized

Fixes #19377
Internal Review Topic

I prefer a compiler directive for this because a conditional check based on environment would run all the time. DEBUG is built-in. Idk if this will work in a Razor file like this. If there's any doubt on it, I'll run a test and confirm that the approach works. Let me know if I should run such a test. :ear:
What do we show for the recommended delay line?
Won't we need two examples of whatever the delay line is? ... one for synch and one for async.

Will two seconds be enough time as an initial suggestion?

Will two seconds be enough time as an initial suggestion?

Let's bump it up to 10 seconds. That's been our safest bet.

@captainsafia The compiler directive used in this way is known to work, correct? I've never tried it. I can run a test if we need to. :ear:

@guardrex The compiler directive should work in this way.


fix: unparser generates wrong sql for derived table with columns

Which issue does this PR close?
Unparser creates invalid sqls for LogicPlan that generated from sql with derived table with columns.
Rationale for this change
See "Which issue does this PR close", also check below comment.
Copy/pasted from the code comments.
// A roundtrip example for table alias with columns
//
// query: SELECT id FROM (SELECT j1_id from j1) AS c (id)
//
// LogicPlan:
// Projection: c.id
//   SubqueryAlias: c
//     Projection: j1.j1_id AS id
//       Projection: j1.j1_id
//         TableScan: j1
//
// Before introducing this logic, the unparsed query would be `SELECT c.id FROM (SELECT j1.j1_id AS
// id FROM (SELECT j1.j1_id FROM j1)) AS c`.
// The query is invalid as `j1.j1_id` is not a valid identifier in the derived table
// `(SELECT j1.j1_id FROM j1)`

What changes are included in this PR?
Introduce a method that probe the SubqueryAlias plan to see if it contains a double layer of projections. If so, extract column alias from the outer layer projection into table alias and use the inner layer projection for relation construction.
Are these changes tested?
Yes
Are there any user-facing changes?
No

Thanks again @y-f-u


Race Condition Open State Bug When Switching Between Multiple Popovers on Safari

🐛 Bug report
If you have two popovers and one is already open, when you click on the trigger for the second non-opened popover, both popovers close.
This bug only shows up when I tested it in Safari on an IOS device.
https://github.com/user-attachments/assets/4eac1ca3-79ea-4666-9e22-c6078e0d2354
💥 Steps to reproduce

Open up reproduction link
Download reproduction
Run npm i and npm run dev -- --host
Visit network url on an iOS device
Open up first popover
Click on second popover

See that both popovers immediately close after clicking on the second popover.
💻 Link to reproduction
https://stackblitz.com/edit/xxcvzd?file=src%2FApp.tsx
🧐 Expected behavior
On a windows PC, when you click the second popover, it closes the first one and then opens the second one, allowing you to swap between the two at will.
https://github.com/user-attachments/assets/7d87fc4d-47cd-48a2-8869-e67df6522431
🧭 Possible Solution
Currently hacking in a delay to open the second popover after a brief timeout instead of immediately to allow the first popover to finish closing.
🌍 System information

Software
Version(s)

Zag Version
0.74.1

Browser
Safari

Operating System
iPad Pro (iOS 18)

📝 Additional information
Likely a race condition bug introduced by https://github.com/chakra-ui/zag/issues/1788 because when it bugs out, I can see that the first popover has the focus outline.

I just pushed a fix for this. We'll release an update shortly.
If the issue persists after upgrading, I'll re-open it.


ServiceMonitor is not optional

Hey Folks,
first of all - many thanks for the work and effort you put in zeebe.
This piece of software is performing really well in our environment.
I've noticed, that there is a new manifest called service-monitor.yaml which requires the deployment of an additional operator and the corresponding CRDs.
In our case, that specific manifest prohibits a deployment of the latest zeebe-cluster-chart.
Even though the prometheus-operator of CoreOS is a pretty great solution, we should make  the templating of it's ServiceMonitor optional for this zeebe-cluster-chart.
What do you think of adding a simple if around here...
{{- if .Values.prometheusOperator.enabled -}}
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: zeebe-monitor
  labels:
      release: metrics
spec:
  selector:
    matchLabels:
      app: zeebe
  endpoints:
      - honorLabels: true
        port: http
        interval: 10s
{{- end }}

@Hermsi1337 totally ok with that.. can you send a PR for that? we really welcome contributions like that, and for some reason in my setup that was not required. Can I ask which version of Kubernetes are you running? You shouldn't need the operator if the CRD is there.. but that means that in your kubernetes the CRD is missing, so your recommendation is a good option.

@salaboy you're absolutely right, the operator itself is not required, but the CRD's are.   Since we have not deployed the operator, we neither have deployed the CRD`s, thats what I meant.
We're running Kubernetes in version v1.16.6:
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.6", GitCommit:"72c30166b2105cd7d3350f2c28a219e6abcd79eb", GitTreeState:"clean", BuildDate:"2020-01-18T23:23:21Z", GoVersion:"go1.13.5", Compiler:"gc", Platform:"linux/amd64"}
I will create a PR with my mentioned change.

@Hermsi1337 thanks a lot for your contribution. Changes are merged and the charts are released. You can get the latest version by doing helm update if you have the helm.zeebe.io repo added.
Formatting changes really appreciated as well.
Thanks a lot @Zelldon for your comments as well.


Build instructions have stopped working (MacOSX)

The build instructions in the README worked just fine last time a tried it (a week or so ago), but seem to have stopped working recently.
Steps to reproduce:

Clone source locally
Switch to directory
Run: npm install (succeeds)
Run npm run dist-mac

Expected result:
DMG file is built.
Actual result:
$ npm run dist-mac
npm ERR! missing script: dist-mac

npm ERR!      /Users/pmonks/.npm/_logs/2017-06-09T21_54_26_796Z-debug.log

Environmental information:
$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.12.5
BuildVersion:	16F73
$ uname -a
Darwin mthay.local 16.6.0 Darwin Kernel Version 16.6.0: Fri Apr 14 16:21:16 PDT 2017; root:xnu-3789.60.24~6/RELEASE_X86_64 x86_64
$ node --version
v8.1.0

sorry i need to update readme, we removed those steps.
if you want to test out locally, use: npm run dev
currently only supporting build msi (for windows via advanced installer) and pkg (for mac).  we'll update readme on how to build pkg.

Cool - pkg packaging works too.  I can't really use the test locally version since I'm looking to build multiple different binaries with different pods configured (ODP and Foundation production pod).

i've updated the instructions to build pkg for mac.


✨ Attempt to improve tutorial names and descriptions

In response to significant demand from the audience (me) in #231 and #221 and as discussed with @ablaom, I have made a PR with suggestions for better "informative" names and descriptions for the tutorials.
The idea is that it makes one feel better to good idea about what the tutorial will be about before clicking on it. It's been noted that other machine learning packages, e.g., outside of Julia, also tend to use verbose names for their tutorials.
As for the descriptions, I found that it's optimal to resort to using "intended learning outcomes" as the tutorial descriptors for the two following reasons:

They are easier to read (not get lost in) thanks to their list format
They give a clear idea of "why" I should see this tutorial (e.g., can be viewed on the website before clicking)
This could potentially encourage universities in using these tutorials as a fantastic resource to learn MLJ
It should be easy for a third party to write intended learning outcomes for a tutorial they made (and it gives a sense of conformity to the rest of the tutorials)

Note that in later tutorials, I did not write the ILOs in a detailed way because such details were covered in the ILOs of earlier tutorials (e.g., coercing data).
Feel free to suggest even better names or ILOs (or to ditch the ILO idea; it's easy to convert them to descriptions; even automatically).
Note that tutorial names will also have to be updated in the Julia file for each tutorial. However, we can move on to this only when the tutorial names, as shown in the JSON object won't further change in the PR.
Lastly, I know I will do some style changes to accomodate the longer names (e.g., navigation button in the bottom has to be longer now, etc.)

Side note: I noticed that back when I made tags assignment, I erroneously replaced "Data Basics" names/links with "Getting Started" ones. This was fixed here (tags were still correct). Sorry for this.

Will merge after resolving the issue with long list of end to end tutorials:

All good to go. Merge when ready.

Moved two tutorials. Merging now.


Fix some docs, add panic section

Describe when the constructor methods panic. Make the wording around
home directories on non-Windows more precise. Fix some typos.

Should I change the code so that the documentation of the constructor methods BaseDirs::new, UserDirs::new, ProjectDirs::from_path and ProjectDirs::from is in one place and not in each of the operating system's modules, so that it doesn't get out of sync?

documentation of the constructor methods BaseDirs::new, UserDirs::new, ProjectDirs::from_path and ProjectDirs::from is in one place

Oh, I tried doing that and failed, how would you do it?

I cherry-picked these changes (with some tiny modifications) in https://github.com/soc/directories-rs/commit/f9e99da35bd7482df0341c59cd64e8f3933f807f and https://github.com/soc/directories-rs/commit/8b9f9156b4bd9cf43730206300962f2f1dcd4929. Thanks!


code optimization and refactoring

PR Description 📜
Optimization Summary:

replaced var declarations with const or let.
used for...of loop instead of for loop for iterating over arrays.
refactored findResult function for readability and efficiency.
refactored canvas creation and drawing functions for better performance.
consolidated repetitive code in prepElements and prepIcons functions.
optimized the finalize function for readability and performance.
consolidated event listener attachment for better maintainability.
replaced inline styles with CSS classes for styling elements.
used textContent instead of innerText.
implemented DOM manipulation optimizations for better performance.

Fixes #37

Mark the task you have completed ✅

[x] I follow CONTRIBUTING GUIDELINE & CODE OF CONDUCT of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I have followed proper naming convention showed in CONTRIBUTING GUIDELINE
[ ] I have added screenshot for review.

@moroii69 Resolve conflict & add a demo vedio


PRTriage should only be triggered by commit not comment

Summary
Steps to reproduce

Merge PR
Comment

Pull Request URL
N/A
What is the current bug behavior?
PRTriage remove PR: Merged if user comment.
What is the expected correct behavior?
PRTriage should only check commit
Relevant logs and/or screenshots

Possible fixes
(If you have any idea to solve the problem, please help us.)

I think this was triggered because of the branch removal and not the comment. Mind to look again and see if that was the reason? If so maybe we can close this bug?

Can we use synchronized instead of edited?


Treat a string with many commas separating single words as all family names

Chaboo, Bennett, Shin
Those are all family names but the parser says:
[#<Name family="Chaboo" given="Bennett">, #<Name given="Shin">]

From @mjy on Twitter

2.5.1 :016 > a = 'M.R. and J.D. Smith'
=> "M.R. and J.D. Smith"
2.5.1 :017 > b = a.gsub( /([A-Z].[A-Z].) (and) ([A-Z].[A-Z].) (.*)/ , "#{$1} #{$4} and #{$3} #{$4}")
=> "M.R. Smith and J.D. Smith"

Another possibility:
a.gsub(/^(\S{1,}\.?){1,}\s*(?i:and|&)\s*(\S{1,}\.?){1,}\s*(.*)$/, '\1 \3|\2 \3')

Seems fixed in the sense that it identify three people, but it is assuming they're all given names rather than family names.
2.7.2 :001 > DwcAgent.parse "Chaboo, Bennett, Shin"
 => [#<Name given="Chaboo">, #<Name given="Bennett">, #<Name given="Shin">]
2.7.2 :002 > DwcAgent.parse "Hardy, Andrews & Giuliani"
 => [#<Name given="Hardy">, #<Name given="Andrews">, #<Name given="Giuliani">]
2.7.2 :003 > DwcAgent::Version.version
 => "<IP_ADDRESS>"
2.7.2 :004 >

Seems fixed in the sense that it identify three people, but it is assuming they're all given names rather than family names.
2.7.2 :001 > DwcAgent.parse "Chaboo, Bennett, Shin"
 => [#<Name given="Chaboo">, #<Name given="Bennett">, #<Name given="Shin">]
2.7.2 :002 > DwcAgent.parse "Hardy, Andrews & Giuliani"
 => [#<Name given="Hardy">, #<Name given="Andrews">, #<Name given="Giuliani">]
2.7.2 :003 > DwcAgent::Version.version
 => "<IP_ADDRESS>"
2.7.2 :004 >

Thanks for having a look at this. Indeed, what's expected here is that each parsed name then needs to be cleaned:
names = DwcAgent.parse "Chaboo, Bennett, Shin"
DwcAgent.clean names[0]
=> {:title=>nil, :appellation=>nil, :given=>nil, :particle=>nil, :family=>"Chaboo", :suffix=>nil}

Thanks for having a look at this. Indeed, what's expected here is that each parsed name then needs to be cleaned:
names = DwcAgent.parse "Chaboo, Bennett, Shin"
DwcAgent.clean names[0]
=> {:title=>nil, :appellation=>nil, :given=>nil, :particle=>nil, :family=>"Chaboo", :suffix=>nil}

Many thanks for pointing out DwcAgent.clean! Was not aware of it. Should it be included in README.md?

Many thanks for pointing out DwcAgent.clean! Was not aware of it. Should it be included in README.md?

Good point. I'll add that.

Good point. I'll add that.


⚠ Bofrost.at has degraded performance

In ac52d65, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 2746 ms

Resolved: Bofrost.at performance has improved in cd4f8b6 after 8 minutes.


Bug: Not able to configure gitops, getting authentication handshake failed.

📜 Description
Unable to configure GitOps in the latest released version (v0.6.27). Getting "msg":"error in getting jwt token with username & password","err":"rpc error: code = Unavailable desc = connection error: desc = "transport: authentication handshake failed: tls: failed to verify certificate: x509: certificate signed by unknown authority"
Criticality
P0 - Critical/Blocking
Impact on Enterprise

Unable to deploy applications as gitops cannot be configured in devtron.

👟 Steps to replicate the Issue

Install latest version of devtron into a kubernetes cluster.
Setup gitops with gitlab using PAT.
Error

👍 Expected behavior
Gitops should be configured successfully.
👎 Actual Behavior
Getting the following error:
[Feb 16 2024 12:49:08 GMT+0530] devtron-68566796c8-5l4k9: {"level":"debug","ts":1708067948.0019996,"caller":"pipeline/CdHandler.go:289","msg":"received argo cd pipelines stuck at kubectl apply synced stage","pipelines":null} [Feb 16 2024 12:49:08 GMT+0530] devtron-68566796c8-5l4k9: {"level":"debug","ts":1708067948.0031743,"caller":"pipeline/CdHandler.go:297","msg":"received argo appStore application stuck at kubectl apply synced stage","pipelines":null} [Feb 16 2024 12:49:13 GMT+0530] devtron-68566796c8-5l4k9: {"level":"info","ts":1708067953.3510125,"caller":"restHandler/GitOpsConfigRestHandler.go:95","msg":"request payload, CreateGitOpsConfig","err":null,"payload":{"provider":"GITLAB","username":"john@doe.com","token":"********","gitLabGroupId":"70435","gitHubOrgId":"","host":"https://gitlab.com/","active":true,"azureProjectName":"","bitBucketWorkspaceId":"","bitBucketProjectKey":"","gitRepoName":"","userEmailId":"","description":""}} [Feb 16 2024 12:49:15 GMT+0530] devtron-68566796c8-5l4k9: {"level":"debug","ts":1708067955.2478583,"caller":"util/GitServiceGitlab.go:76","msg":"gitlab config","config":{"GitlabGroupId":"70435","GitlabGroupPath":"testGroup","GitToken":"******","GitUserName":"john@doe.com","GitWorkingDir":"/tmp/gitops/","GithubOrganization":"","GitProvider":"GITLAB","GitHost":"https://gitlab.com/","AzureToken":"**********","AzureProject":"","BitbucketWorkspaceId":"","BitbucketProjectKey":""}} [Feb 16 2024 12:49:15 GMT+0530] devtron-68566796c8-5l4k9: {"level":"info","ts":1708067955.2479286,"caller":"util/GitService.go:170","msg":"client changed successfully","cfg":{"GitlabGroupId":"70435","GitlabGroupPath":"testGroup","GitToken":"********","GitUserName":"john@doe.com","GitWorkingDir":"/tmp/gitops/","GithubOrganization":"","GitProvider":"GITLAB","GitHost":"https://gitlab.com/","AzureToken":"********","AzureProject":"","BitbucketWorkspaceId":"","BitbucketProjectKey":""}} [Feb 16 2024 12:49:15 GMT+0530] devtron-68566796c8-5l4k9: {"level":"error","ts":1708067955.2487638,"caller":"util/ChartService.go:643","msg":"error in getting emailId from active gitOps config","err":"pg: no rows in result set","stacktrace":"github.com/devtron-labs/devtron/internal/util.(*ChartTemplateServiceImpl).GetUserEmailIdAndNameForGitOpsCommit\n\t/go/src/github.com/devtron-labs/devtron/internal/util/ChartService.go:643\ngithub.com/devtron-labs/devtron/pkg/gitops.(*GitOpsConfigServiceImpl).GitOpsValidateDryRun\n\t/go/src/github.com/devtron-labs/devtron/pkg/gitops/GitOpsConfigService.go:724\ngithub.com/devtron-labs/devtron/pkg/gitops.(*GitOpsConfigServiceImpl).ValidateAndCreateGitOpsConfig\n\t/go/src/github.com/devtron-labs/devtron/pkg/gitops/GitOpsConfigService.go:129\ngithub.com/devtron-labs/devtron/api/restHandler.GitOpsConfigRestHandlerImpl.CreateGitOpsConfig\n\t/go/src/github.com/devtron-labs/devtron/api/restHandler/GitOpsConfigRestHandler.go:102\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/devtron-labs/common-lib/middlewares.Recovery.func1\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/devtron-labs/common-lib/middlewares/recovery.go:26\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/devtron-labs/devtron/internal/middleware.PrometheusMiddleware.func1\n\t/go/src/github.com/devtron-labs/devtron/internal/middleware/instrument.go:132\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/devtron-labs/devtron/api/util.LoggingMiddlewareImpl.LoggingMiddleware.func1\n\t/go/src/github.com/devtron-labs/devtron/api/util/logger.go:66\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/gorilla/mux.(*Router).ServeHTTP\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/gorilla/mux/mux.go:210\ngithub.com/devtron-labs/authenticator/middleware.Authorizer.func1.1\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/devtron-labs/authenticator/middleware/AuthMiddleware.go:71\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\nnet/http.serverHandler.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2936\nnet/http.(*conn).serve\n\t/usr/local/go/src/net/http/server.go:1995"} [Feb 16 2024 12:49:15 GMT+0530] devtron-68566796c8-5l4k9: {"level":"debug","ts":1708067955.2488568,"caller":"util/GitServiceGitlab.go:95","msg":"gitlab app create request ","name":"devtron-sample-repo-dryrun-dxx16o","description":""} [Feb 16 2024 12:49:15 GMT+0530] devtron-68566796c8-5l4k9: {"level":"debug","ts":1708067955.5890741,"caller":"util/GitServiceGitlab.go:216","msg":"gitlab get project err","pid":"testGroup/devtron-sample-repo-dryrun-dxx16o","err":"GET https://gitlab.com/api/v4/projects/testGroup/devtron-sample-repo-dryrun-dxx16o: 404 {message: 404 Project Not Found}"} [Feb 16 2024 12:49:17 GMT+0530] devtron-68566796c8-5l4k9: {"level":"info","ts":1708067957.4906795,"caller":"util/GitServiceGitlab.go:172","msg":"gitlab app created","name":"devtron-sample-repo-dryrun-dxx16o","url":"https://gitlab.com/testGroup/devtron-sample-repo-dryrun-dxx16o.git"} [Feb 16 2024 12:49:19 GMT+0530] devtron-68566796c8-5l4k9: {"level":"debug","ts":1708067959.4057343,"caller":"util/GitService.go:312","msg":"git checkout ","url":"https://gitlab.com/testGroup/devtron-sample-repo-dryrun-dxx16o.git","dir":"/ensure-clone/devtron-sample-repo-dryrun-dxx16o"} [Feb 16 2024 12:49:19 GMT+0530] devtron-68566796c8-5l4k9: {"level":"info","ts":1708067959.4057734,"caller":"util/GitCliUtil.go:133","msg":"git clone<EMAIL_ADDRESS>[Feb 16 2024 12:49:19 GMT+0530] devtron-68566796c8-5l4k9: {"level":"debug","ts":1708067959.4067495,"caller":"util/GitCliUtil.go:33","msg":"git fetch ","location":"/tmp/gitops/ensure-clone/devtron-sample-repo-dryrun-dxx16o"} [Feb 16 2024 12:49:20 GMT+0530] devtron-68566796c8-5l4k9: {"level":"debug","ts":1708067960.2595594,"caller":"util/GitCliUtil.go:36","msg":"fetch output","root":"/tmp/gitops/ensure-clone/devtron-sample-repo-dryrun-dxx16o","opt":"From https://gitlab.com/testGroup/devtron-sample-repo-dryrun-dxx16o\n * [new branch]      master     -> origin/master","errMsg":"","error":null} [Feb 16 2024 12:49:20 GMT+0530] devtron-68566796c8-5l4k9: {"level":"warn","ts":1708067960.2596066,"caller":"util/GitCliUtil.go:140","msg":"git fetch completed, pulling master branch data from remote origin"} [Feb 16 2024 12:49:20 GMT+0530] devtron-68566796c8-5l4k9: {"level":"debug","ts":1708067960.2596138,"caller":"util/GitCliUtil.go:69","msg":"git branch ","location":"/tmp/gitops/ensure-clone/devtron-sample-repo-dryrun-dxx16o"} [Feb 16 2024 12:49:20 GMT+0530] devtron-68566796c8-5l4k9: {"level":"debug","ts":1708067960.2608624,"caller":"util/GitCliUtil.go:72","msg":"branch output","root":"/tmp/gitops/ensure-clone/devtron-sample-repo-dryrun-dxx16o","opt":"origin/master","errMsg":"","error":null} [Feb 16 2024 12:49:20 GMT+0530] devtron-68566796c8-5l4k9: {"level":"info","ts":1708067960.2608852,"caller":"util/GitCliUtil.go:147","msg":"total branch available in git repo","branches":["origin/master"]} [Feb 16 2024 12:49:20 GMT+0530] devtron-68566796c8-5l4k9: {"level":"debug","ts":1708067960.260894,"caller":"util/GitCliUtil.go:45","msg":"git pull ","location":"/tmp/gitops/ensure-clone/devtron-sample-repo-dryrun-dxx16o"} [Feb 16 2024 12:49:20 GMT+0530] devtron-68566796c8-5l4k9: {"level":"debug","ts":1708067960.997014,"caller":"util/GitCliUtil.go:48","msg":"pull output","root":"/tmp/gitops/ensure-clone/devtron-sample-repo-dryrun-dxx16o","opt":"From https://gitlab.com/testGroup/devtron-sample-repo-dryrun-dxx16o\n * branch            master     -> FETCH_HEAD","errMsg":"","error":null} [Feb 16 2024 12:49:20 GMT+0530] devtron-68566796c8-5l4k9: {"level":"info","ts":1708067960.997083,"caller":"util/GitServiceGitlab.go:201","msg":"gitlab ensureProjectAvailability clone passed","try count":1,"repoUrl":"https://gitlab.com/testGroup/devtron-sample-repo-dryrun-dxx16o.git"} [Feb 16 2024 12:49:20 GMT+0530] devtron-68566796c8-5l4k9: {"level":"debug","ts":1708067960.9971483,"caller":"util/GitService.go:312","msg":"git checkout ","url":"https://gitlab.com/testGroup/devtron-sample-repo-dryrun-dxx16o.git","dir":"devtron-sample-repo-dryrun-dxx16o-6906717860577957873"} [Feb 16 2024 12:49:20 GMT+0530] devtron-68566796c8-5l4k9: {"level":"info","ts":1708067960.9971642,"caller":"util/GitCliUtil.go:133","msg":"git clone<EMAIL_ADDRESS>[Feb 16 2024 12:49:20 GMT+0530] devtron-68566796c8-5l4k9: {"level":"debug","ts":1708067960.997634,"caller":"util/GitCliUtil.go:33","msg":"git fetch ","location":"/tmp/gitops/devtron-sample-repo-dryrun-dxx16o-6906717860577957873"} [Feb 16 2024 12:49:21 GMT+0530] devtron-68566796c8-5l4k9: {"level":"debug","ts":1708067961.8244953,"caller":"util/GitCliUtil.go:36","msg":"fetch output","root":"/tmp/gitops/devtron-sample-repo-dryrun-dxx16o-6906717860577957873","opt":"From https://gitlab.com/testGroup/devtron-sample-repo-dryrun-dxx16o\n * [new branch]      master     -> origin/master","errMsg":"","error":null} [Feb 16 2024 12:49:21 GMT+0530] devtron-68566796c8-5l4k9: {"level":"warn","ts":1708067961.8245409,"caller":"util/GitCliUtil.go:140","msg":"git fetch completed, pulling master branch data from remote origin"} [Feb 16 2024 12:49:21 GMT+0530] devtron-68566796c8-5l4k9: {"level":"debug","ts":1708067961.8245478,"caller":"util/GitCliUtil.go:69","msg":"git branch ","location":"/tmp/gitops/devtron-sample-repo-dryrun-dxx16o-6906717860577957873"} [Feb 16 2024 12:49:21 GMT+0530] devtron-68566796c8-5l4k9: {"level":"debug","ts":1708067961.825689,"caller":"util/GitCliUtil.go:72","msg":"branch output","root":"/tmp/gitops/devtron-sample-repo-dryrun-dxx16o-6906717860577957873","opt":"origin/master","errMsg":"","error":null} [Feb 16 2024 12:49:21 GMT+0530] devtron-68566796c8-5l4k9: {"level":"info","ts":1708067961.8257127,"caller":"util/GitCliUtil.go:147","msg":"total branch available in git repo","branches":["origin/master"]} [Feb 16 2024 12:49:21 GMT+0530] devtron-68566796c8-5l4k9: {"level":"debug","ts":1708067961.8257205,"caller":"util/GitCliUtil.go:45","msg":"git pull ","location":"/tmp/gitops/devtron-sample-repo-dryrun-dxx16o-6906717860577957873"} [Feb 16 2024 12:49:22 GMT+0530] devtron-68566796c8-5l4k9: {"level":"debug","ts":1708067962.5576692,"caller":"util/GitCliUtil.go:48","msg":"pull output","root":"/tmp/gitops/devtron-sample-repo-dryrun-dxx16o-6906717860577957873","opt":"From https://gitlab.com/testGroup/devtron-sample-repo-dryrun-dxx16o\n * branch            master     -> FETCH_HEAD","errMsg":"","error":null} [Feb 16 2024 12:49:22 GMT+0530] devtron-68566796c8-5l4k9: {"level":"debug","ts":1708067962.560679,"caller":"util/GitService.go:354","msg":"git hash","repo":"/tmp/gitops/devtron-sample-repo-dryrun-dxx16o-6906717860577957873","hash":"a0c8f69c7c3983832b11486a9d302fb0108485b8"} [Feb 16 2024 12:49:24 GMT+0530] devtron-68566796c8-5l4k9: {"level":"info","ts":1708067964.1384392,"caller":"util/GitServiceGitlab.go:147","msg":"deleting project ","gitlab project name":"devtron-sample-repo-dryrun-dxx16o"} [Feb 16 2024 12:49:24 GMT+0530] devtron-68566796c8-5l4k9: {"level":"debug","ts":1708067964.3441439,"caller":"k8s/K8sUtil.go:694","msg":"getting k8s rest config"} [Feb 16 2024 12:49:24 GMT+0530] devtron-68566796c8-5l4k9: time="2024-02-16T07:19:24Z" level=info msg="Starting configmap/secret informers" [Feb 16 2024 12:49:24 GMT+0530] devtron-68566796c8-5l4k9: time="2024-02-16T07:19:24Z" level=info msg="Configmap/secret informer synced" [Feb 16 2024 12:49:24 GMT+0530] devtron-68566796c8-5l4k9: {"level":"error","ts":1708067964.6606488,"caller":"argo/ArgoUserService.go:304","msg":"error in getting jwt token with username & password","err":"rpc error: code = Unavailable desc = connection error: desc = \"transport: authentication handshake failed: tls: failed to verify certificate: x509: certificate signed by unknown authority\"","stacktrace":"github.com/devtron-labs/devtron/util/argo.(*ArgoUserServiceImpl).createTokenForArgoCdUser\n\t/go/src/github.com/devtron-labs/devtron/util/argo/ArgoUserService.go:304\ngithub.com/devtron-labs/devtron/util/argo.(*ArgoUserServiceImpl).createNewArgoCdTokenForDevtron\n\t/go/src/github.com/devtron-labs/devtron/util/argo/ArgoUserService.go:146\ngithub.com/devtron-labs/devtron/util/argo.(*ArgoUserServiceImpl).GetOrUpdateArgoCdUserDetail\n\t/go/src/github.com/devtron-labs/devtron/util/argo/ArgoUserService.go:113\ngithub.com/devtron-labs/devtron/pkg/gitops.(*GitOpsConfigServiceImpl).ValidateAndCreateGitOpsConfig\n\t/go/src/github.com/devtron-labs/devtron/pkg/gitops/GitOpsConfigService.go:132\ngithub.com/devtron-labs/devtron/api/restHandler.GitOpsConfigRestHandlerImpl.CreateGitOpsConfig\n\t/go/src/github.com/devtron-labs/devtron/api/restHandler/GitOpsConfigRestHandler.go:102\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/devtron-labs/common-lib/middlewares.Recovery.func1\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/devtron-labs/common-lib/middlewares/recovery.go:26\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/devtron-labs/devtron/internal/middleware.PrometheusMiddleware.func1\n\t/go/src/github.com/devtron-labs/devtron/internal/middleware/instrument.go:132\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/devtron-labs/devtron/api/util.LoggingMiddlewareImpl.LoggingMiddleware.func1\n\t/go/src/github.com/devtron-labs/devtron/api/util/logger.go:66\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/gorilla/mux.(*Router).ServeHTTP\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/gorilla/mux/mux.go:210\ngithub.com/devtron-labs/authenticator/middleware.Authorizer.func1.1\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/devtron-labs/authenticator/middleware/AuthMiddleware.go:71\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\nnet/http.serverHandler.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2936\nnet/http.(*conn).serve\n\t/usr/local/go/src/net/http/server.go:1995"} [Feb 16 2024 12:49:24 GMT+0530] devtron-68566796c8-5l4k9: {"level":"error","ts":1708067964.6607323,"caller":"argo/ArgoUserService.go:148","msg":"error in creating new argocd user","err":"rpc error: code = Unavailable desc = connection error: desc = \"transport: authentication handshake failed: tls: failed to verify certificate: x509: certificate signed by unknown authority\"","stacktrace":"github.com/devtron-labs/devtron/util/argo.(*ArgoUserServiceImpl).createNewArgoCdTokenForDevtron\n\t/go/src/github.com/devtron-labs/devtron/util/argo/ArgoUserService.go:148\ngithub.com/devtron-labs/devtron/util/argo.(*ArgoUserServiceImpl).GetOrUpdateArgoCdUserDetail\n\t/go/src/github.com/devtron-labs/devtron/util/argo/ArgoUserService.go:113\ngithub.com/devtron-labs/devtron/pkg/gitops.(*GitOpsConfigServiceImpl).ValidateAndCreateGitOpsConfig\n\t/go/src/github.com/devtron-labs/devtron/pkg/gitops/GitOpsConfigService.go:132\ngithub.com/devtron-labs/devtron/api/restHandler.GitOpsConfigRestHandlerImpl.CreateGitOpsConfig\n\t/go/src/github.com/devtron-labs/devtron/api/restHandler/GitOpsConfigRestHandler.go:102\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/devtron-labs/common-lib/middlewares.Recovery.func1\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/devtron-labs/common-lib/middlewares/recovery.go:26\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/devtron-labs/devtron/internal/middleware.PrometheusMiddleware.func1\n\t/go/src/github.com/devtron-labs/devtron/internal/middleware/instrument.go:132\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/devtron-labs/devtron/api/util.LoggingMiddlewareImpl.LoggingMiddleware.func1\n\t/go/src/github.com/devtron-labs/devtron/api/util/logger.go:66\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/gorilla/mux.(*Router).ServeHTTP\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/gorilla/mux/mux.go:210\ngithub.com/devtron-labs/authenticator/middleware.Authorizer.func1.1\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/devtron-labs/authenticator/middleware/AuthMiddleware.go:71\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\nnet/http.serverHandler.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2936\nnet/http.(*conn).serve\n\t/usr/local/go/src/net/http/server.go:1995"} [Feb 16 2024 12:49:24 GMT+0530] devtron-68566796c8-5l4k9: {"level":"error","ts":1708067964.660774,"caller":"argo/ArgoUserService.go:115","msg":"error in creating new argo cd token for devtron","err":"rpc error: code = Unavailable desc = connection error: desc = \"transport: authentication handshake failed: tls: failed to verify certificate: x509: certificate signed by unknown authority\"","stacktrace":"github.com/devtron-labs/devtron/util/argo.(*ArgoUserServiceImpl).GetOrUpdateArgoCdUserDetail\n\t/go/src/github.com/devtron-labs/devtron/util/argo/ArgoUserService.go:115\ngithub.com/devtron-labs/devtron/pkg/gitops.(*GitOpsConfigServiceImpl).ValidateAndCreateGitOpsConfig\n\t/go/src/github.com/devtron-labs/devtron/pkg/gitops/GitOpsConfigService.go:132\ngithub.com/devtron-labs/devtron/api/restHandler.GitOpsConfigRestHandlerImpl.CreateGitOpsConfig\n\t/go/src/github.com/devtron-labs/devtron/api/restHandler/GitOpsConfigRestHandler.go:102\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/devtron-labs/common-lib/middlewares.Recovery.func1\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/devtron-labs/common-lib/middlewares/recovery.go:26\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/devtron-labs/devtron/internal/middleware.PrometheusMiddleware.func1\n\t/go/src/github.com/devtron-labs/devtron/internal/middleware/instrument.go:132\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/devtron-labs/devtron/api/util.LoggingMiddlewareImpl.LoggingMiddleware.func1\n\t/go/src/github.com/devtron-labs/devtron/api/util/logger.go:66\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/gorilla/mux.(*Router).ServeHTTP\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/gorilla/mux/mux.go:210\ngithub.com/devtron-labs/authenticator/middleware.Authorizer.func1.1\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/devtron-labs/authenticator/middleware/AuthMiddleware.go:71\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\nnet/http.serverHandler.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2936\nnet/http.(*conn).serve\n\t/usr/local/go/src/net/http/server.go:1995"} [Feb 16 2024 12:49:24 GMT+0530] devtron-68566796c8-5l4k9: {"level":"debug","ts":1708067964.6608114,"caller":"gitops/GitOpsConfigService.go:176","msg":"gitops create request","req":{"provider":"GITLAB","username":"john@doe.com","token":"*******","gitLabGroupId":"70435","gitHubOrgId":"","host":"https://gitlab.com/","active":true,"azureProjectName":"","bitBucketWorkspaceId":"","bitBucketProjectKey":"","gitRepoName":"devtron-sample-repo-dryrun-dxx16o","userEmailId":"devtron-bot@devtron.ai","description":""}} [Feb 16 2024 12:49:24 GMT+0530] devtron-68566796c8-5l4k9: {"level":"debug","ts":1708067964.662436,"caller":"k8s/K8sUtil.go:694","msg":"getting k8s rest config"} [Feb 16 2024 12:49:26 GMT+0530] devtron-68566796c8-5l4k9: {"level":"error","ts":1708067966.9167428,"caller":"gitops/GitOpsConfigService.go:341","msg":"Error while upserting cluster in acd","clusterName":"default_cluster","err":"rpc error: code = Unavailable desc = connection error: desc = \"transport: authentication handshake failed: tls: failed to verify certificate: x509: certificate signed by unknown authority\"","stacktrace":"github.com/devtron-labs/devtron/pkg/gitops.(*GitOpsConfigServiceImpl).CreateGitOpsConfig\n\t/go/src/github.com/devtron-labs/devtron/pkg/gitops/GitOpsConfigService.go:341\ngithub.com/devtron-labs/devtron/pkg/gitops.(*GitOpsConfigServiceImpl).ValidateAndCreateGitOpsConfig\n\t/go/src/github.com/devtron-labs/devtron/pkg/gitops/GitOpsConfigService.go:134\ngithub.com/devtron-labs/devtron/api/restHandler.GitOpsConfigRestHandlerImpl.CreateGitOpsConfig\n\t/go/src/github.com/devtron-labs/devtron/api/restHandler/GitOpsConfigRestHandler.go:102\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/devtron-labs/common-lib/middlewares.Recovery.func1\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/devtron-labs/common-lib/middlewares/recovery.go:26\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/devtron-labs/devtron/internal/middleware.PrometheusMiddleware.func1\n\t/go/src/github.com/devtron-labs/devtron/internal/middleware/instrument.go:132\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/devtron-labs/devtron/api/util.LoggingMiddlewareImpl.LoggingMiddleware.func1\n\t/go/src/github.com/devtron-labs/devtron/api/util/logger.go:66\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/gorilla/mux.(*Router).ServeHTTP\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/gorilla/mux/mux.go:210\ngithub.com/devtron-labs/authenticator/middleware.Authorizer.func1.1\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/devtron-labs/authenticator/middleware/AuthMiddleware.go:71\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\nnet/http.serverHandler.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2936\nnet/http.(*conn).serve\n\t/usr/local/go/src/net/http/server.go:1995"} [Feb 16 2024 12:49:26 GMT+0530] devtron-68566796c8-5l4k9: {"level":"error","ts":1708067966.917075,"caller":"gitops/GitOpsConfigService.go:136","msg":"service err, SaveGitRepoConfig","err":"rpc error: code = Unavailable desc = connection error: desc = \"transport: authentication handshake failed: tls: failed to verify certificate: x509: certificate signed by unknown authority\"","payload":{"provider":"GITLAB","username":"john@doe.com","token":"******","gitLabGroupId":"70435","gitHubOrgId":"","host":"https://gitlab.com/testGroup","active":true,"azureProjectName":"","bitBucketWorkspaceId":"","bitBucketProjectKey":"","gitRepoName":"devtron-sample-repo-dryrun-dxx16o","userEmailId":"devtron-bot@devtron.ai","description":""},"stacktrace":"github.com/devtron-labs/devtron/pkg/gitops.(*GitOpsConfigServiceImpl).ValidateAndCreateGitOpsConfig\n\t/go/src/github.com/devtron-labs/devtron/pkg/gitops/GitOpsConfigService.go:136\ngithub.com/devtron-labs/devtron/api/restHandler.GitOpsConfigRestHandlerImpl.CreateGitOpsConfig\n\t/go/src/github.com/devtron-labs/devtron/api/restHandler/GitOpsConfigRestHandler.go:102\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/devtron-labs/common-lib/middlewares.Recovery.func1\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/devtron-labs/common-lib/middlewares/recovery.go:26\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/devtron-labs/devtron/internal/middleware.PrometheusMiddleware.func1\n\t/go/src/github.com/devtron-labs/devtron/internal/middleware/instrument.go:132\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/devtron-labs/devtron/api/util.LoggingMiddlewareImpl.LoggingMiddleware.func1\n\t/go/src/github.com/devtron-labs/devtron/api/util/logger.go:66\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/gorilla/mux.(*Router).ServeHTTP\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/gorilla/mux/mux.go:210\ngithub.com/devtron-labs/authenticator/middleware.Authorizer.func1.1\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/devtron-labs/authenticator/middleware/AuthMiddleware.go:71\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\nnet/http.serverHandler.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2936\nnet/http.(*conn).serve\n\t/usr/local/go/src/net/http/server.go:1995"} [Feb 16 2024 12:49:26 GMT+0530] devtron-68566796c8-5l4k9: {"level":"error","ts":1708067966.9171524,"caller":"restHandler/GitOpsConfigRestHandler.go:104","msg":"service err, SaveGitRepoConfig","err":"rpc error: code = Unavailable desc = connection error: desc = \"transport: authentication handshake failed: tls: failed to verify certificate: x509: certificate signed by unknown authority\"","payload":{"provider":"GITLAB","username":"john@doe.com","token":"******","gitLabGroupId":"70435","gitHubOrgId":"","host":"https://gitlab.com/testGroup","active":true,"azureProjectName":"","bitBucketWorkspaceId":"","bitBucketProjectKey":"","gitRepoName":"devtron-sample-repo-dryrun-dxx16o","userEmailId":"devtron-bot@devtron.ai","description":""},"stacktrace":"github.com/devtron-labs/devtron/api/restHandler.GitOpsConfigRestHandlerImpl.CreateGitOpsConfig\n\t/go/src/github.com/devtron-labs/devtron/api/restHandler/GitOpsConfigRestHandler.go:104\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/devtron-labs/common-lib/middlewares.Recovery.func1\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/devtron-labs/common-lib/middlewares/recovery.go:26\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/devtron-labs/devtron/internal/middleware.PrometheusMiddleware.func1\n\t/go/src/github.com/devtron-labs/devtron/internal/middleware/instrument.go:132\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/devtron-labs/devtron/api/util.LoggingMiddlewareImpl.LoggingMiddleware.func1\n\t/go/src/github.com/devtron-labs/devtron/api/util/logger.go:66\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\ngithub.com/gorilla/mux.(*Router).ServeHTTP\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/gorilla/mux/mux.go:210\ngithub.com/devtron-labs/authenticator/middleware.Authorizer.func1.1\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/devtron-labs/authenticator/middleware/AuthMiddleware.go:71\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2122\nnet/http.serverHandler.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2936\nnet/http.(*conn).serve\n\t/usr/local/go/src/net/http/server.go:1995"} [Feb 16 2024 12:49:26 GMT+0530] devtron-68566796c8-5l4k9: {"level":"info","ts":1708067966.9171932,"caller":"common/apiError.go:118","msg":"ERROR RES","TYPE":"API-ERROR","RES":500,"ERROR-MSG":[{"code":"000","internalMessage":"[{rpc error: code = Unavailable desc = connection error: desc = \"transport: authentication handshake failed: tls: failed to verify certificate: x509: certificate signed by unknown authority\"}]","userMessage":"rpc error: code = Unavailable desc = connection error: desc = \"transport: authentication handshake failed: tls: failed to verify certificate: x509: certificate signed by unknown authority\""}],"err":null} [Feb 16 2024 12:49:26 GMT+0530] devtron-68566796c8-5l4k9: 2024/02/16 07:19:26 http: superfluous response.WriteHeader call from github.com/devtron-labs/devtron/internal/middleware.(*responseWriterDelegator).WriteHeader (delegator.go:69) [Feb 16 2024 12:49:26 GMT+0530] devtron-68566796c8-5l4k9: 2024/02/16 07:19:26 AUDIT_LOG: urlPath: /orchestrator/gitops/config, queryParams: ,updatedBy: admin, updatedOn: 2024-02-16 07:19:13.349783695 +0000 UTC m=+125.115911002, apiResponseCode: 200,requestPayload: {"id":null,"provider":"GITLAB","username":"john@doe.com","host":"https://gitlab.com/","token":"******","gitLabGroupId":"70435","gitHubOrgId":"","azureProjectName":"","bitBucketWorkspaceId":"","bitBucketProjectKey":"","active":true}
☸ Kubernetes version
OKE v.1.28.2
Cloud provider

Oracle Cloud Infrastructure

🌍 Browser
Chrome
🧱 Your Environment
I use this as our internal developer platform.
✅ Proposed Solution
No fix found yet,
but the /validate api to configure gitops works.
👀 Have you spent some time to check if this issue has been raised before?

[X] I checked and didn't find any similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

AB#8584

Potential duplicates:

[#4668] Bug: Not getting errors on Devtron UI in case of GitOps (62.43%)

Potential duplicates:

[#4668] Bug: Not getting errors on Devtron UI in case of GitOps (62.43%)

Potential duplicates:

[#4668] Bug: Not getting errors on Devtron UI in case of GitOps (62.43%)

Potential duplicates:

[#4668] Bug: Not getting errors on Devtron UI in case of GitOps (62.43%)

I can confirm this is not duplicate of #4668

Unable to reproduce at our end. Is this resolved or still exist @Kaushiks4 @badal773 ?

Closing this due to inactivity, please feel free to reopen if this issue still exists

We are having the same issue.
Steps:

For us. It creates a dryrun private repo in the github organization then exits saying "internal server error"
devtron-sample-repo-dryrun-1lasg4 something like this. I assume devtron create a dummy repos to test the connectivity

We are having the same issue.
Steps:

I create an github organization and when configure gitops send error "internal server error"

error:

ideas?....
regards

I am configure gitops as well using bitbucket but getting the same error.
Anyone found a solution?

Is the gitops module installed? @romosa ?

Is the gitops module installed? @romosa ?

Hi @abhibhaw
I followed this instructions and added additional configurations for ingress and s3.
https://docs.devtron.ai/install/install-devtron-with-cicd
helm install devtron devtron/devtron-operator --create-namespace --namespace devtroncd \
--set installer.modules={cicd} \
--set configs.BLOB_STORAGE_PROVIDER=S3 \
--set configs.DEFAULT_CACHE_BUCKET=demo-s3-bucket \
--set configs.DEFAULT_CACHE_BUCKET_REGION=us-east-1 \
--set configs.DEFAULT_BUILD_LOGS_BUCKET=demo-s3-bucket \
--set configs.DEFAULT_CD_LOGS_BUCKET_REGION=us-east-1 \
--set secrets.BLOB_STORAGE_S3_ACCESS_KEY=ACCESS_KEY \
--set secrets.BLOB_STORAGE_S3_SECRET_KEY=SECRET_KEY \
--set components.devtron.ingress.enabled=true \
--set components.devtron.ingress.className=nginx \
--set components.devtron.ingress.host=devtron.devops.example.com \
--set components.devtron.ingress.annotations."nginx\.ingress\.kubernetes\.io\/app-root"="/dashboard" \
--set components.devtron.ingress.annotations."external-dns\.alpha\.kubernetes\.io\/hostname"="devtron.devops.example.com" \
--set components.devtron.ingress.annotations."cert-manager\.io\/cluster-issuer"="letsencrypt-prod" \
--set components.devtron.ingress.tls[0].secretName=devtron-tls \
--set components.devtron.ingress.tls[0].hosts[0]=devtron.devops.example.com

I'm also facing the same issue when using gitlab, /validate works but upon deployment of any chart it gives this error, though upon checking the repo it creates the respective chart under a new project/repo. Tried refreshing argocd certificates as well but that also doesn't work.
https://docs.devtron.ai/resources/devtron-troubleshoot#id-25.-refreshing-argocd-certificates-when-expired
[Nov 11 2024 17:04:24 GMT+0530] devtron-5784d949fb-phrns: {"level":"error","ts":1731324864.1663113,"caller":"common/deploymentConfigService.go:303","msg":"error in getting deployment config db object by appId and envId","appId":0,"envId":0,"err":"pg: no rows in result set","stacktrace":"github.com/devtron-labs/devtron/pkg/deployment/common.(*DeploymentConfigServiceImpl).GetConfigDBObj\n\t/go/src/github.com/devtron-labs/devtron/pkg/deployment/common/deploymentConfigService.go:303\ngithub.com/devtron-labs/devtron/pkg/deployment/common.(*DeploymentConfigServiceImpl).CreateOrUpdateConfig\n\t/go/src/github.com/devtron-labs/devtron/pkg/deployment/common/deploymentConfigService.go:64\ngithub.com/devtron-labs/devtron/pkg/appStore/installedApp/service.(*AppStoreDeploymentDBServiceImpl).AppStoreDeployOperationDB\n\t/go/src/github.com/devtron-labs/devtron/pkg/appStore/installedApp/service/AppStoreDeploymentDBService.go:212\ngithub.com/devtron-labs/devtron/pkg/appStore/installedApp/service.(*AppStoreDeploymentServiceImpl).InstallApp\n\t/go/src/github.com/devtron-labs/devtron/pkg/appStore/installedApp/service/AppStoreDeploymentService.go:142\ngithub.com/devtron-labs/devtron/api/appStore/deployment.AppStoreDeploymentRestHandlerImpl.InstallApp\n\t/go/src/github.com/devtron-labs/devtron/api/appStore/deployment/AppStoreDeploymentRestHandler.go:182\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2141\ngithub.com/devtron-labs/common-lib/middlewares.Recovery.func1\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/devtron-labs/common-lib/middlewares/recovery.go:52\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2141\ngithub.com/devtron-labs/devtron/internal/middleware.PrometheusMiddleware.func1\n\t/go/src/github.com/devtron-labs/devtron/internal/middleware/instrument.go:137\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2141\ngithub.com/devtron-labs/devtron/api/util.(*LoggingMiddlewareImpl).LoggingMiddleware.LoggingMiddlewareImpl.LoggingMiddleware.func1\n\t/go/src/github.com/devtron-labs/devtron/api/util/logger.go:84\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2141\ngithub.com/gorilla/mux.(*Router).ServeHTTP\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/gorilla/mux/mux.go:210\nmain.(*App).Start.(*App).Start.Authorizer.func1.func2\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/devtron-labs/authenticator/middleware/AuthMiddleware.go:91\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2141\nnet/http.serverHandler.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2943\nnet/http.(*conn).serve\n\t/usr/local/go/src/net/http/server.go:2014"} [Nov 11 2024 17:04:25 GMT+0530] devtron-5784d949fb-phrns: {"level":"info","ts":1731324865.0349934,"caller":"git/GitOpsHelper.go:167","msg":"total branch available in git repo","branch length":1} [Nov 11 2024 17:04:27 GMT+0530] devtron-5784d949fb-phrns: time="2024-11-11T11:34:27Z" level=info msg="Starting configmap/secret informers" [Nov 11 2024 17:04:27 GMT+0530] devtron-5784d949fb-phrns: time="2024-11-11T11:34:27Z" level=info msg="Configmap/secret informer synced" [Nov 11 2024 17:04:27 GMT+0530] devtron-5784d949fb-phrns: {"level":"error","ts":1731324867.9139314,"caller":"argocdServer/ArgoClientWrapperService.go:326","msg":"error in creating argo Repository","err":"rpc error: code = Unavailable desc = connection error: desc = \"transport: authentication handshake failed: tls: failed to verify certificate: x509: certificate signed by unknown authority\"","stacktrace":"github.com/devtron-labs/devtron/client/argocdServer.(*ArgoClientWrapperServiceImpl).createRepoInArgoCd\n\t/go/src/github.com/devtron-labs/devtron/client/argocdServer/ArgoClientWrapperService.go:326\ngithub.com/devtron-labs/devtron/client/argocdServer.(*ArgoClientWrapperServiceImpl).RegisterGitOpsRepoInArgoWithRetry.func1\n\t/go/src/github.com/devtron-labs/devtron/client/argocdServer/ArgoClientWrapperService.go:244\ngithub.com/devtron-labs/devtron/util/retryFunc.Retry\n\t/go/src/github.com/devtron-labs/devtron/util/retryFunc/RetryFunction.go:36\ngithub.com/devtron-labs/devtron/client/argocdServer.(*ArgoClientWrapperServiceImpl).RegisterGitOpsRepoInArgoWithRetry\n\t/go/src/github.com/devtron-labs/devtron/client/argocdServer/ArgoClientWrapperService.go:246\ngithub.com/devtron-labs/devtron/pkg/appStore/installedApp/service/FullMode/deployment.(*FullModeDeploymentServiceImpl).InstallApp\n\t/go/src/github.com/devtron-labs/devtron/pkg/appStore/installedApp/service/FullMode/deployment/FullModeDeploymentService.go:167\ngithub.com/devtron-labs/devtron/pkg/appStore/installedApp/service.(*AppStoreDeploymentServiceImpl).InstallApp\n\t/go/src/github.com/devtron-labs/devtron/pkg/appStore/installedApp/service/AppStoreDeploymentService.go:213\ngithub.com/devtron-labs/devtron/api/appStore/deployment.AppStoreDeploymentRestHandlerImpl.InstallApp\n\t/go/src/github.com/devtron-labs/devtron/api/appStore/deployment/AppStoreDeploymentRestHandler.go:182\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2141\ngithub.com/devtron-labs/common-lib/middlewares.Recovery.func1\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/devtron-labs/common-lib/middlewares/recovery.go:52\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2141\ngithub.com/devtron-labs/devtron/internal/middleware.PrometheusMiddleware.func1\n\t/go/src/github.com/devtron-labs/devtron/internal/middleware/instrument.go:137\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2141\ngithub.com/devtron-labs/devtron/api/util.(*LoggingMiddlewareImpl).LoggingMiddleware.LoggingMiddlewareImpl.LoggingMiddleware.func1\n\t/go/src/github.com/devtron-labs/devtron/api/util/logger.go:84\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2141\ngithub.com/gorilla/mux.(*Router).ServeHTTP\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/gorilla/mux/mux.go:210\nmain.(*App).Start.(*App).Start.Authorizer.func1.func2\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/devtron-labs/authenticator/middleware/AuthMiddleware.go:91\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2141\nnet/http.serverHandler.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2943\nnet/http.(*conn).serve\n\t/usr/local/go/src/net/http/server.go:2014"} [Nov 11 2024 17:04:27 GMT+0530] devtron-5784d949fb-phrns: {"level":"error","ts":1731324867.9140651,"caller":"argocdServer/ArgoClientWrapperService.go:252","msg":"error in registering GitOps repository","repoName":"https://<confidential>/devspace-projects/devtron-backup-es-v2.git","err":"rpc error: code = Unavailable desc = connection error: desc = \"transport: authentication handshake failed: tls: failed to verify certificate: x509: certificate signed by unknown authority\"","stacktrace":"github.com/devtron-labs/devtron/client/argocdServer.(*ArgoClientWrapperServiceImpl).RegisterGitOpsRepoInArgoWithRetry\n\t/go/src/github.com/devtron-labs/devtron/client/argocdServer/ArgoClientWrapperService.go:252\ngithub.com/devtron-labs/devtron/pkg/appStore/installedApp/service/FullMode/deployment.(*FullModeDeploymentServiceImpl).InstallApp\n\t/go/src/github.com/devtron-labs/devtron/pkg/appStore/installedApp/service/FullMode/deployment/FullModeDeploymentService.go:167\ngithub.com/devtron-labs/devtron/pkg/appStore/installedApp/service.(*AppStoreDeploymentServiceImpl).InstallApp\n\t/go/src/github.com/devtron-labs/devtron/pkg/appStore/installedApp/service/AppStoreDeploymentService.go:213\ngithub.com/devtron-labs/devtron/api/appStore/deployment.AppStoreDeploymentRestHandlerImpl.InstallApp\n\t/go/src/github.com/devtron-labs/devtron/api/appStore/deployment/AppStoreDeploymentRestHandler.go:182\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2141\ngithub.com/devtron-labs/common-lib/middlewares.Recovery.func1\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/devtron-labs/common-lib/middlewares/recovery.go:52\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2141\ngithub.com/devtron-labs/devtron/internal/middleware.PrometheusMiddleware.func1\n\t/go/src/github.com/devtron-labs/devtron/internal/middleware/instrument.go:137\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2141\ngithub.com/devtron-labs/devtron/api/util.(*LoggingMiddlewareImpl).LoggingMiddleware.LoggingMiddlewareImpl.LoggingMiddleware.func1\n\t/go/src/github.com/devtron-labs/devtron/api/util/logger.go:84\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2141\ngithub.com/gorilla/mux.(*Router).ServeHTTP\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/gorilla/mux/mux.go:210\nmain.(*App).Start.(*App).Start.Authorizer.func1.func2\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/devtron-labs/authenticator/middleware/AuthMiddleware.go:91\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2141\nnet/http.serverHandler.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2943\nnet/http.(*conn).serve\n\t/usr/local/go/src/net/http/server.go:2014"} [Nov 11 2024 17:04:27 GMT+0530] devtron-5784d949fb-phrns: /service-worker.js [Nov 11 2024 17:04:27 GMT+0530] devtron-5784d949fb-phrns: 2024/11/11 11:34:27 AUDIT_LOG: requestMethod: GET, urlPath: /dashboard/service-worker.js, queryParams: , updatedBy: admin, updatedOn: 2024-11-11 11:34:27.957166648 +0000 UTC m=+214.900389798, apiResponseCode: 200, requestPayload: [Nov 11 2024 17:04:28 GMT+0530] devtron-5784d949fb-phrns: {"level":"error","ts":1731324868.1274896,"caller":"argocdServer/ArgoClientWrapperService.go:326","msg":"error in creating argo Repository","err":"rpc error: code = Unavailable desc = connection error: desc = \"transport: authentication handshake failed: tls: failed to verify certificate: x509: certificate signed by unknown authority\"","stacktrace":"github.com/devtron-labs/devtron/client/argocdServer.(*ArgoClientWrapperServiceImpl).createRepoInArgoCd\n\t/go/src/github.com/devtron-labs/devtron/client/argocdServer/ArgoClientWrapperService.go:326\ngithub.com/devtron-labs/devtron/client/argocdServer.(*ArgoClientWrapperServiceImpl).handleArgoRepoCreationError\n\t/go/src/github.com/devtron-labs/devtron/client/argocdServer/ArgoClientWrapperService.go:357\ngithub.com/devtron-labs/devtron/client/argocdServer.(*ArgoClientWrapperServiceImpl).RegisterGitOpsRepoInArgoWithRetry\n\t/go/src/github.com/devtron-labs/devtron/client/argocdServer/ArgoClientWrapperService.go:253\ngithub.com/devtron-labs/devtron/pkg/appStore/installedApp/service/FullMode/deployment.(*FullModeDeploymentServiceImpl).InstallApp\n\t/go/src/github.com/devtron-labs/devtron/pkg/appStore/installedApp/service/FullMode/deployment/FullModeDeploymentService.go:167\ngithub.com/devtron-labs/devtron/pkg/appStore/installedApp/service.(*AppStoreDeploymentServiceImpl).InstallApp\n\t/go/src/github.com/devtron-labs/devtron/pkg/appStore/installedApp/service/AppStoreDeploymentService.go:213\ngithub.com/devtron-labs/devtron/api/appStore/deployment.AppStoreDeploymentRestHandlerImpl.InstallApp\n\t/go/src/github.com/devtron-labs/devtron/api/appStore/deployment/AppStoreDeploymentRestHandler.go:182\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2141\ngithub.com/devtron-labs/common-lib/middlewares.Recovery.func1\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/devtron-labs/common-lib/middlewares/recovery.go:52\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2141\ngithub.com/devtron-labs/devtron/internal/middleware.PrometheusMiddleware.func1\n\t/go/src/github.com/devtron-labs/devtron/internal/middleware/instrument.go:137\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2141\ngithub.com/devtron-labs/devtron/api/util.(*LoggingMiddlewareImpl).LoggingMiddleware.LoggingMiddlewareImpl.LoggingMiddleware.func1\n\t/go/src/github.com/devtron-labs/devtron/api/util/logger.go:84\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2141\ngithub.com/gorilla/mux.(*Router).ServeHTTP\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/gorilla/mux/mux.go:210\nmain.(*App).Start.(*App).Start.Authorizer.func1.func2\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/devtron-labs/authenticator/middleware/AuthMiddleware.go:91\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2141\nnet/http.serverHandler.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2943\nnet/http.(*conn).serve\n\t/usr/local/go/src/net/http/server.go:2014"} [Nov 11 2024 17:04:28 GMT+0530] devtron-5784d949fb-phrns: {"level":"error","ts":1731324868.1275816,"caller":"deployment/FullModeDeploymentService.go:169","msg":"error in argo registry","err":"rpc error: code = Unavailable desc = connection error: desc = \"transport: authentication handshake failed: tls: failed to verify certificate: x509: certificate signed by unknown authority\"","stacktrace":"github.com/devtron-labs/devtron/pkg/appStore/installedApp/service/FullMode/deployment.(*FullModeDeploymentServiceImpl).InstallApp\n\t/go/src/github.com/devtron-labs/devtron/pkg/appStore/installedApp/service/FullMode/deployment/FullModeDeploymentService.go:169\ngithub.com/devtron-labs/devtron/pkg/appStore/installedApp/service.(*AppStoreDeploymentServiceImpl).InstallApp\n\t/go/src/github.com/devtron-labs/devtron/pkg/appStore/installedApp/service/AppStoreDeploymentService.go:213\ngithub.com/devtron-labs/devtron/api/appStore/deployment.AppStoreDeploymentRestHandlerImpl.InstallApp\n\t/go/src/github.com/devtron-labs/devtron/api/appStore/deployment/AppStoreDeploymentRestHandler.go:182\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2141\ngithub.com/devtron-labs/common-lib/middlewares.Recovery.func1\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/devtron-labs/common-lib/middlewares/recovery.go:52\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2141\ngithub.com/devtron-labs/devtron/internal/middleware.PrometheusMiddleware.func1\n\t/go/src/github.com/devtron-labs/devtron/internal/middleware/instrument.go:137\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2141\ngithub.com/devtron-labs/devtron/api/util.(*LoggingMiddlewareImpl).LoggingMiddleware.LoggingMiddlewareImpl.LoggingMiddleware.func1\n\t/go/src/github.com/devtron-labs/devtron/api/util/logger.go:84\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2141\ngithub.com/gorilla/mux.(*Router).ServeHTTP\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/gorilla/mux/mux.go:210\nmain.(*App).Start.(*App).Start.Authorizer.func1.func2\n\t/go/src/github.com/devtron-labs/devtron/vendor/github.com/devtron-labs/authenticator/middleware/AuthMiddleware.go:91\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2141\nnet/http.serverHandler.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2943\nnet/http.(*conn).serve\n\t/usr/local/go/src/net/http/server.go:2014"} [Nov 11 2024 17:04:28 GMT+0530] devtron-5784d949fb-phrns: {"level":"error","ts":1731324868.128001,"caller":"deployment/AppStoreDeploymentRestHandler.go:187","msg":"service err, CreateInstalledApp","err":"rpc error: code = Unavailable desc = connection error: desc = \"transport: authentication handshake failed: tls: failed to verify certificate: x509: certificate signed by unknown authority\"","payload":{"id":10,"appId":21,"appName":"backup-es-v2","teamId":1,"environmentId":1,"installedAppId":10,"installedAppVersionId":10,"installedAppVersionHistoryId":10,"appStoreVersion":16109,"valuesOverrideYaml":"global:\n

Findings: when we were doing curl argocd-server.devtroncd there is some config issue in ndot or noproxy setup , so there is  connectivity issue  to argocd-server from devtron pod , after using fully qualified name the issue got resolved argocd-server.devtroncd.svc.cluster.local.
Other things that we tried was deploying same app via argo dashboard and it got deployed which points us in the direction that there is some connectivity issue from devtron pod to argo server
cc: @Shikhar-404

@romosa in your error logs below log is coming. You need to provide server.secretkey in argocd-secret
"msg":"error on get acd connection","err":"server.secretkey is missing",

GitOps add gitlab
caller":"connection/Connection.go:124","msg":"error on get acd connection","err":"server.secretkey is missing"
2024/12/10 10:45:12 DEVTRON_PANIC_RECOVERrecovered from panicerrruntime error: invalid memory address or nil pointer dereferencestackgoroutine 532224 [running]:

Can you share the names of pods in devtroncd namespace?

Can you share the names of pods in devtroncd namespace @cx2c? kubectl get po -n devtroncd

Seems like rthe argo-cd integration was not installed successfully as i can't see any argo related pods,
helm upgrade -n devtroncd devtron devtron/devtron-operator --reuse-values --set argo-cd.enabled=true --set security.enabled=true --set security.trivy.enabled=true you can use this helm command to enable the argo-cd integration, also the last two --set commands are for image-scanning.

Seems like rthe argo-cd integration was not installed successfully as i can't see any argo related pods, helm upgrade -n devtroncd devtron devtron/devtron-operator --reuse-values --set argo-cd.enabled=true --set security.enabled=true --set security.trivy.enabled=true you can use this helm command to enable the argo-cd integration, also the last two --set commands are for image-scanning.

installed by this step https://docs.devtron.ai/install/install-devtron-with-cicd
helm install devtron ./devtron-operator --create-namespace --namespace=devtroncd --set installer.modules={cicd}

After executing helm update, it seems like  it's working fine.

Hey @cx2c , this is a known bug in which due to certain race condition all modules gets marked as installed even if they were not specified in the helm install command , its already fixed and would be rolled out with the latest release.

Currently, does the deployment only support Helm? Does it support native Kubernetes YAML? Using Helm to orchestrate business services may not be ideal for our development.

yes we do support Kubernetes YAML here's doc for this https://docs.devtron.ai/usage/resource-browser#creating-resources

can i run the ci pod in another k8s cluster?

Yes we support running ci on different nodes based on taints and labels. https://docs.devtron.ai/configurations-overview/installation-configuration#configure-overrides you can add/change these key's value in the devtron-cm configmap.


resizale raygui icons

woukdnit it be neat tio resize rayguii ico=uns?

i would tend to agree

@Idiot64 GuiSetIconScale() was added recently.


Create a Monoids class

With Monoid analogs of the Semigroup instances defined in Semigroup

Merged in https://github.com/aol/cyclops-react/pull/339


2⃣ refactor(services: webhooks): migrate from fastify to @whatwg-node/server

related to #657 but doesn't close it entirely
@kamilkisiela How do I test this service(manually and programmatically) to make sure it's working correctly? I haven't seen a contribution guide to follow. All the tests are passing but that doesn't mean it's ready to be merged because webhooks package isn't tested

@ardatan just applied your suggestions from slack

:two:

Closing. This PR is outdated and we'll reconsider it later.


Documentation around configuration file?

I am trying to setup my statsd instance to write to influxdb and I cannot figure out how to do it. The example config assumes graphite will be used, and I can't find a single document on how to get statsd pointed at influxdb

Have you looked at https://github.com/etsy/statsd/blob/master/docs/backend.md & https://github.com/bernd/statsd-influxdb-backend?

This looks good. I went with Telegraf soon after I wrote this issue since it had easy support for InfluxDB. I will reopen this issue if needed.


[EventHubs] Nightly Test Run Integration for Samples

echoing https://github.com/Azure/azure-sdk-for-python/issues/10425 and #16045, specifically for EH:
Summary
In order to ensure that our samples are up-to-date and in good working order, they should be routinely validated by smoke testing them as part of the nightly test runs.
Scope of Work

Devise an approach to allow published samples to be smoke tested and run as part of the live test suite.

Validate the design with your language team, architect, and, if needed, the engineering team.

Perform any implementation or enhancements necessary to integrate the samples with the nightly test runs.

Success Criteria

The approach for nightly test run integration of samples has been validated with stakeholders and is consistent with the team's direction.

The published samples for the Event Hubs packages are smoke tested as part of the nightly test runs.

The published samples for the Event Hubs packages can be run as part of the live test suite by contributors.

Failures for the samples during the nightly test runs cause the run for that platform to fail; verification of the nightly results surfaces problems with the samples in the same manner that it does issues in the client library features.

already addressed in #16577


Update v1.6.md

Anchor to 'Build self contained, standalone binaries' was incorrect.

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

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


Problem with setuptools on Python3.12 not finding distutils (was: Self-updating with tufup.client)

Summary
Upon building a simple script that uses tufup.client, I get an error with the use of distutils (module not found).
Nuitka version
2.4.8
Commercial: None
Python: 3.12.3 (tags/v3.12.3:f6650f9, Apr  9 2024, 14:05:25) [MSC v.1938 64 bit (AMD64)]
Flavor: CPython Official
Executable: C:\Users\...\pyenv\Scripts\python.exe
OS: Windows
Arch: x86_64
WindowsRelease: 11
Version C compiler: ~\AppData\Local\Nuitka\Nuitka\Cache\DOWNLO~1\gcc\x86_64\13.2.0-16.0.6-11.0.1-msvcrt-r1\mingw64\bin\gcc.exe (gcc 13.2.0).

Nuitka installation
Nuitka has been installed in a virtual environment on Windows 11 in Python 12 with poetry (poetry add nuitka --dev).
pip is version 24.0. The following package has been installed:
Package            Version   Location                                           Installer
------------------ --------- -------------------------------------------------- ------------
tuf                4.0.0     C:\Users\...\pyenv\Lib\site-packages Poetry 1.8.2
tufup              0.9.0     C:\Users\...\pyenv\Lib\site-packages Poetry 1.8.2

nuitka does work and did work for this project until tufup was tested. I've isolated this issue in a very small script (see below).
To reproduce

Write a very small script:
# hello.py
from tufup.client import Client

Build it using python -m nuitka --standalone hello.py.

Go into the dist folder (cd hello.dist) and run it (hello.exe).

Output
(pyenv) C:\Users\...\hello.dist>hello.exe
Traceback (most recent call last):
  File "C:\Users\...\HELLO~1.DIS\hello.py", line 1, in <module>
  File "C:\Users\...\HELLO~1.DIS\tufup\__init__.py", line 4, in <module tufup>
  File "C:\Users\...\HELLO~1.DIS\tufup\repo\__init__.py", line 10, in <module tufup.repo>
  File "C:\Users\...\HELLO~1.DIS\setuptools\__init__.py", line 24, in <module>
  File "C:\Users\...\HELLO~1.DIS\setuptools\logging.py", line 5, in <module>
  File "C:\Users\...\HELLO~1.DIS\setuptools\monkey.py", line 13, in <module>
ModuleNotFoundError: No module named 'distutils'

Problem
I'm not 100% sure this is a problem with Nuitka itself. distutils has been deprecated, though it can still be installed as a third-party program. I would guess that Nuitka does not bundle distutils because it usually conflicts with its build process. But that's just a guess.
At this point, I would like to know if there's a solution to using tufup or if I should consider alternatives. Not that I found many.
Thank you for your answer,

This is having a hard time with bloat, and maybe, the issue you see is caused by attempted anti-bloat measures, where something is missing a guard to not remove distutils or so. I managed to reproduce it.
+- module-name: bsdiff4
+  anti-bloat:
+    - description: 'remove unittest reference'
+      change_function:
+        'test': 'un-callable'
+
+- module-name: tufup.repo
+  anti-bloat:
+    - description: 'need to use setuptools'
+      bloat-mode-overrides:
+        'unittest': 'allow'

With that config it's already nicer.

It seems, setuptools for 3.12, smuggles distutils back in and uses it for itself and exposes it globally too, so it's being found, despite not being found at compile time. For this, we got yaml configuration as well, that would appear to be important to have.

So, the _vendor directory, is newly exposed for setuptools >= 71, and we were not yet compatible with that, but that's added, however, distutils is hacked into things, based on its existence , and we probably need to special treat this, and allow forcing a finding of a specific module by an alias. We surely have something there somewhere that is similar.

I have tried a few forms of smuggling this in. I do think, it will be best if setuptools does make these modules "hard", i.e. they become pre-installed for the module location process, and then the whole module location process is avoided. This ought to be done for Python3.12 only of course, and only if setuptools is used, which should be rare, but sometimes is required, in fact for the tufp library there, I ignore listed it, and it's allowed to do that for simplicity, even though it's bloaty.

It's pretty tough to smuggle in distutils from there, without duplicating it, I had so far not really succeeded and I don't know how to make this in a compatible fashion really. It has been seen in other context, where anti-bloat is outdated or not applied as well, so this is really more blocking for other things, than I would like it to be, I need an idea here.

So, I did a lot of anti-bloat engine changes to setuptools in case of 3.12, that should do the trick, but it's ugly as hell of course.

Thanks for your report, this is fixed on the factory branch, which is a development version under rapid development. You can try it out by going here: https://nuitka.net/doc/factory.html
Feedback on whether this is working is very welcome. Please do not share plans to do it; only confirm or deny that it is working.

This is now part of the current pre-release and will be part of 2.5 release.

Part of the 2.5 release I just made.


⚠ Bofrost.be has degraded performance

In 54fdb98, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 2010 ms

Resolved: Bofrost.be performance has improved in f54bab5.


Unrooted Termux install process

What is the issue?
I am endeavouring to set up an ollama server on my unrooted Termux host environment, please refer:
https://github.com/ollama/ollama/issues/7349#issuecomment-2439776813
and
https://github.com/ollama/ollama/issues/7292#issuecomment-2439781839
@vpnry @dhiltgen So, the process is:
Process

git clone --depth 1 https://github.com/ollama/ollama.git

cd ollama

go generate ./...

delete the two lines of code, as per:

https://github.com/ollama/ollama/issues/7292#issuecomment-2427773036

and write.

go build .

./ollama serve &

and prosper!

Is that the go?
Device details:
❯ termux-info
Termux Variables:
TERMUX_API_VERSION=0.50.1
TERMUX_APK_RELEASE=F_DROID
TERMUX_APP_PACKAGE_MANAGER=apt
TERMUX_APP_PID=3465
TERMUX_IS_DEBUGGABLE_BUILD=0
TERMUX_MAIN_PACKAGE_FORMAT=debian
TERMUX_VERSION=0.118.1
TERMUX__USER_ID=0
Packages CPU architecture:
aarch64
Subscribed repositories:
# sources.list
deb https://packages-cf.termux.dev/apt/termux-main stable main
# sources.list.d/pointless.list
deb https://its-pointless.github.io/files/21 termux extras
# sources.list.d/ivam3-termux-packages.list
deb [trusted=yes arch=all] https://ivam3.github.io/termux-packages stable extras
# x11-repo (sources.list.d/x11.list)
deb https://packages-cf.termux.dev/apt/termux-x11 x11 main
# tur-repo (sources.list.d/tur.list)
deb https://tur.kcubeterm.com tur-packages tur tur-on-device tur-continuous
# root-repo (sources.list.d/root.list)
deb https://packages-cf.termux.dev/apt/termux-root root stable
# sources.list.d/rendiix.list
deb https://rendiix.github.io android-tools termux
Updatable packages:
command-not-found/stable 2.4.0-48 aarch64 [upgradable from: 2.4.0-47]
libgit2/stable 1.8.3 aarch64 [upgradable from: 1.8.2]
termux-tools version:
1.44.1
Android version:
14
Kernel build information:
Linux localhost 5.15.123-android13-8-28577532-abX910XXS4BXG5 #1 SMP PREEMPT Thu Jul 11 02:48:07 UTC 2024 aarch64 Android
Device manufacturer:
samsung
Device model:
SM-X910
LD Variables:
LD_LIBRARY_PATH=:/data/data/com.termux/files/home/.local/lib/ollama:/data/data/com.termux/files/usr/lib:/data/data/com.termux/files/home/install/lib
LD_PRELOAD=/data/data/com.termux/files/usr/lib/libtermux-exec.so
Installed termux plugins:
com.termux.widget versionCode:13
com.termux.x11 versionCode:14
com.termux.api versionCode:51
com.termux.window versionCode:15
com.termux.styling versionCode:1000

OS
Linux
GPU
Other
CPU
Other
Ollama version
No response

sorry whats the problem
is there one ?
or u just post info ?
https://github.com/ollama/ollama/issues/7292#issuecomment-2439815750

I want confirmation of the process to install on an unrooted aarch64 Termux please.

so , here another link i posted before ur question
https://github.com/ollama/ollama/issues/7349#issue-2612784172
.. why dont u just try ?

https://github.com/ollama/ollama/issues/7292#issuecomment-2439891479


Fix ci

A few things to note:

added mmcv-full dependency for deeplab (cc @Landanjs @A-Jacobson should I pin the version of that and mmseg?)
use our docker images so that I can get the vision image for deeplab tests
SAM appears to have a bug when run without grad scaling, skipping the test for now (@Landanjs is fixing in composer)
streaming seems to have a bug. haven't totally root caused, but increasing the dataset size from 16 -> 128 resolves it for now. root cause is still being investigated.

Yeah, we can add more tests later that don't user our docker images (made a JIRA). Installing the vision stuff is a bit of a challenge, which is the reason I switched to using our images.

but increasing the dataset size from 16 -> 128 resolves it for now. root cause is still being investigated.

This is probably due to num_canonical_nodes defaulting to 128. If there are less than that many samples, then it's not possible to create 1 batch. Still not 100% sure if this is intended behavior by StreamingDataset.

but increasing the dataset size from 16 -> 128 resolves it for now. root cause is still being investigated.

This is probably due to num_canonical_nodes defaulting to 128. If there are less than that many samples, then it's not possible to create 1 batch. Still not 100% sure if this is intended behavior by StreamingDataset.

I didn't see any where in the bert code that it was defaulting to 128 though. Where is that happening?

Ah I think I was looking at an old version of the code but CI was running on a newer version. Sounds good.


Add support for bitvec 1.0.0

This PR updates the code to use bitvec 1.0.0 rather than 0.22.
The only breaking change to nom-bitvec is that BSlice no longer implements AsBytes, because I couldn't figure any way to clean pull a slice from a BitSlice.

I also added a From implementation, for BitSlice to BSlice for convienence.


Add a minimal but extensible indexer

Describe your changes
Adds the skeleton of a minimal but extensible indexer. The indexer consumes events from a source (raw event) database and writes to a destination database with compiled / processed tables. The indexer is a library that other binaries import and slot their indexes into.
The cometindex library is intended to be generic over any cometbft events.
The pindexer binary is for penumbra specifically and we can add all our own code to it.
This code needs to be cleaned up but the shape of the owl is present.
Checklist before requesting a review

[x] If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason:

New tool outside of consensus

Example:
cargo run --bin pindexer -- -s "postgresql://localhost:5432/testnet_raw?sslmode=disable" -d "postgresql://localhost:5432/testnet_compiled?sslmode=disable"

psql
testnet_compiled=# SELECT COUNT(*) FROM shielded_pool_fmd_clue_set;
 count
-------
 27198
(1 row)

testnet_compiled=# SELECT * FROM shielded_pool_fmd_clue_set LIMIT 5;
 id |                                                                 clue_bytes                                                                 |                              tx_hash
----+--------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------
  1 | \x10caf9cfe8554fcdbe15ed817bd24c2ac8cd5ee7aca4dfd0262149e5196e4a05dc64809bba86fc45fd4a43e3e19fb1a7055bdf24459762d44755a16976b36e0100000000 | \xcf47123f5180a041b7500871a1b7a7f21dd86cfe0d51e35d3aad7ea12f22a07c
  2 | \xa8384ea099f9b485955658faaa5be55070f55410d229f7511c94a1e0d778eb0be08a2d5cde1a1d472fc5ed9eb3d26f410ac0b0ef721f5f604b20f89d3cced10100000000 | \xcf47123f5180a041b7500871a1b7a7f21dd86cfe0d51e35d3aad7ea12f22a07c
  3 | \x6a123e795f69f6a1d9af4c9f1c9db560704570decb4b9897abd18097c016e001e1e95f0f50c597a11ca2b397c8a5e367744488c3d9a558b22c8eeb582e7c8a0100000000 | \x87adfcd7959c6409c863e05fa396230b27a28bc1ce9651a4b8f1cc064554a91b
  4 | \x5abd8f40e7bff719098cbb1d1f64893158e839fc531362de44877663494d3808df54394cf2d7be48c4a1d3b3e8695f7ad6dd461bfdf5beeaebee2e00ef23d00000000000 | \x87adfcd7959c6409c863e05fa396230b27a28bc1ce9651a4b8f1cc064554a91b
  5 | \xb67786a00010a6ddc3ccbd29fa293cc2d7b5810d28639a8f902a5ea8885835105cf5bcd1105d36c1b2ddbb3f4d78985c7c6b0ffb5fc4c7bf3074fd9e9a3a6c0200000000 | \x8aa895767b2121b60cfbea8566a98517435a33b2125d769f1a92e4982aac8f54
(5 rows)

cc @plaidfinch @philipjames44

i have implemented the changes outlined in the to-do list, and confirmed that polling works correctly by running this against a local devnet. pending CI, this should now be ready for a review!

closing in favor of #4610 :arrow_right:

reset the cometindex branch on my way out, with #4610 now open :saluting_face: