Skip to content

DEBUG setting not honoured #113

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
djjudas21 opened this issue Apr 15, 2024 · 15 comments
Closed

DEBUG setting not honoured #113

djjudas21 opened this issue Apr 15, 2024 · 15 comments
Labels
bug Something isn't working testing required verified This bug can be recreated

Comments

@djjudas21
Copy link
Contributor

I'm running Jump on Kubernetes and I noticed that debug mode remains enabled even when I set DEBUG: false. The debug bar remains in the corner. I tried different ways of quoting false and I even tried setting it to true, but I couldn't get rid of the debug bar. Pretty sure I didn't have this on v1.3.x.

This is my deployment: https://jump.gazeley.uk/ (it's a work in progress so I'm still using the default sites but I'm going to stop fiddling for tonight)

This is the config that's being passed to the container:

  Containers:
   jump:
    Image:      daledavies/jump:v1.4.0
    Port:       8080/TCP
    Host Port:  0/TCP
    Requests:
      cpu:      2m
      memory:   24Mi
    Liveness:   http-get http://:http/ delay=0s timeout=1s period=10s #success=1 #failure=3
    Readiness:  http-get http://:http/ delay=0s timeout=1s period=10s #success=1 #failure=3
    Environment:
      ALTLAYOUT:       false
      AMPMCLOCK:       true
      BGBLUR:          50
      BGBRIGHT:        90
      CACHEBYPASS:     false
      CHECKSTATUS:     false
      CUSTOMGREETING:  Some other greeting message
      CUSTOMWIDTH:     1000
      DEBUG:           false
      METRICTEMP:      true
      NOINDEX:         true
      SHOWCLOCK:       false
      SHOWGREETING:    false
      SHOWSEARCH:      true
      SITENAME:        Gazeley UK
      STATUSCACHE:     5
    Mounts:
      /backgrounds from backgrounds (rw)
      /favicon from favicon (rw)
      /search/searchengines.json from search-config (rw,path="searchengines.json")
      /sites/sites.json from sites-config (rw,path="sites.json")

https://jump.gazeley.uk/

@daledavies
Copy link
Owner

Hmm, thanks for raising the issue. This is a new feature with v1.4.0, I've not seen this happen before in testing though.

Let me take a look tomorrow.

@daledavies daledavies added the triage Currently trying to determine if this can be recreated label Apr 15, 2024
@daledavies
Copy link
Owner

daledavies commented Apr 15, 2024

Wondering if you could try deleting the contents of the cache directory?

@daledavies
Copy link
Owner

Also can you exec into the container and check if the DEBUG environment variable is definitely false?

You shouldn't have to specify it at all as the app sets debug to false internally if the environment variable isn't set.

@djjudas21
Copy link
Contributor Author

I'll do these actions tomorrow. If they don't fix it, I'd put money on it being the classic bug where a value of "false" appears to be true because it is a non-empty string 😄

@daledavies
Copy link
Owner

You know what it probably is! I've even written and used a method to parse booleans from the yaml...

public function parse_bool(mixed $input): mixed {

But looks like I've forgotten to use it here...

if (!$this->config->get('debug')) {

@djjudas21
Copy link
Contributor Author

I think you've found the smoking gun, but for the sake of completeness...

[jonathan@poseidon jump]$ kubectl exec -it jump-7d99fd5799-49jr5 -- bash
jump-7d99fd5799-49jr5:/var/www/html# echo $DEBUG
false

I also couldn't find a cache dir anywhere under /var/www/html, and haven't knowingly set or changed this anywhere.

@daledavies
Copy link
Owner

I've added the proper boolean check mentioned above, I'll create a new release later for it.

In terms of the cache, the default directory is... /var/www/cache. I'm assuming you're deploying the docker image from docker hub or building it using the supplied dockerfile?

@djjudas21
Copy link
Contributor Author

Yes I'm using the stock docker image. I found and deleted the application cache. It didn't fix the problem with debug mode, but it really upset the application until I restarted the container. Loads of errors about it trying to open files from the cache that I had deleted.

@daledavies
Copy link
Owner

I've just added a few changes to the cache directory to stop this from happening again, will add to new release with the patch to fix debug.

@daledavies
Copy link
Owner

I'll also update the readme to clarify what exactly the default values are, as it really wasn't very clear on reflection.

@djjudas21
Copy link
Contributor Author

You mean to tell me that it's an open source project with ambiguous or missing documentation?? That never happens!

Seriously though, I appreciate your effort tracking down and fixing these bugs 🙂

@daledavies
Copy link
Owner

I've seen worse with a lot of closed source applications! But honestly writing good documentation is difficult and probably the least enjoyable part of maintaining a software project for other people to use.

I'm still over the moon knowing that anyone other than me uses Jump though it's truly awesome! 😁

@daledavies daledavies added bug Something isn't working verified This bug can be recreated testing required and removed triage Currently trying to determine if this can be recreated labels Apr 16, 2024
@daledavies
Copy link
Owner

I've created release v1.4.1, pushed to docker hub, if you pull the latest or v1.4.1 tags you'll get it.

@djjudas21
Copy link
Contributor Author

Can confirm this is fixed in v1.4.1 🏆

@daledavies
Copy link
Owner

Amazing, thank you so much for reaching out. All the best 😁

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working testing required verified This bug can be recreated
Projects
None yet
Development

No branches or pull requests

2 participants