These release notes are for Zenhub Enterprise for Virtual Machine and Zenhub Enterprise for Kubernetes.

• For all users using Zenhub on github.com, please check out our new feature announcements on our product changelog.
• For administrators planning upgrades, please refer to the "Important Upgrade Instructions for Administrators" section.

GitHub Enterprise Server compatibility

Zenhub Enterprise 4.4.2 supports GitHub Enterprise versions: 3.14, 3.15, 3.16, and 3.17

What's new in Zenhub Enterprise 4.4.2

🐞 Bug Fixes and Changes

• Work Tracker
  • Added the ability to sort board pipelines by "Time spent in pipeline" and view this value for each issue in the pipeline
  • Added the ability for users to modify the default "assumed estimate" value for their workspaces
  • Creating new workspaces no longer automatically creates a new "Epics" pipeline
  • Users can now override the default end time and timezone for Zenhub sprints
  • Optimized how quickly Zenhub syncs GitHub repository updates by prioritizing most recently accessed repositories first
  • Optimized GitHub token usage to reduce the delay between when GitHub PRs are linked to issues and when this connection appears on the Zenhub board
  • Optimized the rendering performance of the GitHub issue page inside the Zenhub app
  • Improved the reliability and auditability of workspace creation for large GitHub issue repositories (5000+ issues)
  • Performing label and issues text searches will now match via partial string matches (rather than semantic matches)
  • Improved support for Japanese IME inputs for pipeline issue creation
  • Hovering over timestamps in the issue timeline history will now show the full timestamp in a tooltip
  • Fixed a bug causing some ".json" file uploads to be rejected when uploading files via the Zenhub webapp
  • Fixed a bug which would cause GitHub issue imports to fail if a GitHub issue comment was missing a valid author
  • Fixed a bug which would prevent issues from being searched across filtered workspaces when creating dependencies
  • Fixed a bug which cause sprint creation failures when using the auto-move automation
  • Fixed a bug where an onboarding tooltip would sometimes flash on the screen briefly
  • Fixed a bug where some users would not see all their GitHub organizations when attempting to add repositories from different GitHub organizations to their workspace
  • Fixed a bug which sometimes redirected users to the wrong workspace after accepting an invitation
  • Fixed a bug where cross-repository issue references would not properly link to the correct issue (in the issue timeline history)
  • Fixed a bug which caused some pipelines to fail to load due to a 500 error
  • Fixed errors which could appear if dragging linked PRs within the same pipeline
• Extension
  • Redesigned the workspace switcher in the breadcrumb navigation menu to be more reliable and consistent (specifically fixing some GHE 3.16+ compatibility issues)
  • Clicking on Pull Request links will now always open the PR in a new tab
  • Fixed a bug where the Chrome extension's dropdown menu would sometimes show a blank white screen
  • Fixed a bug which caused an extra scroll bar to appear for GitHub Enterprise admin users
  • Fixed a bug which would redirect extension users to an invalid workspace if their latest workspace had no repositories
  • Fixed a bug where cmd+clicking on issue links would sometimes open two tabs
  • Fixed a GHE 3.17+ compatibility issue which caused laggy performance when typing into issue and comment fields
  • Fixed a GHE 3.17+ compatibility issue which caused GitHub's dropdown menus to appear underneath the Zenhub overlays
  • Fixed a GHE 3.17+ compatibility issue which caused the "Zenhub" tab to not always fill the full height of the page
  • Fixed a GHE 3.18+ compatibility issue which caused issue sidebar elements to sometimes show a blank space
• Daily Standup
  • Fixed a text formatting bug for users with active tasks in the "Today" section
  • Fixed a bug which sometimes caused extra scrollbars to appear for large teams
• Sprint Review
  • Fixed a bug which caused unfinished sprint issues to not properly respect workspace label filters
  • Fixed a bug which would sometimes show "Your next Sprint Review will be generated on __" unnecessarily
• Roadmap
  • Fixed a bug which caused the Roadmap to sometimes crash when it is empty
• Release Burnup Report
  • Optimized the data loading layer to support releases with more than 1000 issues more consistently
• Settings
  • User can now review and delete Zenhub Labels from the settings page
• On Premise
  • Enterprise usage reports now include Zenhub usernames/emails and exclude users who have requested seats but do not have approved seats
  • Fixed a bug which sometimes caused Zenhub issues to fail to be created when an external database outage occurred
  • Fixed a bug which caused Zenhub organization administrators to lose administrative privileges if they accepted an invitation from another Zenhub user
  • Added support for MongoDB 7
  • Removed support for the deprecated W3ID authentication provider
• GraphQL API
  • Optimized the Zenhub issue creation GraphQL API command to include labels and assignees assignment in one operation
  • Added early access support for fetching GitHub issue types via the GraphQL API (requires GHE 3.18+)
  • Added the missing ability to order issues by "Updated At" date when fetching via the searchIssuesByPipeline query
  • The searchClosedIssues query will now properly return a 404 error if no matches are found
• Security
  • Zenhub now requests the "read:org" GitHub OAuth scope for new user sessions (existing user sessions are not impacted)
  • Zenhub now more aggressively revokes stale authentication tokens on logout
  • Zenhub now more accurately respects the "Maintain" GitHub permission/role
  • Fixed a user enumeration vulnerability when fetching Zenhub users via the internal API
  • Applied several critical & high severity security patches for third-party dependencies
  • More clearly indicate to users when they've hit the password reset rate limit

Known Issues

• zhe-config --chrony-ntp does not properly configure a custom NTP endpoint

VM Embedded Component Versions

Important Upgrade Instructions for Administrators

Zenhub Enterprise for Virtual Machine

• You must be running 4.2.x, 4.3.x, or 4.4.0 to perform the upgrade to ZHE 4.4.2
• For users currently running Zenhub Enterprise, contact our team for a download link for the upgrade package. The upgrade process is detailed in our documentation.

Important News for Administrators

1. You can now customize Postgres parameters and resource allocation. Please refer to the following readme to find out how to do so.
2. You can now perform a Fail2Ban basic configuration by running zhe-confg --fail2ban. Please refer to 3.3 Configure Zenhub here to view the configurable parameters.
3. We now provide support for resuming from a failing upgrade. You can read more about it here.
4. We fixed a bug where reloading the Zenhub application using zhe-config --reload didn't properly reflect the configurations in configuration.yaml. This has been fixed.

Zenhub Enterprise for Kubernetes

⚠️ NOTE: The minimum version of Kubernetes required to run ZHE 4.4 is now v1.32.

1. Prepare

• Get the kustomization.yaml you configured to setup Zenhub
• Perform a diff to make sure no outstanding changes are waiting to be applied

kustomize build . | kubectl diff -f-

It should exit 0 and only display a warning of unused variables. If changes are pending, apply them before starting the upgrade process.

• Make a copy of your existing kustomization.yaml and keep it handy for the next step

2. Update kustomization.yaml

• Check out the zenhub-enterprise repository at the tag of this release
• Populate the new kustomization.yaml with your existing configuration values

Be sure to replace any additional customized configuration (such as ingress, TLS configuration) with your original configuration from before as well.

• In ZHE 4.0 and onwards, secret_key_base is required to be a 42 byte string, any existing 38 byte string should be updated as described in kustomization.yaml
• If you are using your own registry and not Zenhub's registry, upload the new images tagged with this release to your registry.

3. Run configmap-generator.sh

Once you have setup all the configurations in your copy of kustomization.yaml and are ready to deploy to your cluster, you must run the configmap-generator.sh script that will fill placeholders in our Kubernetes manifests with your configuration values.

To run the script, navigate to the root of the directory containing your kustomization.yaml file, which also contains the configmap-generator.sh script. Then, run the script with these two commands:

chmod 700 configmap-generator.sh
./...

These release notes are for Zenhub Enterprise for Virtual Machine and Zenhub Enterprise for Kubernetes.

• For all users using Zenhub on github.com, please check out our new feature announcements on our product changelog.
• For administrators planning upgrades, please refer to the "Important Upgrade Instructions for Administrators" section.

GitHub Enterprise Server compatibility

Zenhub Enterprise 4.4.1 supports GitHub Enterprise versions: 3.14, 3.15, 3.16, and 3.17

What's new in Zenhub Enterprise 4.4.1

🐞 Bug Fixes and Changes

• The "Age in pipeline" badge on issue cards now shows the number of days
• Fixed a performance issue in the extension when typing text into Zenhub flyover elements
• Fixed a bug where the extension would sometimes inject blank empty spaces when navigating from one issue to another
• Fixed a bug where Ctrl+clicking on links in the extension inside the Zenhub tab would not open the links in a new browser tab
• Fixed a bug where Zenhub sidebar elements would be removed for extension users who toggled markdown checkboxes in the issue body

Known Issues

• zhe-config --chrony-ntp does not properly configure a custom NTP endpoint

VM Embedded Component Versions

Important Upgrade Instructions for Administrators

Zenhub Enterprise for Virtual Machine

• You must be running 4.2.x, 4.3.x, or 4.4.0 to perform the upgrade to ZHE 4.4.1
• For users currently running Zenhub Enterprise, contact our team for a download link for the upgrade package. The upgrade process is detailed in our documentation.

Important News for Administrators

1. You can now customize Postgres parameters and resource allocation. Please refer to the following readme to find out how to do so.
2. You can now perform a Fail2Ban basic configuration by running zhe-confg --fail2ban. Please refer to 3.3 Configure Zenhub here to view the configurable parameters.
3. We now provide support for resuming from a failing upgrade. You can read more about it here.
4. We fixed a bug where reloading the Zenhub application using zhe-config --reload didn't properly reflect the configurations in configuration.yaml. This has been fixed.

Zenhub Enterprise for Kubernetes

⚠️ NOTE: The minimum version of Kubernetes required to run ZHE 4.4 is now v1.32.

1. Prepare

• Get the kustomization.yaml you configured to setup Zenhub
• Perform a diff to make sure no outstanding changes are waiting to be applied

kustomize build . | kubectl diff -f-

It should exit 0 and only display a warning of unused variables. If changes are pending, apply them before starting the upgrade process.

• Make a copy of your existing kustomization.yaml and keep it handy for the next step

2. Update kustomization.yaml

• Check out the zenhub-enterprise repository at the tag of this release
• Populate the new kustomization.yaml with your existing configuration values

Be sure to replace any additional customized configuration (such as ingress, TLS configuration) with your original configuration from before as well.

• In ZHE 4.0 and onwards, secret_key_base is required to be a 42 byte string, any existing 38 byte string should be updated as described in kustomization.yaml
• If you are using your own registry and not Zenhub's registry, upload the new images tagged with this release to your registry.

3. Run configmap-generator.sh

Once you have setup all the configurations in your copy of kustomization.yaml and are ready to deploy to your cluster, you must run the configmap-generator.sh script that will fill placeholders in our Kubernetes manifests with your configuration values.

To run the script, navigate to the root of the directory containing your kustomization.yaml file, which also contains the configmap-generator.sh script. Then, run the script with these two commands:

chmod 700 configmap-generator.sh
./configmap-generator.sh

4. Application updates

In your new kustomization.yaml, confirm that the cluster image tags are set to the new images for this release:

If you are using your own registry, ensure that the newName fields are configured for that instead of Zenhub's

images:
  - name: kraken-webapp
    newName: us.gcr.io/zenhub-public/kraken-webapp
    newTag: zhe-4.4.1
  - name: kraken-extension
    newName: us.gcr.io/zenhub-public/kraken-extension
    newTag: zhe-4.4.1
  - name: kraken-zhe-admin
    newName: us.gcr.io/zenhub-public/kraken-zhe-admin
    newTag: zhe-4.4.1
  - name: raptor-backend
    newName: us.gcr.io/zenhub-public/raptor-backend
    newTag: zhe-4.4.1
  - name: toad-backend
    newName: us.gcr.io/zenhub-public/toad-backend
    newTag: zhe-4.4.1
  - name: sanitycheck
    newName: us.gcr.io/zenhub-public/sanitycheck
    newTag: zhe-4.4.1
  - name: devsite
    newName: us.gcr.io/zenhub-public/devsite
    newTag: zhe-4.4.1
  - name: busybox
    newName: docker.io/library/busybox
    newTag: latest
  - name: nginx
    newName: docker.io/library/nginx
    newTag: latest

• First, delete any raptor-db-migrate and sanitycheck jobs so they may be recreated without errors:

Make sure the status of the jobs are Complete and not Running

kubectl -n <your_dedicated_namespace> delete job/raptor-db-migrate job/sanitycheck

• Then perform a diff to check what the upgrade will do (this command must be run from the directory that contains your kustomization.yaml

kustomize build . | kubectl diff -f-

• If everything looks correct and there are no errors, you can deploy to the cluster via:

kustomize build . | kubectl apply -f-

7. Finalize

• Securely store the updated kustomization.yaml

These release notes are for Zenhub Enterprise for Virtual Machine and Zenhub Enterprise for Kubernetes.

• For all users using Zenhub on github.com, please check out our new feature announcements on our product changelog.
• For administrators planning upgrades, please refer to the "Important Upgrade Instructions for Administrators" section.

GitHub Enterprise Server compatibility

Zenhub Enterprise 4.4.0 supports GitHub Enterprise versions: 3.14, 3.15, and 3.16

What's new in Zenhub Enterprise 4.4.0

We are thrilled to announce the release of Zenhub Enterprise 4.4.0 which contains a range of changes and security updates. Additionally, this release has been tested against the newly released Github Enterprise Server 3.16.0 and is compatible.

🚀 New and Updated Features

Issue Cards Redesign

We're kicking off 2025 with an exciting visual refresh of our issue cards, paving the way for our upcoming Work Breakdown System powered by Sub-issues. This isn't just a cosmetic update – it's a thoughtful redesign that puts productivity and user experience first.

Our redesigned issue cards bring several key improvements:

• Optimized space utilization for better information density
• Enhanced readability across all view modes
• More intuitive access to power-user features (pro tip: try bulk-selecting multiple issues!)
• Built-in support for Issue Types, Sub-issues, and Dependencies
• To Do / In Progress / Complete counts for cards with Sub-issues

Sidebar changes

We've renamed some of our Sidebar items to better describe what they do

• To prepare for additional views that will be coming, we've renamed "Board" to "Work Tracker"
• We moved the Roadmap up in the list
• We've renamed some of our reports to better describe what they do
  • Sprint Report → Sprint Burndown
  • Sprint Review → Sprint Summary
  • Velocity Tracking → Team Velocity
  • Milestone Report → Milestone Burndown
  • Control Chart → Lead / Cycle Time
  • Cumulative Flow → Bottleneck Tracking

Additionally, we've consolidated all settings items under the "Edit Workspace" dropdown

Daily Feed Changes

We've separated the Daily Feed into two distinct pages.

My Work
My Work gives you a streamlined view of all of the work assigned to you. You can pick which pipeline (status) of work to show.

Daily Standup
The "Team Feed" was always meant as a "Daily Standup" view, so that's what we've renamed it.

• Added the ability to shuffle the participant list for Daily Standups
• We've removed the tabs and streamlined what we show you
• We've removed the links and replaced them with metrics from "Today's Insights"
• You can pick which pipeline (status) of work to show

Sprint Burndown & Milestone Burndown

• We've removed the Insights & Recommendations panel as it was just too much on the screen at once - information overload! (we're taking a fresh look at how this can return)
• We've unified the layout of the reports
• We've streamlined how you filter these reports

Release Burnup Report Improvements

We've made several improvements to Release reports in the latest version:

• Releases with start dates in the future can now be loaded in the Release Burnup report. You won't be able to review progress towards the release (as it hasn't started yet) but you'll be able to see any issues added to the Release and its issue and story point totals.
• Fixed a bug where filtering the Release report by a label would not update the chart visualization with tracking progress for issue with that label
• Fixed a bug where selecting a Release would sometimes load the wrong Release

Improved Enterprise Management Features

• Added the ability to enable "Auto-reseat" Users from the "Manage your plan" page. If enabled, unseated users who previously had a license will be auto-assigned a seat (if licenses are available) upon their next login.
• Added the ability to export a CSV list of all seated users and their activity from the "Seats" page.
• Modified the "Usage Report" for ZHE admins to exclude users who have logged into Zenhub but have not been granted a valid license (NOTE: This change does not impact historical usage report number)

🐞 Bug Fixes

• Fixed a bug causing certain invitations not allowing users to join the target organization
• Fixed a bug which would fail to move issues when dragging & dropping issues with connected PRs on the board
• Fixed a bug where the Zenhub extension would not load reliably when navigating GitHub pages rapidly
• Fixed a bug where the Zenhub extension would sometimes duplicate content when navigating with browser Back/Forward buttons
• Fixed a bug where clicking on a video embed inside a Zenhub issue description would trigger edit mode rather than playing the video
• Fixed a bug closed epics would sometimes appear in the "Open" tab of the Epic selector dropdown
• Fixed a bug which caused extra scrollbars to appears for Zenhub extension users who were also GHE administrators

🔒 Security Fixes

• Package security updates
  • pgbouncer: docker.io/edoburu/pgbouncer:1.20.1-p0 -> docker.io/edoburu/pgbouncer:v1.23.1-p3
    • Updated OpenSSL Defaults
    • FIPS Compliance by utilizing OpenSSL for MD5 hash calculations when possible
  • redis: docker.io/bitnami/redis:7.0.12 -> docker.io/bitnami/redis:7.0.15
  • rabbitmq: docker.io/bitnami/rabbitmq:3.8.35 -> docker.io/bitnami/rabbitmq:3.12.14
  • golang: golang:1.19.13-bullseye -> golang:1.24.1-bullseye
    • Fixes CVE-2025-22870 and CVE-2024-45336
  • Kubernetes: v1.28.13 -> v1.32.1
    • Fixes CVE-2025-1974, CVE-2024-5321, CVE-2024-40635, and CVE-2025-0426
  • Postgresql: docker.io/bitnami/postgresql:15.3 -> docker.io/bitnami/postgresql:15.7
    • Fixes CVE-2025-1094 and CVE-2024-4317

Known Issues

• zhe-config --chrony-ntp does not properly configure a custom NTP endpoint

VM Embedded Component Versions

Important Upgrade Instructions for Administrators

Zenhub Enterprise for Virtual Machine

• You must be running 4.2.x or 4.3.x to perform the upgrade to ZHE 4.4.0
• For users currently running Zenhub Enterprise, contact our team for a download link for the upgrade package. The upgrade process is detailed in our documentation.

Important News for Administrators

1. You can now customize Postgres parameters and resource allocation. Please refer to the following readme to find out how to do so.
2. You can now perform a Fail2Ban basic configuration by running zhe-confg --fail2ban. Please refer to 3.3 Configure Zenhub here to view the configurable parameters.
3. We now provide support for resuming from a failing upgrade. You can read more about it here.
4. We fixed a bug where reloading the Zenhub application using zhe-config --reload didn't properly reflect the configurations in configuration.yaml. This has been fixed.

Zenhub Enterprise for Kubernetes

⚠️ NOTE: The minimum version of Kubernetes required to run ZHE 4.4 is now v1.32.

1. Prepare

• Get the kustomization.yaml you configured to setup Zenhub
• Perform a diff to make sure no outstanding changes are waiting to be applied

kustomize build . | kubectl diff -f-

It should exit 0 and only display a warning of unused variables. If changes are pending, apply them before starting the upgrade process.

• Make a copy of your existing kustomization.yaml and keep it handy for the next step

2. Update kustomization.yaml

• Check out the zenhub-enterprise repository at the tag of this release
• Populate the new kustomization.yaml with your existing configuration values

Be sure to replace any additional customized configuration (such as ingress, TLS configuration) with your original configuration from before as well.

• In ZHE 4.0 and onwards, secret_key_base is required to be a 42 byte string, any existing 38 byte string should be updated as described in kustomization.yaml
• If you are using your own registry and not Zenhub's registry, upload the new images tagged with this release to your registry.

3. Run configmap-generator.sh

Once you have setup all the configurations in your copy of kustomization.yaml and are ready to deploy to your cluster, you must run the configmap-generator.sh script that will fill placeholders in our Kubernetes manifests with your configuration values.

To run the script, navigate to the root of the directory containing your kustomization.yaml file, which also contains the configmap-generator.sh script. Then, run the script with these two commands:

chmod 700...

These release notes are for Zenhub Enterprise for Virtual Machine and Zenhub Enterprise for Kubernetes.

• For all users using Zenhub on github.com, please check out our new feature announcements on our product changelog.
• For administrators planning upgrades, please refer to the "Important Upgrade Instructions for Administrators" section.

GitHub Enterprise Server compatibility

Zenhub Enterprise 4.3.1 supports GitHub Enterprise versions: 3.13, 3.14, and 3.15

What's new in Zenhub Enterprise 4.3.1

Contains a range of bug fixes

Features

No new features in this release

Security Fixes

No new security fixes in this release

Known Issues

• Mozilla recently raised the minimum Firefox version required to run published Firefox extensions from 52.0 to 58.0. This results in failed validation during upload of the Zenhub Firefox extension. Until a fix is released, the workaround is to extract the firefox.zip, update strict_min_version at the bottom of the manifest.json file from 52.0 to 58.0, and re-zip the bundle before upload. If you have any questions, please reach out to enterprise@zenhub.com.

VM Embedded Component Versions

Important Upgrade Instructions for Administrators

Zenhub Enterprise for Virtual Machine

• You must be running 4.1.x, 4.2.x, or 4.3.0 to perform the upgrade to ZHE 4.3.1
• For users currently running Zenhub Enterprise, contact our team for a download link for the 4.1.3 upgrade package. The upgrade process is detailed in our documentation.
• 4.3.1 includes a monitoring stack (experimental) that the administrator can deploy via zhe-config --monitoring-stack deploy
  • Deploys Grafana, Kube-state-metrics, and Prometheus
  • Grafana will come with pre-configured Datasources and sample Dashboards
  • Grafana can be accessed via <zenhub.domain>:8443/admin/grafana
  • Prometheus can be accessed via <zenhub.domain>:8443/admin/prometheus
    
    

Zenhub Enterprise for Kubernetes

⚠️ NOTE: The minimum version of Kubernetes required to run ZHE 4.3 is now v1.28.

1. Prepare

• Get the kustomization.yaml you configured to setup Zenhub
• Perform a diff to make sure no outstanding changes are waiting to be applied

kustomize build . | kubectl diff -f-

It should exit 0 and only display a warning of unused variables. If changes are pending, apply them before starting the upgrade process.

• Make a copy of your existing kustomization.yaml and keep it handy for the next step

2. Update kustomization.yaml

• Check out the zenhub-enterprise repository at the tag of this release
• Populate the new kustomization.yaml with your existing configuration values

Be sure to replace any additional customized configuration (such as ingress, TLS configuration) with your original configuration from before as well.

• In ZHE 4.0 and onwards, secret_key_base is required to be a 42 byte string, any existing 38 byte string should be updated as described in kustomization.yaml
• If you are using your own registry and not Zenhub's registry, upload the new images tagged with this release to your registry.

3. Run configmap-generator.sh

Once you have setup all the configurations in your copy of kustomization.yaml and are ready to deploy to your cluster, you must run the configmap-generator.sh script that will fill placeholders in our Kubernetes manifests with your configuration values.

To run the script, navigate to the root of the directory containing your kustomization.yaml file, which also contains the configmap-generator.sh script. Then, run the script with these two commands:

chmod 700 configmap-generator.sh
./configmap-generator.sh

4. Application updates

In your new kustomization.yaml, confirm that the cluster image tags are set to the new images for this release:

If you are using your own registry, ensure that the newName fields are configured for that instead of Zenhub's

images:
  - name: kraken-webapp
    newName: us.gcr.io/zenhub-public/kraken-webapp
    newTag: zhe-4.3.1
  - name: kraken-extension
    newName: us.gcr.io/zenhub-public/kraken-extension
    newTag: zhe-4.3.1
  - name: kraken-zhe-admin
    newName: us.gcr.io/zenhub-public/kraken-zhe-admin
    newTag: zhe-4.3.1
  - name: raptor-backend
    newName: us.gcr.io/zenhub-public/raptor-backend
    newTag: zhe-4.3.1
  - name: toad-backend
    newName: us.gcr.io/zenhub-public/toad-backend
    newTag: zhe-4.3.1
  - name: sanitycheck
    newName: us.gcr.io/zenhub-public/sanitycheck
    newTag: zhe-4.3.1
  - name: devsite
    newName: us.gcr.io/zenhub-public/devsite
    newTag: zhe-4.3.1
  - name: busybox
    newName: docker.io/library/busybox
    newTag: latest
  - name: nginx
    newName: docker.io/library/nginx
    newTag: latest

• First, delete any raptor-db-migrate and sanitycheck jobs so they may be recreated without errors:

Make sure the status of the jobs are Complete and not Running

kubectl -n <your_dedicated_namespace> delete job/raptor-db-migrate job/sanitycheck

• Then perform a diff to check what the upgrade will do (this command must be run from the directory that contains your kustomization.yaml

kustomize build . | kubectl diff -f-

• If everything looks correct and there are no errors, you can deploy to the cluster via:

kustomize build . | kubectl apply -f-

7. Finalize

• Securely store the updated kustomization.yaml

These release notes are for Zenhub Enterprise for Virtual Machine and Zenhub Enterprise for Kubernetes.

• For all users using Zenhub on github.com, please check out our new feature announcements on our product changelog.
• For administrators planning upgrades, please refer to the "Important Upgrade Instructions for Administrators" section.

GitHub Enterprise Server compatibility

Zenhub Enterprise 4.3.0 supports GitHub Enterprise versions: 3.13 and 3.14

What's new in Zenhub Enterprise 4.3.0

We are thrilled to announce the release of Zenhub Enterprise 4.3.0 which contains a range of changes and security updates. Additionally, this release has been tested against the newly released Github Enterprise Server 3.14 and is compatible.

Features

Assumed estimates for unestimated Issues in Reports

It’s not uncommon for teams to work on and close issues without estimating them due to reasons like complexity, uncertainty, or oversight. But don't worry—Zenhub now assigns a default estimate of 1 story point to any planned and closed issues that were left unestimated.

This ensures your Velocity and Release Reports are powered up by default, providing more accurate reflections of your team's performance even if some estimates were missed.

Release Reports for Non-GitHub Users and Zenhub Issues

Release Reports are now accessible to users who are not connected to GitHub and for those working with Zenhub issues. This ensures a more comprehensive view of all issues in your releases, including Zenhub issues. Additionally, you can now collaborate and share your Release Reports with users not connected to GitHub, allowing them to follow the progress of your releases.

Zenhub Command Palette

Zenhub’s command palette is a universal search engine for Zenhub, making navigation a breeze. The command palette can be opened anywhere in the Zenhub web app using the keyboard shortcut [Command + K] on Mac or [Ctrl + K] on Windows. With it, you can easily navigate to features, take actions in Zenhub (like “create Issue”), or search for Issues and Epics in your workspace. Learn more here!

Inactive User Auditing

To help Zenhub Enterprise administrators identify and remove inactive seats, a new "Last Seen" column has been added to the list of Users in the settings area.

Roadmap Improvements

We’ve made a few improvements to the roadmap to make your organization-wide project planning and tracking easier.

• Undated items on the roadmap now appear at the bottom instead of the top, making it easier to see what your team is working on right away.
• Dependencies on the roadmap are now available for all users. (Previously some users on older versions of the product were not able to add them).
• Performance improvements mean that the roadmap loads up to 5x faster!

Performance Improvements

In 4.3 we made several core architectural changes that improve the performance of the app across a wide number of different areas. For a full breakdown of all the changes see our release notes post, but here are just a few highlights:

• Reduced rates of board load failures by 10x
• Improved board load time by up to 2x
• Improved issue page load time by up to 4x
• Improved daily feed load time by 33%
• Improved stability and speed of issue page updates
• Reduced memory usage of backend services with jemalloc implementation

Improved Milestone Support

We've made some improvements for teams who rely on GitHub Milestones:

• Improved the support for Milestones on the Velocity Report
  • Filters now correctly apply for calculating average values
  • Dated Milestones should now show in the Milestone selector
  • Milestones with a due date will be plotted on the chart
  • Milestones without a due date will be shown in the list below the chart
• Fixed several issues on the Milestone Report
  • Issues closed within the dates of the milestone are added to the report
  • Issues closed outside the Milestone date range will still be added to the report, but won't impact the burndown metrics
• Highlight more clearly cases where Milestones are missing their due dates
• Deleting a milestone from the "Milestones" page will now correctly handle situations where the Milestone might have been missing in one of the GitHub repositories

Security Fixes

• Package security updates
• Rails upgrade to major version 7

Known Issues

• Mozilla recently raised the minimum Firefox version required to run published Firefox extensions from 52.0 to 58.0. This results in failed validation during upload of the Zenhub Firefox extension. Until a fix is released, the workaround is to extract the firefox.zip, update strict_min_version at the bottom of the manifest.json file from 52.0 to 58.0, and re-zip the bundle before upload. If you have any questions, please reach out to enterprise@zenhub.com.

VM Embedded Component Versions

Important Upgrade Instructions for Administrators

Zenhub Enterprise for Virtual Machine

• You must be running 4.1.x or 4.2.x to perform the upgrade to ZHE 4.3.0
• For users currently running Zenhub Enterprise, contact our team for a download link for the 4.1.3 upgrade package. The upgrade process is detailed in our documentation.
• 4.3.0 includes a monitoring stack (experimental) that the administrator can deploy via zhe-config --monitoring-stack deploy
  • Deploys Grafana, Kube-state-metrics, and Prometheus
  • Grafana will come with pre-configured Datasources and sample Dashboards
  • Grafana can be accessed via <zenhub.domain>:8443/admin/grafana
  • Prometheus can be accessed via <zenhub.domain>:8443/admin/prometheus
    
    

Zenhub Enterprise for Kubernetes

⚠️ NOTE: The minimum version of Kubernetes required to run ZHE 4.3 is now v1.28.

1. Prepare

• Get the kustomization.yaml you configured to setup Zenhub
• Perform a diff to make sure no outstanding changes are waiting to be applied

kustomize build . | kubectl diff -f-

It should exit 0 and only display a warning of unused variables. If changes are pending, apply them before starting the upgrade process.

• Make a copy of your existing kustomization.yaml and keep it handy for the next step

2. Update kustomization.yaml

• Check out the zenhub-enterprise repository at the tag of this release
• Populate the new kustomization.yaml with your existing configuration values

Be sure to replace any additional customized configuration (such as ingress, TLS configuration) with your original configuration from before as well.

• In ZHE 4.0 and onwards, secret_key_base is required to be a 42 byte string, any existing 38 byte string should be updated as described in kustomization.yaml
• If you are using your own registry and not Zenhub's registry, upload the new images tagged with this release to your registry.

3. Run configmap-generator.sh

Once you have setup all the configurations in your copy of kustomization.yaml and are ready to deploy to your cluster, you must run the configmap-generator.sh script that will fill placeholders in our Kubernetes manifests with your configuration values.

To run the script, navigate to the root of the directory containing your kustomization.yaml file, which also contains the configmap-generator.sh script. Then, run the script with these two commands:

chmod 700 configmap-generator.sh
./configmap-generator.sh

4. Application updates

In your new kustomization.yaml, confirm that the cluster image tags are set to the new images for this release:

If you are using your own registry, ensure that the newName fields are configured for that instead of Zenhub's

images:
  - name: kraken-webapp
    newName: us.gcr.io/zenhub-public/kraken-webapp
    newTag: zhe-4.3.0
  - name: kraken-extension
    newName: us.gcr.io/zenhub-public/kraken-extension
    newTag: zhe-4.3.0
  - name: kraken-zhe-admin
    newName: us.gcr.io/zenhub-public/kraken-zhe-admin
    newTag: zhe-4.3.0
  - name: raptor-backend
    newName: us.gcr.io/zenhub-public/raptor-backend
    newTag: zhe-4.3.0
  - name: toad-backend
    newName: us.gcr.io/zenhub-public/toad-backend
    newTag: zhe-4.3.0
  - name: sanitycheck
    newName: us.gcr.io/zenhub-public/sanitycheck
    newTag: zhe-4.3.0
  - name: devsite
    newName: us.gcr.io/zenhub-public/devsite
    newTag: zhe-4.3.0
  - name: busybox
    newName: docker.io/library/busybox
    newTag: latest
  - name: nginx
    newName: docker.io/library/nginx
    newTag: latest

• First, delete any raptor-db-migrate and sanitycheck jobs so they may be recreated without errors:

Make sure the status of the jobs are Complete and not Running

kubectl -n <your_dedicated_namespace> delete job/raptor...

These release notes are for Zenhub Enterprise for Virtual Machine and Zenhub Enterprise for Kubernetes.

• For all users using Zenhub on github.com, please check out our new feature announcements on our product changelog.
• For administrators planning upgrades, please refer to the "Important Upgrade Instructions for Administrators" section.

GitHub Enterprise Server compatibility

Zenhub Enterprise 4.2.1 supports GitHub Enterprise versions: 3.11, 3.12, and 3.13

What's new in Zenhub Enterprise 4.2.1

We are thrilled to announce the release of Zenhub Enterprise 4.2.1 which contains a range of changes and security updates. Additionally, this release has been tested against the newly released Github Enterprise Server 3.13 and is compatible.

Features

No new features in this release

Security Fixes

• Package security updates
• Patched an application security vulnerability

Bug Fixes

• No bug fixes in this release

Changes

• Updated PostgreSQL configuration for improved performance
• Updated upgrade bundle to improve reliability of upgrades
• Compatible with GitHub Enterprise Server 3.13

Known Issues

• Mozilla recently raised the minimum Firefox version required to run published Firefox extensions from 52.0 to 58.0. This results in failed validation during upload of the Zenhub Firefox extension. Until a fix is released, the workaround is to extract the firefox.zip, update strict_min_version at the bottom of the manifest.json file from 52.0 to 58.0, and re-zip the bundle before upload. If you have any questions, please reach out to enterprise@zenhub.com.

VM Embedded Component Versions

Important Upgrade Instructions for Administrators

Zenhub Enterprise for Virtual Machine

This version of ZHE newly supports skipping a feature version during the upgrade. This means you can now upgrade two feature versions at a time! For this release, you can upgrade from v4.0.X, or v4.1.X.

• For users currently running Zenhub Enterprise, contact our team for a download link for the 4.2.1 upgrade package. The upgrade process is detailed in our documentation.

• For enabling AI features, please consult the setup documentation for detailed steps and prerequisites: https://github.com/ZenHubHQ/zenhub-enterprise/tree/master/virtual-machine#12-ai-features. When you're ready to start, contact our team for a download link for the AI component installation package.

Zenhub Enterprise for Kubernetes

• The new suggested MongoDB version for Zenhub Enterprise v4.2 is the latest version of MongoDB v5.0. Please pay attention to the list of MongoDB v5.0 patch versions that should be avoided for production use here: https://www.mongodb.com/docs/manual/release-notes/5.0/#patch-releases. We suggest upgrading to MongoDB v5.0 prior to upgrading Zenhub Enterprise to v4.2.

• Some extra upgrade instructions have been added specifically for this release due to some database changes that accompany the application updates. Please follow the upgrade instructions below for this release:

⚠️ NOTE: The minimum version of Kubernetes required to run ZHE 4.2 is now v1.27.

1. Prepare

• Get the kustomization.yaml you configured to setup Zenhub
• Perform a diff to make sure no outstanding changes are waiting to be applied

kustomize build . | kubectl diff -f-

It should exit 0 and only display a warning of unused variables. If changes are pending, apply them before starting the upgrade process.

• Make a copy of your existing kustomization.yaml and keep it handy for the next step

2. Update kustomization.yaml

• Check out the zenhub-enterprise repository at the tag of this release
• Populate the new kustomization.yaml with your existing configuration values

Be sure to replace any additional customized configuration (such as ingress, TLS configuration) with your original configuration from before as well.

• In ZHE 4.0 and onwards, secret_key_base is required to be a 42 byte string, any existing 38 byte string should be updated as described in kustomization.yaml
• If you are using your own registry and not Zenhub's registry, upload the new images tagged with this release to your registry.

3. Run configmap-generator.sh

Once you have setup all the configurations in your copy of kustomization.yaml and are ready to deploy to your cluster, you must run the configmap-generator.sh script that will fill placeholders in our Kubernetes manifests with your configuration values.

To run the script, navigate to the root of the directory containing your kustomization.yaml file, which also contains the configmap-generator.sh script. Then, run the script with these two commands:

chmod 700 configmap-generator.sh
./configmap-generator.sh

4. Application updates

In your new kustomization.yaml, confirm that the cluster image tags are set to the new images for this release:

If you are using your own registry, ensure that the newName fields are configured for that instead of Zenhub's

images:
  - name: kraken-webapp
    newName: us.gcr.io/zenhub-public/kraken-webapp
    newTag: zhe-4.2.1
  - name: kraken-extension
    newName: us.gcr.io/zenhub-public/kraken-extension
    newTag: zhe-4.2.1
  - name: kraken-zhe-admin
    newName: us.gcr.io/zenhub-public/kraken-zhe-admin
    newTag: zhe-4.2.1
  - name: raptor-backend
    newName: us.gcr.io/zenhub-public/raptor-backend
    newTag: zhe-4.2.1
  - name: toad-backend
    newName: us.gcr.io/zenhub-public/toad-backend
    newTag: zhe-4.2.1
  - name: sanitycheck
    newName: us.gcr.io/zenhub-public/sanitycheck
    newTag: zhe-4.2.1
  - name: devsite
    newName: us.gcr.io/zenhub-public/devsite
    newTag: zhe-4.2.1
  - name: busybox
    newName: docker.io/library/busybox
    newTag: latest
  - name: nginx
    newName: docker.io/library/nginx
    newTag: latest

• First, delete any raptor-db-migrate and sanitycheck jobs so they may be recreated without errors:

Make sure the status of the jobs are Complete and not Running

kubectl -n <your_dedicated_namespace> delete job/raptor-db-migrate job/sanitycheck

• Then perform a diff to check what the upgrade will do (this command must be run from the directory that contains your kustomization.yaml

kustomize build . | kubectl diff -f-

• If everything looks correct and there are no errors, you can deploy to the cluster via:

kustomize build . | kubectl apply -f-

5. Database Changes for Zenhub Enterprise for Kubernetes

⚠️ NOTE: For upgrading to Zenhub Enterprise version 4.2 from 4.0.X, Zenhub will require a manual change to the PostgreSQL schema.
A constraint called pih_no_overlap from the pipeline_issue_histories table is required to be dropped and replaced.

To do this, you may follow the following steps:

1. Ensure you have a backup of the existing PostgreSQL database. Implementation may vary depending on the PostgreSQL service provider
2. Perform the following while connected to the PostgreSQL database:

ALTER table pipeline_issue_histories DROP CONSTRAINT pih_no_overlap;
ALTER TABLE ONLY public.pipeline_issue_histories
    ADD CONSTRAINT pih_no_overlap EXCLUDE USING gist (workspace_id WITH =, issue_id WITH =, tsrange(started_at, ended_at, '[)'::text) WITH &&) DEFERRABLE;

1. Verify the completion of the above with the following PostgreSQL command which should return an empty result:

SELECT * FROM pg_stat_activity WHERE query LIKE '%public.pipeline_issue_histories%';

Next, proceed to run the regular data migration script.

⚠️ NOTE: Running this script is only required if you are upgrading from ZHE 4.0.X
⚠️ NOTE: If you are using stunnel, be sure to uncomment the relevant sections in update/batch_v1_job_data_migration.yaml

• Run the script found in k8s-cluster/update/zhe-upgrade.sh via the commands below:

If you use the ZenHub registry

cd update
./zhe-upgrade.sh yourNamespace

If you use your own registry

cd update
./zhe-upgrade.sh yourNamespace yourRegistryName

6. Re Deploy Application

⚠️ NOTE: Running these commands is only required if you are upgrading from ZHE 4.0.X

The data migration script run in the previous step will have scaled down the application in order to safely migrate data without active database writes occurring. Now that the migration is complete, the application needs to be deployed to the normal desired operational state:

• First perform a diff to check what will change (this command must be run from the directory that contains your kustomization.yaml

kustomize build . | kubectl diff -f-

• If everything looks correct and there are no errors, you can deploy to the cluster via:

kustomize build . | kubectl apply -f-

7. Finalize

• Securely store the updated kustomization.yaml

These release notes are for Zenhub Enterprise for Virtual Machine and Zenhub Enterprise for Kubernetes.

• For all users using Zenhub on github.com, please check out our new feature announcements on our product changelog.
• For administrators planning upgrades, please refer to the "Important Upgrade Instructions for Administrators" section.

GitHub Enterprise Server compatibility

Zenhub Enterprise 4.1.3 supports GitHub Enterprise versions: 3.9, 3.10, and 3.11

What's new in Zenhub Enterprise 4.1.3

We are thrilled to announce the release of Zenhub Enterprise 4.1.3 which contains a range of bug fixes and security updates

Features

No new features in this release

Security Fixes

• Package security updates
• Patched an application security vulnerability

Bug Fixes

• No bug fixes in this release

Changes

• Updated PostgreSQL configuration for improved performance
• Updated upgrade bundle to improve reliability of upgrades

Known Issues

• Mozilla recently raised the minimum Firefox version required to run published Firefox extensions from 52.0 to 58.0. This results in failed validation during upload of the Zenhub Firefox extension. Until a fix is released, the workaround is to extract the firefox.zip, update strict_min_version at the bottom of the manifest.json file from 52.0 to 58.0, and re-zip the bundle before upload. If you have any questions, please reach out to enterprise@zenhub.com.

VM Embedded Component Versions

Important Upgrade Instructions for Administrators

Zenhub Enterprise for Virtual Machine

• You must be running 4.0.X, 4.1.0, 4.1.1, or 4.1.2 to perform the upgrade to ZHE 4.1.3

• For users currently running Zenhub Enterprise, contact our team for a download link for the 4.1.3 upgrade package. The upgrade process is detailed in our documentation.

Zenhub Enterprise for Kubernetes

• Some extra upgrade instructions have been added specifically for this release due to some database changes that accompany the application updates. Please follow the upgrade instructions below for this release:

⚠️ NOTE: The minimum version of Kubernetes required to run ZHE 4.1 is now v1.26.

1. Prepare

• Get the kustomization.yaml you configured to setup Zenhub
• Perform a diff to make sure no outstanding changes are waiting to be applied

kustomize build . | kubectl diff -f-

It should exit 0 and only display a warning of unused variables. If changes are pending, apply them before starting the upgrade process.

• Make a copy of your existing kustomization.yaml and keep it handy for the next step

2. Update kustomization.yaml

• Check out the zenhub-enterprise repository at the tag of this release
• Populate the new kustomization.yaml with your existing configuration values

Be sure to replace any additional customized configuration (such as ingress, TLS configuration) with your original configuration from before as well.

• In ZHE 4.0 and onwards, secret_key_base is required to be a 42 byte string, any existing 38 byte string should be updated as described in kustomization.yaml
• If you are using your own registry and not Zenhub's registry, upload the new images tagged with this release to your registry.

3. Run configmap-generator.sh

Once you have setup all the configurations in your copy of kustomization.yaml and are ready to deploy to your cluster, you must run the configmap-generator.sh script that will fill placeholders in our Kubernetes manifests with your configuration values.

To run the script, navigate to the root of the directory containing your kustomization.yaml file, which also contains the configmap-generator.sh script. Then, run the script with these two commands:

chmod 700 configmap-generator.sh
./configmap-generator.sh

4. Application updates

In your new kustomization.yaml, confirm that the cluster image tags are set to the new images for this release:

If you are using your own registry, ensure that the newName fields are configured for that instead of Zenhub's

images:
  - name: kraken-webapp
    newName: us.gcr.io/zenhub-public/kraken-webapp
    newTag: zhe-4.1.3
  - name: kraken-extension
    newName: us.gcr.io/zenhub-public/kraken-extension
    newTag: zhe-4.1.3
  - name: kraken-zhe-admin
    newName: us.gcr.io/zenhub-public/kraken-zhe-admin
    newTag: zhe-4.1.3
  - name: raptor-backend
    newName: us.gcr.io/zenhub-public/raptor-backend
    newTag: zhe-4.1.3
  - name: toad-backend
    newName: us.gcr.io/zenhub-public/toad-backend
    newTag: zhe-4.1.3
  - name: sanitycheck
    newName: us.gcr.io/zenhub-public/sanitycheck
    newTag: zhe-4.1.3
  - name: devsite
    newName: us.gcr.io/zenhub-public/devsite
    newTag: zhe-4.1.3
  - name: busybox
    newName: docker.io/library/busybox
    newTag: latest
  - name: nginx
    newName: docker.io/library/nginx
    newTag: latest

• First, delete any raptor-db-migrate and sanitycheck jobs so they may be recreated without errors:

Make sure the status of the jobs are Complete and not Running

kubectl -n <your_dedicated_namespace> delete job/raptor-db-migrate job/sanitycheck

• Then perform a diff to check what the upgrade will do (this command must be run from the directory that contains your kustomization.yaml

kustomize build . | kubectl diff -f-

• If everything looks correct and there are no errors, you can deploy to the cluster via:

kustomize build . | kubectl apply -f-

5. Database Changes for Zenhub Enterprise for Kubernetes

⚠️ NOTE: For upgrading to Zenhub Enterprise version 4.1 from 4.0.X, Zenhub will require a manual change to the PostgreSQL schema.
A constraint called pih_no_overlap from the pipeline_issue_histories table is required to be dropped and replaced.

To do this, you may follow the following steps:

1. Ensure you have a backup of the existing PostgreSQL database. Implementation may vary depending on the PostgreSQL service provider
2. Perform the following while connected to the PostgreSQL database:

ALTER table pipeline_issue_histories DROP CONSTRAINT pih_no_overlap;
ALTER TABLE ONLY public.pipeline_issue_histories
    ADD CONSTRAINT pih_no_overlap EXCLUDE USING gist (workspace_id WITH =, issue_id WITH =, tsrange(started_at, ended_at, '[)'::text) WITH &&) DEFERRABLE;

1. Verify the completion of the above with the following PostgreSQL command which should return an empty result:

SELECT * FROM pg_stat_activity WHERE query LIKE '%public.pipeline_issue_histories%';

Next, proceed to run the regular data migration script.

⚠️ NOTE: Running this script is only required if you are upgrading from ZHE 4.0.X
⚠️ NOTE: If you are using stunnel, be sure to uncomment the relevant sections in update/batch_v1_job_data_migration.yaml

• Run the script found in k8s-cluster/update/zhe-upgrade.sh via the commands below:

If you use the ZenHub registry

cd update
./zhe-upgrade.sh yourNamespace

If you use your own registry

cd update
./zhe-upgrade.sh yourNamespace yourRegistryName

6. Re Deploy Application

⚠️ NOTE: Running these commands is only required if you are upgrading from ZHE 4.0.X

The data migration script run in the previous step will have scaled down the application in order to safely migrate data without active database writes occurring. Now that the migration is complete, the application needs to be deployed to the normal desired operational state:

• First perform a diff to check what will change (this command must be run from the directory that contains your kustomization.yaml

kustomize build . | kubectl diff -f-

• If everything looks correct and there are no errors, you can deploy to the cluster via:

kustomize build . | kubectl apply -f-

7. Finalize

• Securely store the updated kustomization.yaml

These release notes are for Zenhub Enterprise for Virtual Machine and Zenhub Enterprise for Kubernetes.

• For all users using Zenhub on github.com, please check out our new feature announcements on our product changelog.
• For administrators planning upgrades, please refer to the "Important Upgrade Instructions for Administrators" section.

GitHub Enterprise Server compatibility

Zenhub Enterprise 4.0.3 supports GitHub Enterprise versions: 3.8, 3.9, 3.10

What's new in Zenhub Enterprise 4.0.3

We are thrilled to announce the release of Zenhub Enterprise 4.0.3, packed with a host of exciting new features designed to optimize your workflow, boost productivity, and heighten collaboration.

Features

No new features in this release

Security Fixes

• Package security updates
• Patched an application security vulnerability

Bug Fixes

• Resolved a problem that caused the Chrome Web Store to reject publishing the browser extension due to additional requirements for Manifest V3.

Changes

• Updated PostgreSQL configuration for improved performance
• Updated upgrade bundle to improve reliability of upgrades

Known Issues

• Mozilla recently raised the minimum Firefox version required to run published Firefox extensions from 52.0 to 58.0. This results in failed validation during upload of the Zenhub Firefox extension. Until a fix is released, the workaround is to extract the firefox.zip, update strict_min_version at the bottom of the manifest.json file from 52.0 to 58.0, and re-zip the bundle before upload. If you have any questions, please reach out to enterprise@zenhub.com.
• In some cases, admin permissions may be lost on upgrade. To restore admin permissions, go to https://<subdomain_suffix>.<domain_tld>:8443/settings and enter the admin username/email
• When removing "Seats" the available license count doesn't update until a page refresh
• When using W3ID integration, some users are seeing their name show up as empty
• In some rare cases, deleting a workspace displays an error message
• In some rare cases, new users who sign up for Zenhub are taken directly to the board instead of being shown the onboarding form
• Usage report data from before Zenhub Enterprise v4.0 is not displayed in the admin dashboard
• When trying to create an account from the login page an 'Account does not exist. Please sign up instead.' error occurs. This is expected behaviour, to create a new account you must use the sign-up page.

VM Embedded Component Versions

Important Upgrade Instructions for Administrators

Zenhub Enterprise for Virtual Machine

⚠️ NOTE: For the upgrade from ZHE 3.5 -> ZHE 4.0, the regular rollback steps cannot be used. Please perform a machine level snapshot prior to upgrading to use as a backup in case you need to revert back to ZHE 3.5 for any reason.

• You must be running ZHE 3.5.X, 4.0.0, 4.0.1, or 4.0.2 to perform the upgrade to ZHE 4.0.3.

• For users currently running Zenhub Enterprise, contact our team for a download link for the 4.0.3 upgrade package. The upgrade process is detailed in our documentation.

Zenhub Enterprise for Kubernetes

• Some extra upgrade instructions have been added specifically for this release due to some database changes that accompany the application updates. Please follow the upgrade instructions below for this release:

⚠️ NOTE: The minimum version of Kubernetes required to run ZHE 4.0 is now v1.24.

1. Prepare

• Get the kustomization.yaml you configured to setup Zenhub
• Perform a diff to make sure no outstanding changes are waiting to be applied

kustomize build . | kubectl diff -f-

It should exit 0 and only display a warning of unused variables. If changes are pending, apply them before starting the upgrade process.

• Make a copy of your existing kustomization.yaml and keep it handy for the next step

2. Update kustomization.yaml

• Check out the zenhub-enterprise repository at the tag of this release
• Populate the new kustomization.yaml with your existing configuration values

Be sure to replace any additional customized configuration (such as ingress, TLS configuration) with your original configuration from before as well.

• In ZHE 4.0, secret_key_base is required to be a 42 byte string, any existing 38 byte string should be updated as described in kustomization.yaml
• If you are using your own registry and not Zenhub's registry, upload the new images tagged with this release to your registry.

3. Run configmap-generator.sh

Once you have setup all the configurations in your copy of kustomization.yaml and are ready to deploy to your cluster, you must run the configmap-generator.sh script that will fill placeholders in our Kubernetes manifests with your configuration values.

To run the script, navigate to the root of the directory containing your kustomization.yaml file, which also contains the configmap-generator.sh script. Then, run the script with these two commands:

chmod 700 configmap-generator.sh
./configmap-generator.sh

4. Application updates

In your new kustomization.yaml, confirm that the cluster image tags are set to the new images for this release:

If you are using your own registry, ensure that the newName fields are configured for that instead of Zenhub's

images:
  - name: kraken-webapp
    newName: us.gcr.io/zenhub-public/kraken-webapp
    newTag: zhe-4.0.3
  - name: kraken-extension
    newName: us.gcr.io/zenhub-public/kraken-extension
    newTag: zhe-4.0.3
  - name: kraken-zhe-admin
    newName: us.gcr.io/zenhub-public/kraken-zhe-admin
    newTag: zhe-4.0.3
  - name: raptor-backend
    newName: us.gcr.io/zenhub-public/raptor-backend
    newTag: zhe-4.0.3
  - name: toad-backend
    newName: us.gcr.io/zenhub-public/toad-backend
    newTag: zhe-4.0.3
  - name: sanitycheck
    newName: us.gcr.io/zenhub-public/sanitycheck
    newTag: zhe-4.0.3
  - name: devsite
    newName: us.gcr.io/zenhub-public/devsite
    newTag: zhe-4.0.3
  - name: busybox
    newName: docker.io/library/busybox
    newTag: latest
  - name: nginx
    newName: docker.io/library/nginx
    newTag: latest

• First, delete any raptor-db-migrate and sanitycheck jobs so they may be recreated without errors:

Make sure the status of the jobs are Complete and not Running

kubectl -n <your_dedicated_namespace> delete job/raptor-db-migrate job/sanitycheck

• Then perform a diff to check what the upgrade will do (this command must be run from the directory that contains your kustomization.yaml

kustomize build . | kubectl diff -f-

• If everything looks correct and there are no errors, you can deploy to the cluster via:

kustomize build . | kubectl apply -f-

5. Database changes

⚠️ NOTE: Running this script is only required if you are upgrading from ZHE 3.5.

• Run the script found in k8s-cluster/update/zhe-upgrade.sh via the commands below:

If you use the ZenHub registry

cd update
./zhe-upgrade.sh yourNamespace

If you use your own registry

cd update
./zhe-upgrade.sh yourNamespace yourRegistryName

6. Re Deploy Application

⚠️ NOTE: Running these commands is only required if you are upgrading from ZHE 3.5.

The data migration script run in the previous step will have scaled down the application in order to safely migrate data without active database writes occurring. Now that the migration is complete, the application needs to be deployed to the normal desired operational state:

• First perform a diff to check what will change (this command must be run from the directory that contains your kustomization.yaml

kustomize build . | kubectl diff -f-

• If everything looks correct and there are no errors, you can deploy to the cluster via:

kustomize build . | kubectl apply -f-

7. Finalize

• Securely store the updated kustomization.yaml

These release notes are for Zenhub Enterprise for Virtual Machine and Zenhub Enterprise for Kubernetes.

• For all users using Zenhub on github.com, please check out our new feature announcements on our product changelog.
• For administrators planning upgrades, please refer to the "Important Upgrade Instructions for Administrators" section.

GitHub Enterprise Server compatibility

Zenhub Enterprise 4.2.0 supports GitHub Enterprise versions: 3.11 and 3.12

What's new in Zenhub Enterprise 4.2.0

We are thrilled to announce the release of Zenhub Enterprise 4.2, packed with a host of exciting new features designed to optimize your workflow, boost productivity, and heighten collaboration. Zenhub Enterprise 4.2 includes AI components that can suggest Issue labels, acceptance criteria, and generate sprint reviews.

Features

AI Features

AI Label Suggestions

This feature uses AI with the help of minimizing a tedious task of searching for the right label(s). Start by creating an issue (Zenhub issue or GitHub issue), type in a title to best describe the issue. Once you click out of the title section you will see under the label metadata that Zenhub AI has made some suggestions. You can select one label or all, and you can also refresh if the labels suggested weren't quite right. The labels suggested are the labels that currently exist within the repository you are working in.

AI Sprint Review Report

The Sprint Review report is a new report within Zenhub that summarizes the work completed by your team within a sprint using Zenhub AI. The report features a short text summary of the completed issues, and groups closed issues by their epics, creating a useful starting point or agenda for your next sprint review or demo meeting. Sprint Reviews are automatically generated per workspace throughout the Sprint.

Features:

• Manually update a text description or leverage Zenhub AI to rephrase it: shorter, longer, more technical, less technical
• Add or remove issues from groups
• Access Sprint Reviews for a previously completed sprint from the roadmap
• Visual indication of issues closed after a sprint ended
  … and more!

AI Acceptance Criteria

AI Acceptance Criteria is a new AI feature that enables users to generate acceptance criteria for a Zenhub issue or GitHub issue. Generated acceptance criteria will automatically be added to the issue or Epic description in BDD format as a checklist for ease of use for testing and development.

Velocity Report Improvements

Available for non-GitHub-connected users

Previously exclusive to GitHub-connected users, the Velocity Report is now available to all users regardless of their GitHub-connection status. This enhancement ensures that all teams, regardless of their preferred workflow or toolset, can benefit from the valuable insights provided by the Velocity Report.

A Year in View

The Velocity Report now covers a more comprehensive date range, spanning up to one year. This allows teams to compare see and analyze performance against past quarters and identify long-term patterns of team performance. The date range selection is now 2 weeks, 1 month and then in increments of 3 months up to 1 year.

To use this, navigate to the Velocity Report and select the Date Period filter at the top section. You may also use it in association with other filters on the Report.

Multiple repository selection

Zenhub's Velocity Report now empowers users with the ability to select and analyze issues within more than one repository, offering a consolidated view for a more efficient and insightful reporting experience for teams that work across multiple repositories.

Open but "Done" Issues

You can now track velocity based on specific pipelines. This can be done by setting "Completed Pipelines" on the Velocity Report. This addition allows for a realistic view of your project's progress based on different workflows for teams that consider issues in a specific pipeline as "Done" even if those issues are not Closed.

Assignee, Epic and Label Filters

Users now have the ability to filter their Velocity Report by Epics, assignees, and labels. This provides greater flexibility and insight into team performance and project progress.

• Filter by Epics: Users can now filter their Velocity Report by Epics, allowing them to focus on specific high-level initiatives or themes within their projects. This enhancement enables teams to track the progress and velocity of individual Epics, providing valuable insights into their impact on overall project delivery.

• Filter by Assignees: In addition to filtering by Epics, users can also filter their Velocity Report by individual assignees. This feature enables teams to assess individual team members' contributions toward project velocity, identify potential bottlenecks or resource constraints, and optimize workload distribution for improved efficiency and productivity.

• Filter by Labels: If you tag work by labels, the Velocity Report now enables you to visualize and track work items based on labels, offering enhanced flexibility in organizing and analyzing project data according to specific criteria or themes.

Roadmap Improvements

Key Dates

You can now seamlessly integrate important dates into your roadmap. Customize the title of each key date to accurately reflect its significance and set the corresponding date. These additions are shared across the workspace, ensuring comprehensive awareness and alignment on all upcoming events, deadlines, or important dates, and how they relate to your project timeline.

Add a key date on the roadmap by bringing your cursor up to the timeline.

Dependencies

Dependencies are now available on the roadmap, shown as lines connecting Epics that depend on one another.

Exporting and Sharing

You now have the ability to export the roadmap as a CSV, PNG and/or SVG. This allows you to pop the roadmap in a spreadsheet or a slide deck to present to your organization.

You can now select the date range you want to have displayed in the exported file, as well as the timeline scale being quarterly, monthly, or weekly. There is also now a selector for which projects and Epics you want to include in the export, so you can include exactly what you need and nothing more.

Board Improvements

Predicted Sprint and Auto Sprint Assignment

Zenhub can now let you know when an issue will be worked on by predicting which sprint it will fit into! You will notice a new sprint tag appear on your issues to help you plan future sprints.

You can also automatically assign an issue to the current sprint when the issue is moved into your sprint backlog or onwards across the board. If it’s moved back into your backlog, the sprint will be removed for you. This will help you and your team maintain your sprint hygiene automatically and improve the quality of your reports.

Additionally, when a new sprint starts, Zenhub will automatically move your issues in your prioritized backlog into your sprint backlog. To ensure both of these features work as intended, make sure to configure your pipelines following the instructions below.

Lastly, you now have the ability to add a description or goal to your sprints directly on the sprint page. These goals will show up in your reports and the roadmap to help you stay on track and find historical sprint goals!

In order for Zenhub to properly auto assign and populate your sprint backlog you will need to turn on automated sprints and configure your pipelines. You can do this easily within the 'Modify Reoccurring Sprints' section:

Issue Metadata Automation

• Users can build automa...

These release notes are for Zenhub Enterprise for Virtual Machine and Zenhub Enterprise for Kubernetes.

• For all users using Zenhub on github.com, please check out our new feature announcements on our product changelog.
• For administrators planning upgrades, please refer to the "Important Upgrade Instructions for Administrators" section.

GitHub Enterprise Server compatibility

Zenhub Enterprise 4.1.2 supports GitHub Enterprise versions: 3.9, 3.10, and 3.11

What's new in Zenhub Enterprise 4.1.2

We are thrilled to announce the release of Zenhub Enterprise 4.1.2 which contains a range of bug fixes and security updates

Features

No new features in this release

Security Fixes

• Package security updates fixing critical and high CVE

Bug Fixes

• Fixed a bug causing MongoDB and RabbitMQ to consume large amounts of CPU
• Fixed a bug causing upgrades to fail due to ctr not being ready
• Fixed a bug causing issue dependencies not to update when the blocking issue was closed
• Fixed a bug that could cause a token_key_not_found error in the extension, resulting in various requests to fail
• Fixed a bug causing upgrades to hang due to lack of resources

Changes

• No changes in this release

Known Issues

• No known issues in this release

VM Embedded Component Versions

Important Upgrade Instructions for Administrators

Zenhub Enterprise for Virtual Machine

• You must be running 4.0.X, 4.1.0 or 4.1.1 to perform the upgrade to ZHE 4.1.2

• For users currently running Zenhub Enterprise, contact our team for a download link for the 4.1.2 upgrade package. The upgrade process is detailed in our documentation.

Zenhub Enterprise for Kubernetes

• Some extra upgrade instructions have been added specifically for this release due to some database changes that accompany the application updates. Please follow the upgrade instructions below for this release:

⚠️ NOTE: The minimum version of Kubernetes required to run ZHE 4.1 is now v1.26.

1. Prepare

• Get the kustomization.yaml you configured to setup Zenhub
• Perform a diff to make sure no outstanding changes are waiting to be applied

kustomize build . | kubectl diff -f-

It should exit 0 and only display a warning of unused variables. If changes are pending, apply them before starting the upgrade process.

• Make a copy of your existing kustomization.yaml and keep it handy for the next step

2. Update kustomization.yaml

• Check out the zenhub-enterprise repository at the tag of this release
• Populate the new kustomization.yaml with your existing configuration values

Be sure to replace any additional customized configuration (such as ingress, TLS configuration) with your original configuration from before as well.

• In ZHE 4.0 and onwards, secret_key_base is required to be a 42 byte string, any existing 38 byte string should be updated as described in kustomization.yaml
• If you are using your own registry and not Zenhub's registry, upload the new images tagged with this release to your registry.

3. Run configmap-generator.sh

Once you have setup all the configurations in your copy of kustomization.yaml and are ready to deploy to your cluster, you must run the configmap-generator.sh script that will fill placeholders in our Kubernetes manifests with your configuration values.

To run the script, navigate to the root of the directory containing your kustomization.yaml file, which also contains the configmap-generator.sh script. Then, run the script with these two commands:

chmod 700 configmap-generator.sh
./configmap-generator.sh

4. Application updates

In your new kustomization.yaml, confirm that the cluster image tags are set to the new images for this release:

If you are using your own registry, ensure that the newName fields are configured for that instead of Zenhub's

images:
  - name: kraken-webapp
    newName: us.gcr.io/zenhub-public/kraken-webapp
    newTag: zhe-4.1.2
  - name: kraken-extension
    newName: us.gcr.io/zenhub-public/kraken-extension
    newTag: zhe-4.1.2
  - name: kraken-zhe-admin
    newName: us.gcr.io/zenhub-public/kraken-zhe-admin
    newTag: zhe-4.1.2
  - name: raptor-backend
    newName: us.gcr.io/zenhub-public/raptor-backend
    newTag: zhe-4.1.2
  - name: toad-backend
    newName: us.gcr.io/zenhub-public/toad-backend
    newTag: zhe-4.1.2
  - name: sanitycheck
    newName: us.gcr.io/zenhub-public/sanitycheck
    newTag: zhe-4.1.2
  - name: devsite
    newName: us.gcr.io/zenhub-public/devsite
    newTag: zhe-4.1.2
  - name: busybox
    newName: docker.io/library/busybox
    newTag: latest
  - name: nginx
    newName: docker.io/library/nginx
    newTag: latest

• First, delete any raptor-db-migrate and sanitycheck jobs so they may be recreated without errors:

Make sure the status of the jobs are Complete and not Running

kubectl -n <your_dedicated_namespace> delete job/raptor-db-migrate job/sanitycheck

• Then perform a diff to check what the upgrade will do (this command must be run from the directory that contains your kustomization.yaml

kustomize build . | kubectl diff -f-

• If everything looks correct and there are no errors, you can deploy to the cluster via:

kustomize build . | kubectl apply -f-

5. Database Changes for Zenhub Enterprise for Kubernetes

⚠️ NOTE: For upgrading to Zenhub Enterprise version 4.1 from 4.0.X, Zenhub will require a manual change to the PostgreSQL schema.
A constraint called pih_no_overlap from the pipeline_issue_histories table is required to be dropped and replaced.

To do this, you may follow the following steps:

1. Ensure you have a backup of the existing PostgreSQL database. Implementation may vary depending on the PostgreSQL service provider
2. Perform the following while connected to the PostgreSQL database:

ALTER table pipeline_issue_histories DROP CONSTRAINT pih_no_overlap;
ALTER TABLE ONLY public.pipeline_issue_histories
    ADD CONSTRAINT pih_no_overlap EXCLUDE USING gist (workspace_id WITH =, issue_id WITH =, tsrange(started_at, ended_at, '[)'::text) WITH &&) DEFERRABLE;

1. Verify the completion of the above with the following PostgreSQL command which should return an empty result:

SELECT * FROM pg_stat_activity WHERE query LIKE '%public.pipeline_issue_histories%';

Next, proceed to run the regular data migration script.

⚠️ NOTE: Running this script is only required if you are upgrading from ZHE 4.0.X
⚠️ NOTE: If you are using stunnel, be sure to uncomment the relevant sections in update/batch_v1_job_data_migration.yaml

• Run the script found in k8s-cluster/update/zhe-upgrade.sh via the commands below:

If you use the ZenHub registry

cd update
./zhe-upgrade.sh yourNamespace

If you use your own registry

cd update
./zhe-upgrade.sh yourNamespace yourRegistryName

6. Re Deploy Application

⚠️ NOTE: Running these commands is only required if you are upgrading from ZHE 4.0.X

The data migration script run in the previous step will have scaled down the application in order to safely migrate data without active database writes occurring. Now that the migration is complete, the application needs to be deployed to the normal desired operational state:

• First perform a diff to check what will change (this command must be run from the directory that contains your kustomization.yaml

kustomize build . | kubectl diff -f-

• If everything looks correct and there are no errors, you can deploy to the cluster via:

kustomize build . | kubectl apply -f-

7. Finalize

• Securely store the updated kustomization.yaml