diff --git a/content/author/Harsh-Rao.md b/content/author/Harsh-Rao.md
index ed5909b..331c2f5 100644
--- a/content/author/Harsh-Rao.md
+++ b/content/author/Harsh-Rao.md
@@ -1,10 +1,10 @@
+++
-title = "Aman Asrani"
-image = "/images/authors/Aman_Asrani .JPG"
-description = "Google Summer of Code 2024 @ CircuitVerse"
+title = "Harsh Rao"
+image = "/images/authors/ThatDeparted2061_Harsh_Rao.png"
+description = "Google Summer of Code 2025 @ CircuitVerse"
+++
-Google Summer of Code 2024 @ CircuitVerse || Electronics and Communication Undergraduate at Birla Institute of Technology and Sciences Pilani, Goa Campus || Class of 2027
+Google Summer of Code 2025 @ CircuitVerse || Electronics and Communication Undergraduate at Birla Institute of Technology and Sciences Pilani, Goa Campus || Class of 2027
-[](www.linkedin.com/in/harsh-rao-81a0581b0)
+[](https://www.linkedin.com/in/harsh-rao-81a0581b0)
[](https://github.com/ThatDeparted2061)
\ No newline at end of file
diff --git a/content/posts/Harsh_Rao_2025_final_report.md b/content/posts/Harsh_Rao_2025_final_report.md
new file mode 100644
index 0000000..f853c94
--- /dev/null
+++ b/content/posts/Harsh_Rao_2025_final_report.md
@@ -0,0 +1,287 @@
+---
+title: "Desktop Application & Vue Frontend Updates: GSoC 2025 Final Report"
+date: 2025-08-31T14:04:00+05:30
+author: Harsh Rao
+type: post
+---
+
+
+
+**Hey Everyone ๐**,
+
+Welcome to my final blog for Google Summer of Code 2025 for the project **Desktop Application & Vue Frontend Updates**. At the begining of each heading you can see `Deliverable`, which gives information for users to know about the feature with no dev-terms(or very less at best ๐). For the dev side, read on!
+
+### What is the Project about ๐ฅโจ
+---
+
+> **[_Desktop Application & Vue Frontend Updates:_](https://summerofcode.withgoogle.com/programs/2025/projects/RLcXZOiF)
+> The project works on the Vue Simulator and aims at completing the vue-simulator. We have achieved several milestones like Authentication model, a beautiful Release Pipeline for Tauri simulator, version sync for v0 and v1, a brand new Testbench UI and best of all pushed vue-simulator to production. Let's dive into them right away !!**
+
+## Major statures that have been added and merged include:
+- ๐ Pushing the Vue-Simulator to production
+- ๐ Authentication model for Tauri Simulator
+- ๐ Conventional-commits workflow
+- โก Release Pipeline for Tauri Simulator
+- ๐จ An improved Testbench UI/UX
+- ๐ Legacy feature sync to v0 and v1
+
+---
+
+[Project Board
](https://github.com/orgs/CircuitVerse/projects/43/views/2)
+
+---
+# 1. Pushing Vue-Simulator to Production
+---
+**Deliverable:** We have finally pushed the vue-simulator to production ๐. We faced a lot of tricky problems along the way but finally after 4 GSoC projects we are here with vue-simulator in Production. The users can use legacy simulator by just clicking on the simulator at the homepage (URL - `https://circuitverse.org/simulator`). For using vue simulator they need to change the URL to `https://circuitverse.org/simulatorvur` which is equivalent to `https://circuitverse.org/simulatorvue?simver=v0`. This sets the `v0` (base) version for vue-simulator. Users can also change the URL to `https://circuitverse.org/simulatorvue?simver=v1`, this sets the version to `v1`. We will be using `v1` to rollout the beta updates for new features ๐งช, after thorough testing and positive user response ๐ we'll move those updates to `v0`. Users can freely choose to work on either of the three versions: `legacy`, `v0`, `v1`. The working of the Embed view can be seen in the video attached below. ๐ฅ
+
+---
+
+**Let's tape the tale ๐:** Pushing the vue-simulator to production has been the biggest objective for this project. The vision of vue-simulator being giving users option to use the various versions at will gave rise to a lot of contingencies โก. Let's start with the first major bug ๐ we faced:
+
+## 1A. The Embed-Vue failure โ [#643](https://github.com/CircuitVerse/cv-frontend-vue/issues/643)
+
+When a user saves a circuit it can be viewed in the Dashboard ๐. When going into the Embed view i.e. when we click on `more` under a circuit we are directed to another page where we see the Embed view. The issue was that the paths were only handled properly for the legacy simulator causing the whole vue-simulator being loaded in the Embed area instead of just a lighter version of the simulator like how it is meant to be for the embedded format. To fix this we had to really delve into the codebase ๐ ๏ธ. Here on is the crux of the situation and how we tackled it.
+
+#### Problem โ
+
+- The `simulatorVersion` was not stored as a separate column in the database ๐๏ธ.
+- Many older projects did not have `simulatorVersion` defined at all, since they were created using the legacy simulator ๐ฐ๏ธ.
+- Because of this, we could not reliably read the field directly without risking errors โ ๏ธ or breaking compatibility.
+
+#### Solution โ
+
+**Step 1:** Extract the simulator version from project data ๐
+We added logic in the **Project model** to safely read `simulatorVersion` from the JSON field.
+- If the field exists, we use its value.
+- If it does not exist (as in legacy projects), we default to `"legacy"`.
+
+This gave us a consistent way to determine whether a project was created with the new Vue simulator or the old legacy one.
+
+**Step 2:** Add a helper method to detect Vue simulator projects ๐
+In the model, we introduced a method that checks the simulator version and returns whether the project is a Vue simulator project or not.
+- Vue simulators are identified by versions `v0` and `v1`.
+- Legacy simulators fall back to the default `"legacy"` tag.
+
+**Step 3:** Decide the embed path in the controller โ๏ธ
+In the **Project controller**, we used the helper method to set the correct embed path.
+- If the project uses Vue simulator, we assign the Vue embed path.
+- Otherwise, we assign the legacy embed path.
+
+This kept the decision-making clean and consistent.
+
+**Step 4:** Render the correct simulator in the view ๐ผ๏ธ
+In the **show page**, instead of hardcoding the iframe path, we used the path determined by the controller.
+This ensures that the correct simulator (legacy or Vue) is embedded based on the projectโs version.
+
+#### Why this approach works ๐ก
+
+- โ
It supports both old and new projects without breaking anything.
+- โ
It avoids errors when `simulatorVersion` is missing.
+- โ
It centralizes the version-handling logic inside the model, keeping the controller and view simple.
+- โ
It makes the application future-proof ๐ฎ.
+
+**Here is the working of Embed ๐ฅ**
+
+{{< video src="/videos/Harsh_Rao/Embed.mp4" controls=true preload=true >}}
+
+## 1B. The Docker Failure ๐ณโ
+
+For Pushing the vue-simulator we needed to change the old hash pointing to the vue-submodule in the primary codebase to the new hash pointing to the current vue-submodule. This step in theory was supposed to be just 2 steps:
+- **Step 1:** `cd` into the `cv-frontend-vue` submodule from the `master` and use `git branch` to switch to main
+- **Step 2:** Raise the PR for it.
+
+But the technicalities of the process overshadowed us and we ran straight into a wall. The Docker publish image workflow was failing! ๐จ It had to pass, else we couldn't merge the PR ([PR #6012](https://github.com/CircuitVerse/CircuitVerse/pull/6012)). Now we had to review and fix it as soon as possible. This turned out to be trickier than we thought. It earlier seemed like just an issue due to missing `v0` in the `outdir`. We tried fixing it that way but failed. Finally, after a lot more debugging, this is how we solved it.
+
+**Problem Statement:** Docker build failed with "not found" error when copying Vue simulator files from `/public/simulatorvue/`.
+**Root Cause:** Vite config used relative path `../public/simulatorvue/` with undefined `DESKTOP_MODE`, causing unpredictable build output location.
+**Solution:** ([PR #6061](https://github.com/CircuitVerse/CircuitVerse/pull/6061))
+- Created explicit output directory `/output/simulatorvue/`
+- Set `DESKTOP_MODE=false` for consistent Vite behavior
+- Added fallback copy logic to handle different output paths
+
+```yml
+# In simulator_vue_build stage:
+RUN mkdir -p /output/simulatorvue
+ENV DESKTOP_MODE=false
+RUN npm run build
+RUN cp -r public/simulatorvue/* /output/simulatorvue/ || cp -r ../public/simulatorvue/* /output/simulatorvue/
+
+# In final stage:
+COPY --from=simulator_vue_build /output/simulatorvue/ /usr/src/app/public/simulatorvue
+```
+# 2. Authentication Model for Web and Tauri Simulator ๐ช๐
+---
+**Deliverable:** Added an Authentication model to Tauri Simulator. For the Tauri simulator the users now will face an Authentication model specifically made for the application. They only have to login once, their profiles will be stored up until they themselves log out from the application. โ
+
+---
+
+**Technical Tale:** The reason we needed a separate Authentication model for vue simulator is because of Tauri. Earlier we were simply changing the `path` in the `URL` to direct to the Login page of Circuitverse for Authentication. This particular method fails for the Tauri simulator because:
+- It is a standalone simulator with no connection to the primary codebase. ๐ฅ๏ธ
+- We want the Tauri simulator to also work when user is offline. ๐โ
+- We cannot redirect links like we do in web in Tauri. ๐๐ซ
+
+To answer those needs, it was the need of the hour to create an authentication model for the vue-simulator and so did we deliver. The authentication system in the CircuitVerse frontend is built using **Vue 3 with TypeScript**.
+It handles both **login** and **signup** flows via API requests to the CircuitVerse backend. ๐
+
+- **Frontend Tech**: Vue 3 + TypeScript + Pinia (Auth Store) ๐ ๏ธ
+- **API Layer**: Fetch (with [Tauri HTTP plugin](https://tauri.app)) ๐
+- **Backend Endpoints**:
+ - `POST /api/v1/auth/login` ๐
+ - `POST /api/v1/auth/signup` ๐
+
+## 2A. Authentication Flow ๐
+
+1. **Auth Modal Handling** ๐ช
+ - A modal component (`authModal`) is used to toggle between **login** and **signup**. ๐
+ - Users can switch modes dynamically without leaving the page. ๐
+
+2. **Form Validation** โ
+ - Basic client-side validation rules:
+ - Required fields must not be empty. ๐ซ
+ - Valid email format (`/.+@.+\..+/`). ๐ง
+ - Password must be at least 6 characters. ๐
+
+3. **Request Building** ๐ ๏ธ
+ - Depending on mode (`isLoginMode`), the request body changes:
+ - **Login**: `{ email, password }` ๐
+ - **Signup**: `{ name, email, password }` ๐
+ - Requests are sent as JSON with appropriate headers. ๐ค
+
+4. **API Communication** ๐
+ - Uses the `fetch` function (via Tauri plugin when inside desktop app).
+ - On success, the backend responds with an **auth token**. ๐ท๏ธ
+
+5. **State Management** ๐๏ธ
+ - The received token is stored in the **Auth Store** (`useAuthStore()`).
+ - Store handles:
+ - Saving token ๐พ
+ - Fetching user ID ๐
+ - Sign-out / token removal ๐ช
+
+6. **Error Handling** โ ๏ธ
+ - Common error responses:
+ - `401 Unauthorized` โ Invalid credentials โ
+ - `404 Not Found` โ User does not exist ๐
+ - `409 Conflict` โ User already exists โ๏ธ
+ - `422 Unprocessable Entity` โ Invalid input ๐
+ - Errors are shown to the user via a **snackbar** notification system. ๐
+
+These are some of the snaps of the Authentication model and its working video-
+
+
+
+
+{{< video src="/videos/Harsh_Rao/Authentication.mp4" controls=true preload=true >}}
+
+# 3. Conventional-Commit ๐
+---
+**Deliverable:** Now the commits to the cv-frontend-vue require to follow [`conventional-commits`](https://www.conventionalcommits.org/en/v1.0.0/) ๐. This is to add more meaning to commits for both humans and machines ๐ค.
+
+---
+**Why and How we did it:** We have added `conventional-commit` to the workflows, ensuring smoothness in the Automation for version tag generation ๐. This also helps give the maintainers a good holistic view of where the simulator stands at, in turn helping them choose the `minor`, `patch`, or `major` version bump in the Release ๐ฏ. ([PR #656](https://github.com/CircuitVerse/cv-frontend-vue/pull/656))
+From here on, the commits made by everyone would need to follow the [conventional-commits](https://www.conventionalcommits.org/en/v1.0.0/) โ
. Some of them are as follows:
+
+#### Types ๐ ๏ธ
+
+The **type** indicates the nature of the change:
+
+- **feat**: โจ A new feature
+- **fix**: ๐ A bug fix
+- **docs**: ๐ Documentation changes
+- **style**: ๐จ Code style/formatting changes (no logic change)
+- **refactor**: ๐ Code changes that neither fix a bug nor add a feature
+- **perf**: โก Performance improvements
+- **test**: ๐งช Adding or updating tests
+- **chore**: ๐ ๏ธ Build process, tooling, or maintenance tasks
+- **ci**: ๐ค CI/CD related changes
+# 4. Automating Cross-Platform Desktop Releases ๐๐ป
+---
+**Deliverable:** An Automated Release pipeline has been added to the vue-simulator. With one click by the maintainers a Release is created and assets (Artefacts for `Windows`, `Mac` and `Linux` subsystems) are attached with the Latest Release under `Releases` heading on cv-frontend-vue primary codebase. There is also another file called `CHANGELOG` that is created, it holds the logs of current and all of the previous Releases. ๐
+
+---
+
+**How we did it? -** One of the key deliverables for the GSoC project was a reliable release pipeline for the CircuitVerse desktop app. We initially explored fully automated tools like semantic-release and release-it!, but they offered less manual control than we needed. The ideal solution needed to balance powerful automation with maintainer oversight. โ๏ธ
+
+The breakthrough was using GitHub Actions' `workflow_dispatch`. This allows us to trigger the release manually, providing input on the version type (major, minor, or patch), giving us the perfect blend of automation and control. This approach culminated in the final workflow that now powers our desktop releases. ๐ฏ
+
+## 4A. The Release Workflow Code ๐ ๏ธ
+The entire process is encapsulated in a single GitHub Actions workflow file. It's composed of two primary jobs: `build-tauri` to compile the application across all platforms, and `create-release` to package and publish the final release. ๐ฆ
+
+## 4B. How It Works ๐ง
+The workflow operates in two sequential jobs:
+**Job 1: `build-tauri`**
+This job is the workhorse, responsible for compiling the application. It uses a matrix strategy to run three parallel jobs, one for each target OS: `ubuntu-latest`, `windows-latest`, and `macos-latest`. This is the key to efficient cross-platform building. ๐
+
+- **Environment Setup:** Each job begins by checking out the code and setting up the required toolchains, like Node.js and Rust. Crucially, it also installs OS-specific dependencies needed for compilation, such as `libwebkit2gtk-4.1-dev` on Ubuntu or `wixtoolset` on Windows. ๐ ๏ธ
+
+- **Dependency Caching:** To dramatically speed up build times on subsequent runs, the workflow caches both the Node.js (`.npm`) and Rust (`.cargo`, `target`) dependency directories. This avoids re-downloading and re-compiling hundreds of packages every time. โก
+
+- **Build & Upload:** The job then runs the `tauri build` command, which creates the native application installers. Once complete, it uses the `actions/upload-artifact` action to save these installers, making them available to the next job in the workflow. ๐ค
+
+**Job 2: `create-release`**
+This job only runs after all three build jobs have completed successfully (`needs: build-tauri`). It handles the final packaging and publishing. ๐ฆ
+
+- **Artifact & Code Aggregation:** It begins by downloading all the build artifacts (the installers for Linux, macOS, and Windows) from the previous job. It also checks out the repository with `fetch-depth: 0` to ensure it has the full git history, which is essential for the next step. ๐
+
+- **Automated Changelog:** The `conventional-changelog-action` scans the git history since the last release tag. Based on conventional commit messages (like `feat:`, `fix:`, etc.), it automatically generates professional, well-formatted release notes. ๐
+
+- **Versioning:** A bash script then determines the new version number. It fetches the latest git tag (e.g., `v1.2.3`), parses it, and increments the version based on the version-bump input (`patch`, `minor`, or `major`) that was provided when the workflow was triggered. ๐ข
+
+- **Publishing:** Finally, using the GitHub CLI, the script creates a new GitHub Release. It tags the commit with the new version, sets the release title, attaches the auto-generated changelog as the release notes, and uploads all the cross-platform installers as release assets. ๐
+
+**The Final Product ([PR #636](https://github.com/CircuitVerse/cv-frontend-vue/pull/636))โจ**
+The result is a beautifully simple and powerful release process. Now, any maintainer can go to the repository's "`Actions`" tab, select the "`Manually Triggered Desktop Release`" workflow, choose whether it's a `major`, `minor`, or `patch` release, and click "Run workflow." ๐ฑ๏ธ
+
+
+
+From there, everything is automated. Within minutes, a new, cross-platform release is published to GitHub, complete with installers for every OS and a professional changelog, ready for our users. This pipeline removes manual effort, eliminates human error, and ensures our releases are consistent and reliable every single time. โ
+
+
+
+{{< video src="/videos/Harsh_Rao/release-pipeline-final.mp4" controls=true preload=true >}}
+# 5. The Artistic new Testbench UI ๐จโจ
+
+This has been the artistic side of the project. We have had the Testbench UI for a while now, up to now it had received 2 major UI revamps during some of the previous GSOC projects. This time we went outside the current colour palette a bit. We have used the classic Circuitverse green with white, which gives it a soft and user-friendly look. ๐๐ค
+
+Here are some snapshots of the new Testbench UI ๐ธ
+
+
+
+
+
+Here is a video showcasing the working of the new Testbench
+
+{{< video src="/videos/Harsh_Rao/Testbench.mp4" controls=true preload=true >}}
+# 6. Legacy version sync to versions v0 and v1 ๐๐
+---
+**Deliverable:** This was a requirement for Versioning of vue-simulator. This is not a new feature but rather a major pillar of versioning. ๐๏ธ
+
+---
+**And what is that major Pillar?** After the previous year's GSOC project on implementing version control, we needed to sync the legacy simulator versions to the versioned folders while syncing the changes in the `src` folder to `v0` and `v1` too. This was carried out in 3 steps. ๐ ๏ธ
+**Step 1:** This step was brute-force copying all of the files from the `src` folder to the versioned directories `v0` and `v1`. ๐
+**Step 2:** Then we compared all of the changes that existed in `src` and not in `v0` and `v1`. We came across many small features that were missing for `src` which needed to be re-written, for eg: the version mismatch dialogue for the vue simulator in `openOffline.vue`. ([PR #599](https://github.com/CircuitVerse/cv-frontend-vue/pull/599)) ๐ ๏ธ
+**Step 3:** This was the part where we tested the result of the change. Since the change built up a massive PR, this step took time and also proved beneficial. We came across a few shortcomings, the major one being the preview circuits for version `v1` going into infinite reload. This was created due to an error that occurred during the feature sync to the `v1` folder. ([PR #647](https://github.com/CircuitVerse/cv-frontend-vue/pull/647)) ๐๐
+
+---
+
+- PR : [Authentication Model](https://github.com/CircuitVerse/cv-frontend-vue/pull/657) ๐โจ
+- PR : [Release Pipelines](https://github.com/CircuitVerse/cv-frontend-vue/pull/636) ๐๐ฆ
+- PR : [Testbench UI/UX](https://github.com/CircuitVerse/cv-frontend-vue/pull/650) ๐จ๐ฅ๏ธ
+- PR : [Versioning PR](https://github.com/CircuitVerse/cv-frontend-vue/pull/599) ๐๐
+- PR : [Conventional commit workflow](https://github.com/CircuitVerse/cv-frontend-vue/pull/656) ๐โ
+- PR : [Infinite loop error](https://github.com/CircuitVerse/cv-frontend-vue/pull/647) ๐๐
+- PR : [Docker Failure Fix](https://github.com/CircuitVerse/CircuitVerse/pull/6061) ๐ณ๐ ๏ธ
+- PR : [Embed Failure Fix](https://github.com/CircuitVerse/CircuitVerse/pull/6072) โ๐ง
+
+---
+## Learning ๐โจ
+I learned a lot related to working of things in software. Most of all I learned how to look for solutions. I really liked the part where I sat plannig with my mentors as to how we are going to be approaching different contingencies. We implemented many ideas and had to leave behind many too. I learned a lot about GitHub Actions, Vue.js, Rust, and TypeScript a lot. Also got to try my hands on Rails and Ruby too. ๐ ๏ธ
+
+These few weeks taught me a lot about how the industry works and how work is done. I learned a lot of things outside coding and got to meet many crazy people and learn from them. ๐
+
+## Conclusion ๐ข๐ฏ
+
+My journey so far has been nothing but a roller-coaster. Each week I stumbled upon things I didn't know, then learned it, bugged my mentor about it, experimented with it and then implemented it. It has truly been a developer's dream till now. My mentors and CircuitVerse community have been very helpful and inspirational in my little journey. Looking forward to contribute and learn more. ๐
+
+I would especially like to thank my mentors [Aryann Dwivedi](https://github.com/aryanndwi123) and [Niladri Adhikary](https://github.com/niladrix719) for being amazing mentors and guiding my way out of the walls I kept head-butting into, I would also like to thank [Arnab Das](https://github.com/Arnabdaz), [Aboobacker MK](https://github.com/tachyons), [Vedant Jain](https://github.com/vedant-jain03) and other mentors and circuitverse contributors for helping and mentoring me throught the journey. ๐๐
+
diff --git a/static/images/Harsh_Rao/Authentication2-final.png b/static/images/Harsh_Rao/Authentication2-final.png
new file mode 100644
index 0000000..abf0c1c
Binary files /dev/null and b/static/images/Harsh_Rao/Authentication2-final.png differ
diff --git a/static/images/Harsh_Rao/Authentication3-final.png b/static/images/Harsh_Rao/Authentication3-final.png
new file mode 100644
index 0000000..1ad6ea7
Binary files /dev/null and b/static/images/Harsh_Rao/Authentication3-final.png differ
diff --git a/static/images/Harsh_Rao/Final_report.jpg b/static/images/Harsh_Rao/Final_report.jpg
new file mode 100644
index 0000000..ae884eb
Binary files /dev/null and b/static/images/Harsh_Rao/Final_report.jpg differ
diff --git a/static/images/Harsh_Rao/Release_Pipeline_1.png b/static/images/Harsh_Rao/Release_Pipeline_1.png
new file mode 100644
index 0000000..ab55672
Binary files /dev/null and b/static/images/Harsh_Rao/Release_Pipeline_1.png differ
diff --git a/static/images/Harsh_Rao/Release_Pipeline_2.png b/static/images/Harsh_Rao/Release_Pipeline_2.png
new file mode 100644
index 0000000..bb6c737
Binary files /dev/null and b/static/images/Harsh_Rao/Release_Pipeline_2.png differ
diff --git a/static/images/Harsh_Rao/Testbench_1.png b/static/images/Harsh_Rao/Testbench_1.png
new file mode 100644
index 0000000..48c1270
Binary files /dev/null and b/static/images/Harsh_Rao/Testbench_1.png differ
diff --git a/static/images/Harsh_Rao/Testbench_2.png b/static/images/Harsh_Rao/Testbench_2.png
new file mode 100644
index 0000000..11c728f
Binary files /dev/null and b/static/images/Harsh_Rao/Testbench_2.png differ
diff --git a/static/images/authors/ThatDeparted2061_Harsh_Rao.png b/static/images/authors/ThatDeparted2061_Harsh_Rao.png
new file mode 100644
index 0000000..50389b2
Binary files /dev/null and b/static/images/authors/ThatDeparted2061_Harsh_Rao.png differ
diff --git a/static/videos/Harsh_Rao/Authentication.mp4 b/static/videos/Harsh_Rao/Authentication.mp4
new file mode 100644
index 0000000..ec9a17d
Binary files /dev/null and b/static/videos/Harsh_Rao/Authentication.mp4 differ
diff --git a/static/videos/Harsh_Rao/Embed.mp4 b/static/videos/Harsh_Rao/Embed.mp4
new file mode 100644
index 0000000..b0df132
Binary files /dev/null and b/static/videos/Harsh_Rao/Embed.mp4 differ
diff --git a/static/videos/Harsh_Rao/Testbench.mp4 b/static/videos/Harsh_Rao/Testbench.mp4
new file mode 100644
index 0000000..bd1ffc1
Binary files /dev/null and b/static/videos/Harsh_Rao/Testbench.mp4 differ
diff --git a/static/videos/Harsh_Rao/release-pipeline-final.mp4 b/static/videos/Harsh_Rao/release-pipeline-final.mp4
new file mode 100644
index 0000000..098591a
Binary files /dev/null and b/static/videos/Harsh_Rao/release-pipeline-final.mp4 differ