Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Fix: #662 #680

Closed
wants to merge 1 commit into from
Closed

Fix: #662 #680

wants to merge 1 commit into from

Conversation

shiv4nk4r
Copy link

@shiv4nk4r shiv4nk4r commented Jul 2, 2024

Description

Fixes #662

Type of change

  • Chore (changes which are not directly related to any business logic)

What's Changed

  • Added version.tsx file in frontend/app/src/components/ui folder. Version exposes an enum, type and the component itself, the enum is used to drive the theme, defaulted to dark theme, can be updated in future.
  • Added .env file in fronted/app/src folder with content VITE_VERSION=v1.0.0
  • Modified the frontend/components/molecules/nav-bar file to include the new version component

Dark Theme
Light Theme

Copy link

vercel bot commented Jul 2, 2024

@shiv4nk4r is attempting to deploy a commit to the Hatchet Team on Vercel.

A member of the Team first needs to authorize it.

@abelanger5
Copy link
Contributor

Hey @shiv4nk4r, thanks for the PR! I think it would be better if the version was being returned from the /api/v1/meta endpoint, which is already being used and can be accessed via the useApiMeta hook. While this can mean that the frontend gets out of sync with the API and engine, the reason for this issue is that we'd like to confirm the version of the API and engine (typically not the frontend).

Another option would be to still have the frontend version, and display a warning to the user if the frontend version is out of sync with the API version.

@shiv4nk4r
Copy link
Author

@abelanger5 thanks for the feedback.
I would implement the version from the API, now coming to the frontend part this would require the maintenance of the frontend version every time there is a new deployment in the backend.

@abelanger5
Copy link
Contributor

now coming to the frontend part this would require the maintenance of the frontend version every time there is a new deployment in the backend

Yes I agree, this should be out-of-scope for now. At some point we may want to warn if there's too high of a version skew but we don't have a policy around this yet, so I think just the API version will suffice.

@steebchen
Copy link
Collaborator

I think from the UI perspective it would be better suited to go into the settings, as you only need to see the version in rare cases. For example, we can put it in /tenant-settings/overview.

@shiv4nk4r
Copy link
Author

I think from the UI perspective it would be better suited to go into the settings, as you only need to see the version in rare cases. For example, we can put it in /tenant-settings/overview.

We would need to update our docs for this in order for the user to know that there is something as version inside.

@shiv4nk4r
Copy link
Author

think it would be better if the version was being returned from the /api/v1/meta endpoint,

Can I get some documentation for this ?

@abelanger5 abelanger5 closed this Nov 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

show Hatchet version in the web UI
3 participants