chore: git tag - ui components for tagging release#39508
Conversation
WalkthroughThis pull request introduces new functionalities to support a Git-based release process. It adds constants and messages for release modals, new React components to display the latest commit information, and UI elements for release operations such as a release notes input and a radio group for selecting version types. Additionally, it incorporates a custom hook to fetch the latest commit details, along with new API request functions, TypeScript types, Redux actions, selectors, and state updates. Overall, these changes extend Git artifact management and streamline the release workflow. Changes
Sequence Diagram(s)sequenceDiagram
participant C as Component
participant H as useLatestCommit Hook
participant D as Redux Dispatch
participant R as API (fetchLatestCommitRequest)
participant S as Redux Store
participant Sel as Selector (selectLatestCommitState)
C->>H: Invoke fetchLatestCommit()
H->>D: Dispatch fetchLatestCommitInitAction
D->>R: Call fetchLatestCommitRequest(artifactType, branchedArtifactId)
R-->>D: Return commit data (or error)
D->>S: Dispatch success or error action
S->>Sel: Update latestCommit state
C->>Sel: Retrieve updated commit details
sequenceDiagram
participant T as TabRelease Component
participant LI as LatestCommitInfo Component
participant RVR as ReleaseVersionRadioGroup Component
participant RNI as ReleaseNotesInput Component
T->>LI: Render latest commit info via useLatestCommit hook
T->>RVR: Render radio group for release version selection
RVR-->>T: onVersionChange event triggers state update
T->>RNI: Render input for release notes
RNI-->>T: onTextChange event updates notes state
T->>T: Validate releaseVersion & releaseNotes
T->>T: Call handleClickOnRelease on release button click
Suggested labels
Suggested reviewers
Poem
✨ Finishing Touches
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Actionable comments posted: 9
🧹 Nitpick comments (5)
app/client/src/git/components/OpsModal/OpsModalView.tsx (1)
57-72: Add analytics tracking for the Release tab.The handleTabKeyChange function tracks analytics for Deploy and Merge tabs, but not for the new Release tab. Consider adding a similar tracking for consistency.
const handleTabKeyChange = useCallback( (tabKey: string) => { if (tabKey === GitOpsTab.Deploy) { AnalyticsUtil.logEvent("GS_DEPLOY_GIT_MODAL_TRIGGERED", { source: `${tabKey.toUpperCase()}_TAB`, }); } else if (tabKey === GitOpsTab.Merge) { AnalyticsUtil.logEvent("GS_MERGE_GIT_MODAL_TRIGGERED", { source: `${tabKey.toUpperCase()}_TAB`, }); + } else if (tabKey === GitOpsTab.Release) { + AnalyticsUtil.logEvent("GS_RELEASE_GIT_MODAL_TRIGGERED", { + source: `${tabKey.toUpperCase()}_TAB`, + }); } toggleOpsModal(true, tabKey as GitOpsTab); }, [toggleOpsModal], );app/client/src/git/components/OpsModal/TabRelease.tsx (1)
48-55: Add user feedback for disabled state.Add a tooltip or other visual indication to explain why the Release button is disabled when either release version or notes are missing.
<Button isDisabled={isReleaseDisabled} onClick={handleClickOnRelease} size="md" + tooltip={isReleaseDisabled ? "Please provide both version and release notes" : ""} > {TAB_RELEASE.RELEASE_BTN} </Button>app/client/src/git/components/ReleaseVersionRadioGroup/ReleaseVersionRadioGroupView.tsx (3)
28-33: Handle edge cases in version change effect.The effect runs when nextVersion changes, but should handle the initial null value elegantly.
useEffect( function releaseVersionChangeEffect() { - onVersionChange(nextVersion); + // Only notify parent when we have a valid version + if (nextVersion) { + onVersionChange(nextVersion); + } }, [nextVersion, onVersionChange], );
35-37: Use type guard for radio value.The current type casting assumes the value is always one of the ReleaseType values, which might not be true.
const handleRadioChange = useCallback((value: string) => { - setReleaseType(value as ReleaseType); + // Ensure value is a valid ReleaseType + if (value === "major" || value === "minor" || value === "patch") { + setReleaseType(value); + } }, []);
52-52: Simplify RadioGroup value handling.The nullish coalescing is unnecessary since releaseType is initialized with "patch" and never set to null.
- value={releaseType ?? undefined} + value={releaseType}
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (10)
app/client/src/git/ce/constants/messages.tsx(1 hunks)app/client/src/git/components/LatestCommitInfo/LatestCommitInfoView.tsx(1 hunks)app/client/src/git/components/LatestCommitInfo/index.tsx(1 hunks)app/client/src/git/components/OpsModal/OpsModalView.tsx(2 hunks)app/client/src/git/components/OpsModal/TabRelease.tsx(1 hunks)app/client/src/git/components/ReleaseNotesInput/index.tsx(1 hunks)app/client/src/git/components/ReleaseVersionRadioGroup/ReleaseVersionRadioGroupView.tsx(1 hunks)app/client/src/git/components/ReleaseVersionRadioGroup/index.tsx(1 hunks)app/client/src/git/constants/enums.ts(1 hunks)app/client/src/git/ee/constants/messages.tsx(1 hunks)
✅ Files skipped from review due to trivial changes (2)
- app/client/src/git/ee/constants/messages.tsx
- app/client/src/git/ce/constants/messages.tsx
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: client-check-cyclic-deps / check-cyclic-dependencies
- GitHub Check: client-lint / client-lint
- GitHub Check: client-prettier / prettier-check
🔇 Additional comments (8)
app/client/src/git/constants/enums.ts (1)
10-10: Clean addition of a new GitOpsTab enum value.The addition of the 'Release' enum member follows the established pattern and will be used for the new release tab functionality.
app/client/src/git/components/OpsModal/OpsModalView.tsx (2)
96-102: Tab implementation for Release looks good.The implementation follows the existing pattern for tabs in the modal.
107-107: TabRelease rendering implementation is correct.The conditional rendering of the TabRelease component based on the selected tab follows the established pattern.
app/client/src/git/components/ReleaseNotesInput/index.tsx (1)
11-29: Component implementation LGTM.The component is well-structured with proper props handling and default values.
app/client/src/git/components/LatestCommitInfo/LatestCommitInfoView.tsx (1)
5-8: Good styling approach.The styled component approach with explicit color variables matches project conventions.
app/client/src/git/components/OpsModal/TabRelease.tsx (2)
39-40:Details
✅ Verification successful
Check for required props in LatestCommitInfo.
No props are passed to the LatestCommitInfo component. Check if it requires explicit props or gets them from context.
🏁 Script executed:
#!/bin/bash # Check the LatestCommitInfo component implementation echo "Checking LatestCommitInfo implementation for required props:" if [ -f "app/client/src/git/components/LatestCommitInfo/index.tsx" ]; then cat app/client/src/git/components/LatestCommitInfo/index.tsx fiLength of output: 631
Review Verification: LatestCommitInfo Component Props Verified
The investigation confirms that the
LatestCommitInfocomponent does not require any props to be passed from its parent. It internally rendersLatestCommitInfoViewwith hardcoded property values. Therefore, the current usage inapp/client/src/git/components/OpsModal/TabRelease.tsxis correct and requires no modification.
30-30:Details
❓ Verification inconclusive
Add implementation for release handler.
The
handleClickOnReleasefunction is currently empty. It should include the logic to execute the release process.
🏁 Script executed:
#!/bin/bash # Check if there are other similar handlers in the codebase echo "Looking for similar handler implementations in Git components:" rg -A10 "handleClickOn\w+" app/client/src/git/components/ --type ts --type tsx | grep -v TabRelease.tsxLength of output: 268
Action Required: Implement the Release Handler Logic
The
handleClickOnReleasefunction inapp/client/src/git/components/OpsModal/TabRelease.tsxremains empty. We attempted to locate similar handler implementations in other Git components but encountered issues (an "unrecognized file type: tsx" error) during the automated search, and no conclusive pattern was identified. Please double-check similar handlers manually if needed and add the appropriate release process logic in this function.app/client/src/git/components/ReleaseVersionRadioGroup/ReleaseVersionRadioGroupView.tsx (1)
22-26: Good handling of semver version incrementing.The use of useMemo with proper dependency array and null checks before using the semver library is well-implemented.
app/client/src/git/components/ReleaseVersionRadioGroup/index.tsx
Outdated
Show resolved
Hide resolved
app/client/src/git/components/ReleaseVersionRadioGroup/ReleaseVersionRadioGroupView.tsx
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
app/client/src/git/components/LatestCommitInfo/index.tsx (1)
5-16: Component should handle loading and error states.The component retrieves data from the useLatestCommit hook but doesn't handle potential loading or error states. This could lead to a poor user experience when commits are being fetched or when errors occur.
function LatestCommitInfo() { - const { latestCommit } = useLatestCommit(); + const { latestCommit, loading, error } = useLatestCommit(); + + if (loading) { + return <div>Loading latest commit...</div>; + } + + if (error) { + return <div>Failed to load latest commit</div>; + } return ( <LatestCommitInfoViewapp/client/src/git/requests/fetchLatestCommitRequest.ts (1)
1-1: Remove unnecessary eslint-disable commentThe eslint-disable comment for unused variables appears unnecessary as there are no unused variables in this file.
-/* eslint-disable @typescript-eslint/no-unused-vars */
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (10)
app/client/src/git/components/LatestCommitInfo/LatestCommitInfoView.tsx(1 hunks)app/client/src/git/components/LatestCommitInfo/index.tsx(1 hunks)app/client/src/git/hooks/useLatestCommit.ts(1 hunks)app/client/src/git/requests/fetchLatestCommitRequest.ts(1 hunks)app/client/src/git/requests/fetchLatestCommitRequest.types.ts(1 hunks)app/client/src/git/store/actions/fetchLatestCommitActions.ts(1 hunks)app/client/src/git/store/gitArtifactSlice.ts(2 hunks)app/client/src/git/store/helpers/initialState.ts(1 hunks)app/client/src/git/store/selectors/gitArtifactSelectors.ts(1 hunks)app/client/src/git/store/types.ts(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- app/client/src/git/components/LatestCommitInfo/LatestCommitInfoView.tsx
🧰 Additional context used
🧠 Learnings (1)
app/client/src/git/requests/fetchLatestCommitRequest.types.ts (1)
Learnt from: brayn003
PR: appsmithorg/appsmith#37984
File: app/client/src/git/requests/fetchAutocommitProgressRequest.types.ts:3-7
Timestamp: 2024-12-05T11:02:12.715Z
Learning: When reviewing TypeScript interfaces for API responses in `app/client/src/git/requests/`, note that even if interfaces appear identical, they may be intentionally kept separate because the API responses might change independently in the future.
⏰ Context from checks skipped due to timeout of 90000ms (4)
- GitHub Check: client-prettier / prettier-check
- GitHub Check: client-build / client-build
- GitHub Check: client-lint / client-lint
- GitHub Check: client-check-cyclic-deps / check-cyclic-dependencies
🔇 Additional comments (17)
app/client/src/git/components/LatestCommitInfo/index.tsx (1)
5-16: Consider accepting props to override hook data for testing.The component currently only uses data from the hook. For better testability and flexibility, consider accepting optional props that can override the hook data.
-function LatestCommitInfo() { +interface LatestCommitInfoProps { + authorName?: string; + committedAt?: string; + hash?: string; + message?: string; +} + +function LatestCommitInfo({ + authorName: authorNameProp, + committedAt: committedAtProp, + hash: hashProp, + message: messageProp, +}: LatestCommitInfoProps = {}) { const { latestCommit } = useLatestCommit(); return ( <LatestCommitInfoView - authorName={latestCommit?.authorName ?? null} - committedAt={latestCommit?.committedAt ?? null} - hash={latestCommit?.hash ?? null} - message={latestCommit?.message ?? null} + authorName={authorNameProp ?? latestCommit?.authorName ?? null} + committedAt={committedAtProp ?? latestCommit?.committedAt ?? null} + hash={hashProp ?? latestCommit?.hash ?? null} + message={messageProp ?? latestCommit?.message ?? null} /> ); }app/client/src/git/store/helpers/initialState.ts (1)
55-59: LGTM!The latestCommit state property follows the established pattern for API responses with value, loading, and error fields.
app/client/src/git/store/selectors/gitArtifactSelectors.ts (1)
91-95: LGTM!The new selector follows the established pattern and naming convention, placed appropriately after the related commitState selector.
app/client/src/git/requests/fetchLatestCommitRequest.types.ts (2)
3-8: LGTM!The FetchLatestCommitResponseData interface clearly defines the structure for commit information with appropriate string types.
10-11: LGTM!The type alias correctly wraps the response data in the ApiResponse generic type, following the established pattern for API responses.
app/client/src/git/requests/fetchLatestCommitRequest.ts (1)
8-15: LGTM - Clear and concise API request implementationThe function implementation follows best practices for API requests and follows existing patterns in the codebase.
app/client/src/git/store/gitArtifactSlice.ts (2)
144-148: LGTM - Action imports follow existing patternsThe import statement for the latest commit actions follows the established pattern in the file.
213-215: LGTM - Action handlers added appropriatelyThe new action handlers are added in an appropriate location within the git operations section.
app/client/src/git/hooks/useLatestCommit.ts (1)
8-29: LGTM - Well-structured React hookThe hook implementation follows React best practices:
- Proper dependency array in useCallback
- Null checks with fallback values
- Clear return object structure
app/client/src/git/store/types.ts (2)
22-22: LGTM - Appropriate type importType import follows the established pattern in the file.
45-45: LGTM - State property added in logical locationThe latestCommit property is added in a logical position within the interface, maintaining consistency with other related Git operations.
app/client/src/git/store/actions/fetchLatestCommitActions.ts (6)
1-6: Imports look appropriate and well-organized.The file correctly imports the necessary types and helper functions needed for the implementation.
8-10: Clean interface definition.Good job defining a clear, focused interface with a single property for the initialization payload.
12-19: Initialization action correctly implemented.The action properly sets loading state and clears errors at the start of the fetch operation.
20-27: Success action handler looks good.Properly handles the success case by updating the loading state and storing the response data.
29-38: Error action handler implemented correctly.This follows the standard error handling pattern by updating the loading state and capturing the error details.
1-39: Overall implementation follows Redux best practices.The actions follow a consistent pattern for asynchronous operations with clear separation of concerns between init, success, and error states. The TypeScript typing ensures type safety throughout the implementation.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
app/client/src/git/components/ReleaseVersionRadioGroup/index.tsx (3)
10-22: Add support for direct property overrides.The component should allow direct property overrides for testing or custom implementations.
function ReleaseVersionRadioGroup({ onVersionChange = noop, + currentVersion: propCurrentVersion, + releasedAt: propReleasedAt, }: ReleaseVersionRadioGroupProps) { const { latestCommit } = useLatestCommit(); return ( <ReleaseVersionRadioGroupView - currentVersion={latestCommit?.releaseTagName ?? null} + currentVersion={propCurrentVersion ?? latestCommit?.releaseTagName ?? null} onVersionChange={onVersionChange} - releasedAt={latestCommit?.releasedAt ?? null} + releasedAt={propReleasedAt ?? latestCommit?.releasedAt ?? null} /> ); }
13-13: Add error handling for hook usage.The hook may fail to fetch data or encounter errors, which should be handled appropriately.
- const { latestCommit } = useLatestCommit(); + const { latestCommit, error, loading } = useLatestCommit(); + + // Handle loading and error states + if (loading) { + return <div>Loading commit information...</div>; + } + + if (error) { + console.error("Failed to fetch latest commit:", error); + // Consider showing an error message or fallback UI + }
1-25: Add component documentation.Add JSDoc comments to document the component's purpose, props, and behavior.
+/** + * A component that displays radio options for selecting release versions. + * Uses the latest commit information to provide context about the current version. + * + * @param {Object} props - Component properties + * @param {Function} props.onVersionChange - Callback when version selection changes + * @param {string|null} [props.currentVersion] - Override for the current version + * @param {string|null} [props.releasedAt] - Override for the release date + * @returns {JSX.Element} The rendered component + */ function ReleaseVersionRadioGroup({ onVersionChange = noop, }: ReleaseVersionRadioGroupProps) {
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
app/client/src/git/components/ReleaseVersionRadioGroup/index.tsx(1 hunks)app/client/src/git/requests/fetchLatestCommitRequest.types.ts(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
app/client/src/git/requests/fetchLatestCommitRequest.types.ts (1)
Learnt from: brayn003
PR: appsmithorg/appsmith#37984
File: app/client/src/git/requests/fetchAutocommitProgressRequest.types.ts:3-7
Timestamp: 2024-12-05T11:02:12.715Z
Learning: When reviewing TypeScript interfaces for API responses in `app/client/src/git/requests/`, note that even if interfaces appear identical, they may be intentionally kept separate because the API responses might change independently in the future.
⏰ Context from checks skipped due to timeout of 90000ms (5)
- GitHub Check: client-unit-tests / client-unit-tests
- GitHub Check: client-lint / client-lint
- GitHub Check: client-check-cyclic-deps / check-cyclic-dependencies
- GitHub Check: client-build / client-build
- GitHub Check: client-prettier / prettier-check
🔇 Additional comments (4)
app/client/src/git/requests/fetchLatestCommitRequest.types.ts (3)
1-1: LGTM: Appropriate import of ApiResponse type.The import of
ApiResponsetype fromapi/typesis correctly used for wrapping the response data type.
3-10: Interface design looks good.The
FetchLatestCommitResponseDatainterface properly defines the structure for git commit information. All fields are appropriately typed as strings, which aligns with how dates and hashes are typically returned from APIs.
12-13: Type alias follows established pattern.The
FetchLatestCommitResponsetype correctly leverages the genericApiResponsewrapper for the commit data. This follows the established pattern in the codebase for API response typing.app/client/src/git/components/ReleaseVersionRadioGroup/index.tsx (1)
6-8: Update the props interface to include all optional properties.The interface is missing optional properties that are passed to the view component.
interface ReleaseVersionRadioGroupProps { onVersionChange: (version: string | null) => void; + currentVersion?: string | null; + releasedAt?: string | null; }
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
app/client/src/git/components/LatestCommitInfo/LatestCommitInfoView.test.tsx (3)
17-19: Consider more resilient test assertions.The current assertions depend on exact string formatting. This makes tests brittle if component display format changes.
- expect(getByText("Initial commit")).toBeInTheDocument(); - expect(getByText("John Doe committed 2025-03-01")).toBeInTheDocument(); - expect(getByText("abc123")).toBeInTheDocument(); + expect(getByText(/Initial commit/i)).toBeInTheDocument(); + expect(getByText(/John Doe/i)).toBeInTheDocument(); + expect(getByText(/2025-03-01/i)).toBeInTheDocument(); + expect(getByText(/abc123/i)).toBeInTheDocument();
67-79: Add negative assertion for null message test.The test verifies that other fields are displayed when message is null, but doesn't explicitly verify that no message placeholder is shown.
expect(getByText("John Doe committed 2025-03-01")).toBeInTheDocument(); expect(getByText("abc123")).toBeInTheDocument(); + // Verify no message placeholder is displayed + expect(document.body.textContent).not.toContain("Initial commit");
1-94: Consider adding tests for additional edge cases.The current tests cover null values well, but could be expanded to test other edge cases.
Consider adding tests for:
- Empty strings as prop values
- Undefined values
- Very long text values that might affect layout
- Different date formats or localization scenarios
app/client/src/git/components/ReleaseVersionRadioGroup/ReleaseVersionRadioGroupView.tsx (1)
28-33: Consider optimizing the effect dependency arrayThe effect currently runs whenever
nextVersionoronVersionChangechanges. SinceonVersionChangeis likely a stable reference from the parent component or defaulted tonoop, you could consider wrapping it in useCallback in the parent to prevent unnecessary effect runs.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
app/client/src/git/components/LatestCommitInfo/LatestCommitInfoView.test.tsx(1 hunks)app/client/src/git/components/ReleaseNotesInput/index.tsx(1 hunks)app/client/src/git/components/ReleaseVersionRadioGroup/ReleaseVersionRadioGroupView.test.tsx(1 hunks)app/client/src/git/components/ReleaseVersionRadioGroup/ReleaseVersionRadioGroupView.tsx(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- app/client/src/git/components/ReleaseNotesInput/index.tsx
⏰ Context from checks skipped due to timeout of 90000ms (6)
- GitHub Check: perform-test / rts-build / build
- GitHub Check: perform-test / server-build / server-unit-tests
- GitHub Check: client-lint / client-lint
- GitHub Check: client-check-cyclic-deps / check-cyclic-dependencies
- GitHub Check: client-prettier / prettier-check
- GitHub Check: client-build / client-build
🔇 Additional comments (9)
app/client/src/git/components/LatestCommitInfo/LatestCommitInfoView.test.tsx (6)
1-5: Appropriate imports for testing React components.The imports are concise and contain all necessary libraries for React component testing.
6-20: Well-structured test for happy path scenario.The test properly validates that the component correctly displays all commit information when valid props are provided.
22-35: Good null handling test for authorName.The test properly verifies fallback behavior when authorName is null.
37-50: Good null handling test for committedAt.The test properly verifies fallback behavior when committedAt is null.
52-65: Good null handling test for hash.The test properly verifies fallback behavior when hash is null.
81-93: Good comprehensive null handling test.The test correctly verifies component behavior when all props are null.
app/client/src/git/components/ReleaseVersionRadioGroup/ReleaseVersionRadioGroupView.test.tsx (1)
1-72: Well-structured test suite with good coverageThis test file provides comprehensive coverage of the
ReleaseVersionRadioGroupViewcomponent, testing rendering, interaction, and edge cases. The tests verify:
- Initial rendering with correct content
- Version changes when different radio options are selected
- Callback function invocation with proper parameters
- Handling of null values for optional props
Good use of test-ids, role-based queries, and proper test organization.
app/client/src/git/components/ReleaseVersionRadioGroup/ReleaseVersionRadioGroupView.tsx (2)
3-3: Update the import to align with the CE directory structureThe component is within the CE structure, so please change the import to use the CE constants file:
- import { RELEASE_VERSION_RADIO_GROUP } from "git/ee/constants/messages"; + import { RELEASE_VERSION_RADIO_GROUP } from "git/ce/constants/messages";This prevents potential mismatches between the CE and EE codebases.
15-71: Well-implemented component with good type safetyThe component effectively uses React hooks for state management and performance optimization:
useStatefor tracking the selected release typeuseMemofor calculating the next version based on the current version and release typeuseCallbackfor memoizing the change handler- Clear UI structure with appropriate data-testid attributes for testing
The component handles null values appropriately and provides sensible defaults.
## Description - Adds release tab to be used in git ops modal - Release Tab contains LatestCommitInfo, ReleaseVersionRadioGroup and ReleaseNotesInput components Fixes appsmithorg#38808 Fixes appsmithorg#38809 ## Automation /ok-to-test tags="@tag.Module,@tag.Git" ### 🔍 Cypress test results <!-- This is an auto-generated comment: Cypress test results --> > [!TIP] > 🟢 🟢 🟢 All cypress tests have passed! 🎉 🎉 🎉 > Workflow run: <https://github.com/appsmithorg/appsmith/actions/runs/13618810570> > Commit: e7ee385 > <a href="https://internal.appsmith.com/app/cypress-dashboard/rundetails-65890b3c81d7400d08fa9ee5?branch=master&workflowId=13618810570&attempt=1" target="_blank">Cypress dashboard</a>. > Tags: `@tag.Module,@tag.Git` > Spec: > <hr>Sun, 02 Mar 2025 20:57:07 UTC <!-- end of auto-generated comment: Cypress test results --> ## Communication Should the DevRel and Marketing teams inform users about this change? - [ ] Yes - [ ] No <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Introduced a new release management interface featuring a modal that allows users to view the latest commit details, input release notes, and select the release version. - Enabled automatic version suggestion based on the current version and selected release type. - Updated UI messaging to ensure consistent release process notifications. - Added dedicated components for displaying the latest commit information, inputting release notes, and selecting release versions. - Implemented a custom hook for fetching the latest commit details. - **Bug Fixes** - Enhanced error handling and loading states for fetching the latest commit. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
Description
Fixes #38808
Fixes #38809
Automation
/ok-to-test tags="@tag.Module,@tag.Git"
🔍 Cypress test results
Tip
🟢 🟢 🟢 All cypress tests have passed! 🎉 🎉 🎉
Workflow run: https://github.com/appsmithorg/appsmith/actions/runs/13618810570
Commit: e7ee385
Cypress dashboard.
Tags:
@tag.Module,@tag.GitSpec:
Sun, 02 Mar 2025 20:57:07 UTC
Communication
Should the DevRel and Marketing teams inform users about this change?
Summary by CodeRabbit