config for disabling the `beta_job` block or delaying on startup

[malud]

The beta_job does run on startup no matter how big the interval has been set. However, it may be required to disable a job via environment variable for some reason. A workaround could have been a huge interval which actually does not work with our startup run. So the proposal here would be to introduce a disable bool attribute which could be set to true if required.

Thoughts: how about to add an additional attribute which prevents the startup run?

e.g.:

definitions {
  beta_job "update_data" {
    # new
    disable = default(env.DISABLE_UPDATE_JOB, false)
    # or with "delay"
    interval = "1h"
    start_after_interval = true
    request "origin" {
      url = "http://my-service/api/v1/exports/data"
    }
  }
}

/cc @filex

[filex]

Would it be more straight forward to have an enable flag instead of disable?

[malud]

its about the default behaviour which should still be enabled? So the best default boolean is a false one.

[alex-schneider]

https://github.com/alex-schneider/cron :)

[filex]

Gophers like to use false​ as the default value for Booleans :) But I would dare to have true as the default for an enabled flag.

Do we have enable(d)/disable(d) in other parts of the configuration? There is disable_access_control, which we justified with being an exception. Disabling a job is also an exception.

---

Von: Alex Schneider @.> Gesendet: Monday, April 24, 2023 5:12:30 PM An: avenga/couper @.> Cc: Felix Hassert @.>; Mention @.> Betreff: Re: [avenga/couper] config for disabling the beta_job block or delaying on startup (Issue #726)

https://github.com/alex-schneider/cron :)

— Reply to this email directly, view it on GitHubhttps://github.com/avenga/couper/issues/726#issuecomment-1520367090, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAD3OQSDHB2XKCYDFTPL2B3XC2J55ANCNFSM6AAAAAAVGX26L4. You are receiving this because you were mentioned.Message ID: @.***>