Releases: ZenHubHQ/zenhub-enterprise
Zenhub Enterprise 4.3.1
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 and 3.14
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 from52.0
to58.0
, and re-zip the bundle before upload. If you have any questions, please reach out to enterprise@zenhub.com.
VM Embedded Component Versions
Component | Version |
---|---|
Ubuntu | 22.04.4 |
K3s | v1.28.13+k3s1 |
Kubernetes | v1.28.13 |
Kustomize | v4.5.7 |
Fluentd | v1.16.6-debian-1.0 |
Postgresql | 15.4 |
MongoDB | 6.0.13 |
RabbitMQ | 3.8.35 |
Redis | 7.0.12 |
PgBouncer | 1.20.1 |
Grafana | 10.4.2 |
Prometheus | 2.45.0 |
kube-state-metrics/kube-state-metrics | v2.10.0 |
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
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 inkustomization.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
andsanitycheck
jobs so they may be recreated without errors:
Make sure the status of the jobs are
Complete
and notRunning
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
Zenhub Enterprise 4.3.0
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 from52.0
to58.0
, and re-zip the bundle before upload. If you have any questions, please reach out to enterprise@zenhub.com.
VM Embedded Component Versions
Component | Version |
---|---|
Ubuntu | 22.04.4 |
K3s | v1.28.13+k3s1 |
Kubernetes | v1.28.13 |
Kustomize | v4.5.3 |
Fluentd | v1.16.6-debian-1.0 |
Postgresql | 15.4 |
MongoDB | 6.0.13 |
RabbitMQ | 3.8.35 |
Redis | 7.0.12 |
PgBouncer | 1.20.1 |
Grafana | 10.4.2 |
Prometheus | 2.45.0 |
kube-state-metrics/kube-state-metrics | v2.10.0 |
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
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 inkustomization.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
andsanitycheck
jobs so they may be recreated without errors:
Make sure the status of the jobs are
Complete
and notRunning
kubectl -n <your_dedicated_namespace> delete job/raptor...
Zenhub Enterprise 4.2.1
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 from52.0
to58.0
, and re-zip the bundle before upload. If you have any questions, please reach out to enterprise@zenhub.com.
VM Embedded Component Versions
Component | Version |
---|---|
Ubuntu | 22.04.4 |
K3s | v1.27.11+k3s1 |
Kubernetes | v1.27.11 |
Kustomize | v4.5.3 |
Fluentd | v1.16.2-debian-1.0 |
Postgresql | 15.4 |
MongoDB | 5.0.24 |
RabbitMQ | 3.8.35 |
Redis | 7.0.12 |
PgBouncer | 1.20.1 |
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 inkustomization.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
andsanitycheck
jobs so they may be recreated without errors:
Make sure the status of the jobs are
Complete
and notRunning
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 calledpih_no_overlap
from thepipeline_issue_histories
table is required to be dropped and replaced.
To do this, you may follow the following steps:
- Ensure you have a backup of the existing PostgreSQL database. Implementation may vary depending on the PostgreSQL service provider
- 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;
- 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 inupdate/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
Zenhub Enterprise 4.1.3
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 from52.0
to58.0
, and re-zip the bundle before upload. If you have any questions, please reach out to enterprise@zenhub.com.
VM Embedded Component Versions
Component | Version |
---|---|
Ubuntu | 22.04.4 |
K3s | v1.26.8+k3s1 |
Kubernetes | v1.26.8 |
Kustomize | v4.5.3 |
Fluentd | v1.16.2-debian-1.0 |
Postgresql | 15.4 |
MongoDB | 4.4.13 |
RabbitMQ | 3.8.31 |
Redis | 7.0.12 |
PgBouncer | 1.20.1 |
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 inkustomization.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
andsanitycheck
jobs so they may be recreated without errors:
Make sure the status of the jobs are
Complete
and notRunning
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 calledpih_no_overlap
from thepipeline_issue_histories
table is required to be dropped and replaced.
To do this, you may follow the following steps:
- Ensure you have a backup of the existing PostgreSQL database. Implementation may vary depending on the PostgreSQL service provider
- 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;
- 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 inupdate/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
Zenhub Enterprise 4.0.3
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 from52.0
to58.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
Component | Version |
---|---|
Ubuntu | 22.04.4 |
K3s | v1.24.13+k3s1 |
Kubernetes | v1.24.13 |
Kustomize | v4.5.3 |
Fluentd | v1.16.2-debian-1.0 |
Postgresql | 11.16 |
MongoDB | 4.4.13 |
RabbitMQ | 3.8.31 |
Redis | 7.0.5 |
PgBouncer | 1.17.0 |
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 inkustomization.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
andsanitycheck
jobs so they may be recreated without errors:
Make sure the status of the jobs are
Complete
and notRunning
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
Zenhub Enterprise 4.2.0
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...
Zenhub Enterprise 4.1.2
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
Component | Version |
---|---|
Ubuntu | 22.04.2 |
K3s | v1.26.8+k3s1 |
Kubernetes | v1.26.8 |
Kustomize | v4.5.3 |
Fluentd | v1.16.2-debian-1.0 |
Postgresql | 15.4 |
MongoDB | 4.4.13 |
RabbitMQ | 3.8.31 |
Redis | 7.0.12 |
PgBouncer | 1.20.1 |
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 inkustomization.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
andsanitycheck
jobs so they may be recreated without errors:
Make sure the status of the jobs are
Complete
and notRunning
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 calledpih_no_overlap
from thepipeline_issue_histories
table is required to be dropped and replaced.
To do this, you may follow the following steps:
- Ensure you have a backup of the existing PostgreSQL database. Implementation may vary depending on the PostgreSQL service provider
- 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;
- 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 inupdate/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
Zenhub Enterprise 4.1.1
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.1 supports GitHub Enterprise versions: 3.9, 3.10, and 3.11
What's new in Zenhub Enterprise 4.1.1
We are thrilled to announce the release of Zenhub Enterprise 4.1.1 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
- Resolved a problem that caused the Chrome Web Store to reject publishing the browser extension due to additional requirements for Manifest V3.
- Fixed a bug causing the pipeline dropdown not to work on the extension
- Fixed a bug causing some settings such as Sprints or Epics to not save during Issue creation via the extension
- Fixed a bug that caused upgrades to fail due to logrotate requesting too much CPU
- Fixed a race condition that could cause upgrades to fail after k3s upgrade
- Fixed a bug that caused authentication to fail when self-signed certificates were being used
Changes
- Added support for refresh tokens for W3ID external provider authentication
- Updated Redis from v7.0.5 to v7.0.12 (VM)
- Added missing application logs to support bundle generation
- Improved external authentication provider setup documentation
Known Issues
- No known issues in this release
VM Embedded Component Versions
Component | Version |
---|---|
Ubuntu | 22.04.2 |
K3s | v1.26.8+k3s1 |
Kubernetes | v1.26.8 |
Kustomize | v4.5.3 |
Fluentd | v1.16.2-debian-1.0 |
Postgresql | 15.4 |
MongoDB | 4.4.13 |
RabbitMQ | 3.8.31 |
Redis | 7.0.12 |
PgBouncer | 1.20.1 |
Important Upgrade Instructions for Administrators
Zenhub Enterprise for Virtual Machine
-
You must be running 4.0.X or 4.1.0 to perform the upgrade to ZHE 4.1.1
-
For users currently running Zenhub Enterprise, contact our team for a download link for the 4.1.1 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 inkustomization.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.1
- name: kraken-extension
newName: us.gcr.io/zenhub-public/kraken-extension
newTag: zhe-4.1.1
- name: kraken-zhe-admin
newName: us.gcr.io/zenhub-public/kraken-zhe-admin
newTag: zhe-4.1.1
- name: raptor-backend
newName: us.gcr.io/zenhub-public/raptor-backend
newTag: zhe-4.1.1
- name: toad-backend
newName: us.gcr.io/zenhub-public/toad-backend
newTag: zhe-4.1.1
- name: sanitycheck
newName: us.gcr.io/zenhub-public/sanitycheck
newTag: zhe-4.1.1
- name: devsite
newName: us.gcr.io/zenhub-public/devsite
newTag: zhe-4.1.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
andsanitycheck
jobs so they may be recreated without errors:
Make sure the status of the jobs are
Complete
and notRunning
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 calledpih_no_overlap
from thepipeline_issue_histories
table is required to be dropped and replaced.
To do this, you may follow the following steps:
- Ensure you have a backup of the existing PostgreSQL database. Implementation may vary depending on the PostgreSQL service provider
- 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;
- 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 inupdate/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
Zenhub Enterprise 4.1.0
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.0 supports GitHub Enterprise versions: 3.9, 3.10, and 3.11
What's new in Zenhub Enterprise 4.1.0
We are thrilled to announce the release of Zenhub Enterprise 4.1.0, packed with a host of exciting new features designed to optimize your workflow, boost productivity, and heighten collaboration.
Features
Daily Feed
Daily Feed is here! The new tab on the left hand side provides an overview of what you previously worked on, currently are working on and potential blockers. You can also see your team's Daily Feed too!
Within the ‘currently working on’ section you will see these helpful tags we’ve added, where if you are needed for a code review it will appear as well as if you are working on an issue that is blocking another and if you are needed for your input for an estimate. For the blocked section, we are providing issues that you may be blocked by, your issues that need code revision etc.
Sprint insights
Now along with your Sprint burndown chart, at a glance, you can
- Predict the likelihood of your team meeting your Sprint goals
- Identify bottlenecks and areas for improvement that could potentially get in the way of your Sprint goals
- Make data-driven decisions to adjust your sprint goals.
- Provide transparency for your stakeholders to easily access your team's Sprint progress
Dynamic Productivity Recommendations
This feature empowers developers and teams with intelligent insights to enhance their codebase operations and improve productivity. Say goodbye to the guesswork on improving your Issues completion and PR practices and hello to automated, data-driven suggestions that elevate your development workflow.
Notion Integration
Users can now paste a share link for a Notion page and have a document preview displayed in Zenhub. We often see users sharing Notion links within Zenhub Issues, Epics or Comments and wanted to introduce a more informative experience. With the new Notion Previews, users will be able to see the document title, author, created and edited date all within Zenhub. Check the docs to learn how to configure this integration.
Open Pull Request links in GitHub
We've introduced a setting that allows a user to enable PRs to open directly in GitHub from Zenhub. We've had customer feedback from both internal and external teams around this feature and appreciated the flexibility it brings
Phone Home metrics for ZHE VM
We have automated the collection of the admin usage report as well as some other metrics on ZHE VM. These metrics are not sensitive, are stored securely and will be used to enhance our support capabilities. As this feature requires a connection to AWS, please reach out to enterprise@zenhub.com to enable this, or if you have any questions or concerns about this feature.
Security Fixes
- Package security updates fixing critical and high CVE
Bug Fixes
- Resolved a problem that caused the Chrome Web Store to reject publishing the browser extension due to additional requirements for Manifest V3.
- Fixed a bug causing existing workspaces to sometimes not be found when using the browser extension in GitHub
- Fixed a bug that causes the admin usage report not to return any results
Changes
- With this release, our old Board is no longer available. We've worked hard over the past few months to make Board 2.0 better in every way (see recent updates), and with ZHE 4.1 it is now the de facto standard.
- PostgreSQL as been upgraded from
11.16
to15.4
- K3s has been upgraded from
v1.24.13+k3s1
tov1.26.8+k3s1
- Kubernetes has been upgraded from
v1.24.13
tov1.26.8
- The built-in upgrade bundle rollback feature has been deprecated. VM or disk snapshots should be used to revert to a previous version in case of an upgrade failure.
- Zenhub Enterprise for VM upgrade instructions. have been updated for clarity and to add the use of the
tmux
terminal multiplexer to protect the upgrade from possible SSH disconnects.
Known Issues
- Authentication fails when self-signed TLS certificates are used
- Logrotate image can be cleaned up by K8s garbage collector, causing failed log rotation jobs that consume system resources
VM Embedded Component Versions
Component | Version |
---|---|
Ubuntu | 22.04.2 |
K3s | v1.26.8+k3s1 |
Kubernetes | v1.26.8 |
Kustomize | v4.5.3 |
Fluentd | v1.16.2-debian-1.0 |
Postgresql | 15.4 |
MongoDB | 4.4.13 |
RabbitMQ | 3.8.31 |
Redis | 7.0.5 |
PgBouncer | 1.20.1 |
Important Upgrade Instructions for Administrators
Zenhub Enterprise for Virtual Machine
-
You must be running 4.0.X to perform the upgrade to ZHE 4.1.0
-
For users currently running Zenhub Enterprise, contact our team for a download link for the 4.1.0 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 inkustomization.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.0
- name: kraken-extension
newName: us.gcr.io/zenhub-public/kraken-extension
newTag: zhe-4.1.0
- name: kraken-zhe-admin
newName: us.gcr.io/zenhub-public/kraken-zhe-admin
newTag: zhe-4.1.0
- name: raptor-backend
newName: us.gcr.io/zenhub-public/raptor-backend
newTag: zhe-4.1.0
- name: toad-backend
newName: us.gcr.io/zenhub-public/toad-backend
newTag: zhe-4.1.0
- name: sanitycheck
newName: us.gcr.io/zenhub-public/sanitycheck
newTag: zhe-4.1.0
- name: devsite
newName: us.gcr.io/zenhub-public/devsite
newTag: zhe-4.1.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
andsanitycheck
jobs so they may be recreated without errors:
Make sure the status of the jobs are
Complete
and notRunning
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. Dat...
Zenhub Enterprise 4.0.2
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.2 supports GitHub Enterprise versions: 3.8
, 3.9
, 3.10
What's new in Zenhub Enterprise 4.0.2
We are thrilled to announce the release of Zenhub Enterprise 4.0.2, packed with a host of exciting new features designed to optimize your workflow, boost productivity, and heighten collaboration.
Features
Zenhub Platform
New authentication providers
To leverage platform features, Zenhub now supports authentication with Email/Password, IBM W3ID, Azure Active Directoryl, LDAP and SAML. Users can sign up using these methods without connecting to a GitHub account, which means you can save costs on unnecessary GitHub seats for non-technical team members.
Zenhub Issues
Zenhub Issues enables teams to work together in Zenhub without a GitHub account. Zenhub Issues function similarly to GitHub Issues but are a separate entity from GitHub. These are great for team members who don’t use GitHub or for tracking non-development tasks.
Converting Zenhub Issues to GitHub Issues
You can now convert Zenhub Issues to GitHub Issues. This enables users not using GitHub to create issues that may later evolve into development tasks.
Disconnecting GitHub Accounts from Zenhub
You can disconnect your GitHub account by going to Account Management > Settings > Connected Accounts.
Classic GitHub Projects Importer for Platform Users
For users migrating from GitHub Projects to Zenhub, we've extended the capabilities of our Classic GitHub Projects Importer. Smoothly import pipelines, repositories, and issues from existing classic GitHub project boards into your Zenhub workspace.
Onboarding
Organization access requests for companies and teams
Zenhub Organizations are now visible at the time of onboarding to users signing up with the same email domain as the Zenhub Organization creator. Users associated by domain no longer need to be invited to join a new organization.
“Allowed Domains” for organization access
The “Allowed Domains” feature enables organizations to specify the domains from which they accept requests, providing an extra layer of security and speeding up user onboarding.
New permissions system
Now, in Zenhub, existing GitHub organization admins are automatically granted Zenhub organization admin status. All other teammates will receive “member” status.
Projects flyover
Every project on the roadmap now has a dedicated flyover, which provides a description of the project and shows the contributors who created and closed the project.
Board enhancements
Milestones support for Board 2.0
Zenhub has brought back milestone support to Board 2.0. You can now filter issues by Milestone or with no Milestones, bulk edit, and multi-select Milestones, add/remove Milestones from issues, and Show/Hide Milestones from issue cards.
Board 2.0 Improvements
Board 2.0 now includes a smoother drag-and-drop functionality, multi-column pipelines, and a warning message when moving issues from normal priority to high priority.
Saved Views
The saved view feature enables you to apply a set of filters to your board and save that board configuration as a Saved View for easy access.
Integrations
Figma, Miro & Loom Embeds
Boost collaboration by embedding Figma, Miro, or Loom files into Zenhub. Miro and Figma embeds in Zenhub display a preview of the content from the file. Loom embeds enable users to watch full videos inside Zenhub – no more tab switching!
Figma & Miro embeds are only available for Zenhub Issues, Zenhub Epics, and Zenhub Comments.
These integrations will not work in an air-gapped environment.
Extras
GitHub Productivity Insights
GitHub Productivity Insights is a new dashboard that gives you quick views of your team’s performance metrics and compares them to the top-performing teams in GitHub. The dashboard also includes tailored suggestions for how to enhance your team’s performance.
Security Fixes
- Package security updates
Bug Fixes
- Fixed a bug causing the chrome extension url to be incorrectly set
Changes
- No changes in the 4.0.2 patch release
Known Issues
- The Chrome Web Store may reject publishing the browser extension due to additional requirements for Manifest V3. This is resolved in Zenhub Enterprise 4.1.
- 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
Component | Version |
---|---|
Ubuntu | 22.04.2 |
K3s | v1.24.13+k3s1 |
Kubernetes | v1.24.13 |
Kustomize | v4.5.3 |
Fluentd | v1.16.2-debian-1.0 |
Postgresql | 11.16 |
MongoDB | 4.4.13 |
RabbitMQ | 3.8.31 |
Redis | 7.0.5 |
PgBouncer | 1.17.0 |
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 or 4.0.1 to perform the upgrade to ZHE 4.0.2.
-
For users currently running Zenhub Enterprise, contact our team for a download link for the 4.0.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.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 inkustomization.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.2
- name: kraken-extension
newName: us.gcr.io/zenhub-public/kraken-extension
newTag: zhe-4.0.2
- name: kraken-zhe-admin
newName: us.gcr.io/zenhub-...