BE: Allow disabling GitHub release info #1108

stklcode · 2025-05-29T09:44:47Z

Breaking change? (if so, please describe the impact and migration path for existing application instances)

What changes did you make?

The application info object contains details about the latest version which is queried online from GitHub API. While this info can be useful, it raises warning when Kafbat UI is deployed in environments with restricted internet access.

Introduce a new property github.release.info.enabled (default: true) that can be set to false to disable release info and just display the currently running version/commit.

Is there anything you'd like reviewers to focus on?

The original feature was introduced in provectus/kafka-ui#3570

Apparently, the issue was already known during development (provectus/kafka-ui#3570 (review)):

We need a boolean property to make it possible to opt-out of such checks in air-gap environments.

Did I miss anything or was this point just ignored? Anyway with this PR now there it is.

How Has This Been Tested? (put an "x" (case-sensitive!) next to an item)

For manual testing, start the app with environment variable or property, e.g. GITHUB_RELEASE_INFO_ENABLED=false.

Checklist (put an "x" (case-sensitive!) next to all the items, otherwise the build will fail)

I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I have made corresponding changes to the documentation (e.g. ENVIRONMENT VARIABLES)
My changes generate no new warnings (e.g. Sonar is happy)
I have added tests that prove my fix is effective or that my feature works
New and existing unit tests pass locally with my changes
Any dependent changes have been merged

PR for documentation update: kafbat/ui-docs#56

github-actions

Hi stklcode! 👋

Welcome, and thank you for opening your first PR in the repo!

Please wait for triaging by our maintainers.

Please take a look at our contributing guide.

Haarolean

Hi, thanks for the PR. I've left some inline comments, PTAL!

Haarolean · 2025-05-29T10:25:17Z

api/src/main/java/io/kafbat/ui/service/ApplicationInfoService.java

+    if (githubInfoEnabled) {
+      this.githubReleaseInfo = new GithubReleaseInfo(githubApiMaxWaitTime);
+    } else {
+      this.githubReleaseInfo = null;


let's either mark the field as nullable or replace it with some empty object instead to prevent NPEs

Let's also output a bold warning into logs on startup in case this is disabled that running outdated versions is dangerous due to CVEs and we will not provide support for outdated versions per our security policy

Let's also output a bold warning into logs on startup ...

A real "warning", i.e. WARN log level? INFO ... OK, but warning seems little overdone. I'm running about 400 instances in various test clusters and remote systems, no online access, updates and security scans are done by external tooling. Simply shifting Firewall/eBPF warnings to application warnings was not what I had in mind....

It might seem "overdone" until folks start coming up with air-gapped installations requesting support for 2 yo releases.

I get the point. But does a warning really prevent these folks from requesting anything? My experience is you can write "UNMAINTEINED" in 50px bold at the top of a GH issue template and you still get new tickets with the warning not even removed 🤷‍♂️

Nevertheless I've added a log warning. (yet another one to ignore, but at least consistent with other config scenarios).

WARN [restartedMain] i.k.u.s.ApplicationInfoService: Check for latest release is disabled. Note that old versions are not supported, please make sure that your system is up to date.

yet another one to ignore

do you export them to some external systems like sentry or something?

Yes, quite a few deployments on K8s where pod's logs are scraped and some generic checks for warnings and errors.

Not really a big deal.
Mostly dev/qa stuff where this is non-critical and for the remaining staging/prod-like namespaces there are filters in the deployment templates - almost impossible to run every third-party tool 100% warning-free in every environment, but normal under normal conditions we don't want any warning without actual impact. So just accept some "unfixable" ones (like version checks in an offline environment) explicitly and move on.

api/src/main/java/io/kafbat/ui/service/ApplicationInfoService.java

api/src/main/java/io/kafbat/ui/util/GithubReleaseInfo.java

Haarolean · 2025-05-29T10:28:18Z

frontend/src/components/Version/Version.tsx

@@ -19,7 +19,7 @@ const Version: React.FC = () => {

  return (
    <S.Wrapper>
-      {!isLatestRelease && (
+      {isLatestRelease === false && (


I'd like to see a visual difference between "no latest release present" and "user disabled version check" in the UI. This is crucial as it's often only the UI screenshots I have to deduct things from.

Any suggestion how such information should look?

Frankly, I don't see any benefit in such information. Currently running version is displayed, if the check failed there's a warning symbol and the information if there's an update available or not can change 1 second after a screenshot was taken, because it's dynamic info.

Perhaps a red (rather than yellow) exclamation mark icon (most likely it's an svg, so altering stroke-color should work) with a different text about version check disabled.
The benefit is offloading responsibility of running an oudated and possibly CVE-"enriched" version and giving the maintainers visual signal of what the user's running (red icon -> no version check = most likely outdated -> no support)

A red warning, really?

I've learned to ignore the yellow icon due do failing version checks and yet there are frequent questions if there's something wrong. So annoying users, who have no control whatsoever about the deployed version in our case, with read warning sign that typically means "something is wrong here" ...

Our use case are - you guessed it - isolated systems, mostly dev/staging environments. We allow users some access to the underlying Kafka and deployment/updates are done by some automation/opt team who don't see the UI warnings anyway.

We were looking for a solution to remove the frontend warning, not making it look worse.

You wouldn't imagine the number of issues I've seen where people come with their "up-to-date" installations, only to realize after wasting some time that it's not only an outdated version, but also a fork with completely unrelated functionality that we don't even have. Not sure of a middle ground here. @germanosin thoughts?

On the oder end, I've seen questions from users about the warning of "UNKNOWN" version and regular tickets from ops about log warnings that nobody can do anything about.

We have filters on our network logs to prevent alerting from unauthorized access attempts and injected a logging config to suppress the "Authentication is disabled" warning for instances running behind an external auth gateway. But we cannot filter the human eye and regular "just ignore the warning" is not really a satisfactory answer.

Evaluated red and gray symbol (current yellow and none for reference). My preference is "none" or maybe gray 😉

My personal preference: gray

I extended the <WarningIcon> component to (a) use theme's warningIcon color instead of hardcoded color (was #F2C94C, now #FFDD57 ... close enough for me) and (b) allow override by parameter.

Override to infoIcon color (#ABB5BA) with adjusted message in case the check info is not available.

I think we could hide the whole icon tbh. Even if the person reporting issues is not the same as the one managing the installation, they can still check if the version is up to date by clicking the commit hash. Given the counterpoint by @stklcode about "users screaming due to an alert", it might be alright.
@germanosin thoughts?

The application info object contains details about the latest version which is queried online from GitHub API. While this info can be useful, it raises warning when Kafbat UI is deployed in environments with restricted internet access. Introduce a new property "github.release.info.enabled" (default: true) that can be set to "false" to disable release info and just display the currently running version/commit.

Extend he WarningIcon template to allow custom coloring with fallback to theme's "warningIcon" color. If version check is disabled, show a corresponding info with a "infoIcon" (gray) colored icon instead.

Haarolean · 2025-06-25T10:30:24Z

api/src/main/java/io/kafbat/ui/service/ApplicationInfoService.java

+    if (githubInfoEnabled) {
+      this.githubReleaseInfo = new GithubReleaseInfo(githubApiMaxWaitTime);
+    } else {
+      this.githubReleaseInfo = null;


yet another one to ignore

do you export them to some external systems like sentry or something?

Haarolean · 2025-06-25T10:32:01Z

api/src/test/java/io/kafbat/ui/service/ApplicationInfoServiceTest.java

  @Test
  void testCustomGithubReleaseInfoTimeout() {
    assertEquals(100, service.githubReleaseInfo().getGithubApiMaxWaitTime());
  }
+
+  @Test
+  void testDisabledReleaseInfo() {


Thank you for adding the tests

Haarolean · 2025-06-25T10:39:55Z

frontend/src/components/Version/Version.tsx

@@ -19,7 +19,7 @@ const Version: React.FC = () => {

  return (
    <S.Wrapper>
-      {!isLatestRelease && (
+      {isLatestRelease === false && (


I think we could hide the whole icon tbh. Even if the person reporting issues is not the same as the one managing the installation, they can still check if the version is up to date by clicking the commit hash. Given the counterpoint by @stklcode about "users screaming due to an alert", it might be alright.
@germanosin thoughts?

stklcode requested review from a team as code owners May 29, 2025 09:44

kapybro bot added status/triage Issues pending maintainers triage status/triage/manual Manual triage in progress status/triage/completed Automatic triage completed and removed status/triage Issues pending maintainers triage labels May 29, 2025

github-actions bot reviewed May 29, 2025

View reviewed changes

Haarolean requested changes May 29, 2025

View reviewed changes

Haarolean added type/enhancement En enhancement/improvement to an already existing feature scope/backend Related to backend changes and removed status/triage/manual Manual triage in progress labels May 29, 2025

Haarolean changed the title ~~Allow disabling GitHub release info~~ BE: Allow disabling GitHub release info May 29, 2025

stklcode force-pushed the feat/disable-releaseinfo branch from f1f15de to 3c4131c Compare May 29, 2025 12:31

stklcode mentioned this pull request May 29, 2025

Document new and existing properties for GitHub release info kafbat/ui-docs#56

Open

stklcode force-pushed the feat/disable-releaseinfo branch from 3c4131c to bc55bce Compare May 29, 2025 13:04

Display a neutral warning icon if version check is disabled

c4f2562

Extend he WarningIcon template to allow custom coloring with fallback to theme's "warningIcon" color. If version check is disabled, show a corresponding info with a "infoIcon" (gray) colored icon instead.

stklcode force-pushed the feat/disable-releaseinfo branch from c3a87e3 to c4f2562 Compare May 29, 2025 16:43

Haarolean self-assigned this Jun 11, 2025

Haarolean self-requested a review June 11, 2025 10:04

Merge branch 'main' into feat/disable-releaseinfo

d6222de

Haarolean approved these changes Jun 25, 2025

View reviewed changes

Haarolean requested a review from a team June 25, 2025 10:40

Haarolean added the scope/frontend Related to frontend changes label Jun 25, 2025

Uh oh!

BE: Allow disabling GitHub release info #1108

Are you sure you want to change the base?

BE: Allow disabling GitHub release info #1108

Uh oh!

Conversation

stklcode commented May 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot left a comment

Choose a reason for hiding this comment

Uh oh!

Haarolean left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stklcode May 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

stklcode commented May 29, 2025 •

edited

Loading

stklcode May 29, 2025 •

edited

Loading