Skip to content

Instantly share code, notes, and snippets.

@israelias
Last active June 10, 2024 17:09
Show Gist options
  • Save israelias/4786e36898fdf26c5f9e5d496af758cb to your computer and use it in GitHub Desktop.
Save israelias/4786e36898fdf26c5f9e5d496af758cb to your computer and use it in GitHub Desktop.
Sync Fork Diff Clone Pipeline | A One-Person Job

Sync Fork Diff Clone Pipeline

the-lex-web-uia-lex-web-uiour-lex-web-ui

@aws-samples/aws-lex-web-ui@results-cx/aws-lex-web-ui@devicebits/qnabot-web-widget

A one person job.

Clone deviates from fork circa v0.19.*


Fork

Allows ability to pull release versions from the source of truth repo to sync to in order to then diff locally against clone

The Public Fork

The fork is in a separate org from the clone reserved for R&D initiatives.


Clone

Clone will always deviate from the fork as the clone is in a multi-tenant multi-integrated CI/CD plug-and-play world with attention to external QnABot backend and internal micro services.

For this reason, the single most important thing is to track exactly every codeblock of deviated feature.. Note: We make it a point to check the changelog in backend and fronted: QnABot Solution and LexWebUI Samples.

Below is an excerpt from the root README.md of the private clone

The Private Clone

TL;DR

We sync to the latest release of the pubic repo through a public fork but have direct modifications applied to this private clone.

/**
 * SP-Edit
 * @description
 */
<>
  "We wrap our modifications in an comment block with an opener and a closer so
  it's easier to diff."
</>
/** /SP-Edit */
  1. Check the original repos' changelogs: UI CHANGELOG, CF CHANGELOG for a release update. This clone is always (semantically) one major numerical above the the public repo to sensibly differentiate.
  2. Check the BLOG for updates
nvm install 16
nvm use 16 || 16.20.2
npm install --legacy-peer-deps
cd lex-web-ui
npm install
npm run build-dist
cd ..
npm run build

The root repo contains Loader logic along with our own event listeners. The child repo is a Vue app. It is not a monorepo; it's a repo with a very specific build output that isolates a contained/bundled Vue app.

  1. Quick Start using the current build in dist.
npm start


Sync Fork ∞ Diff Clone

WebStorm is the editor of choice for no other reason than it works at the discretion of the engineer executing this one-person-job.

Compare folders against their file size, content, or timestamp.

Diff Viewer for folders

The differences are displayed in the Diff Viewer for Folders where:

  1. Left is the Fork
  2. Right is the Clone

Settings

Toolbar

  • ✅ Show New Files on Left Side
  • ✅ Show Difference

Differences pane

  • Whitespace
    • ✅ Ignore whitespaces and empty lines
    • ☑️ [...diffViewerOptions]

Examples

Overview of the Comparison Table

Screenshot 2024-05-02 at 12 59 57 PM

fork > clone

Fork trumps Clone

In this example, fork trumps clone as the changes to sendChatMessageWithDelay are valuable at the discretion of the dev performing this one-person-job.

Screenshot 2024-05-02 at 1 32 50 PM

Accept >> Apply right changes to left.

Screenshot 2024-05-02 at 1 35 15 PM

clone > fork

Clone trumps Fork

This application is one of a four-part fully integrated PaaS CX solution. We introduce a lib as we need userIds to be uuids from the get-go.

Screenshot 2024-05-02 at 1 07 30 PM

clone > fork full drill

Clone trumps Fork meaningfully (a good one)

We introduce new Vue logic to ensure that clicked response card buttons remain hidden even after toggling/minimizing the chat window for as long as this bot is mounted. (Current LexWebUI as of this capture does not catch this)

Message.vue#<script>#computed

Screenshot 2024-05-02 at 1 17 31 PM

Message.vue#<script>#provide&methods

Screenshot 2024-05-02 at 1 15 53 PM

MessageList.vue#template

Excerpt of how MessageList complies to Message

Screenshot 2024-05-02 at 1 20 44 PM

Remainder

Just like any feature branch, the rest of this pipeline lives in the local clone that has or has not accepted changes from the fork. It is reviewed as a PR, tested, and so on. And released specifically with docs on what and how and where we deviate. (to the best of our ability)

A "release" of a build that is being consumed by live customers has only occurred twice. We are in early stages of the migration. The current clone's tag is serving the baseline functionality expected by exissting customers that replaces the Product's legacy bot with AWS' offering. Most features from the public repo are plugged-and-played in test branches connected to appropriate QnABot backends for R&D initiatives as enterprise customers have yet to fully adopt and appreciate the power of QnABot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment