Setup deployment for canary branch

[yangwao]

Set Netlify branch deployment for canary branch

Once there is something in Canary branch, can proceed

Best if it would be straight working something with Vue3 components

[preschian]

I'm not sure what we need to add in the canary branch, but let me start with upgrading nuxt-edge and trying to add oruga

I think migrating the vue component to composition API, it's better directly to the main branch

oruga + tailwindcss seems a good match, isn't it? tailwind has a good extension https://tailwindcss.com/docs/editor-setup#intelli-sense-for-vs-code, and we can put our sass variable in the tailwind config. so our variable will appear on the IntelliSense
cc @yangwao @vikiival @roiLeo

[roiLeo]

I think migrating the vue component to composition API, it's better directly to the main branch

I'm okay with that, it can remain invisible to end users.

oruga + tailwindcss seems a good match, isn't it?

🤔?
Tailwind is a utility framework while Oruga is more of a UI component library, they are not the same thing and I don't see any advantage in coupling them (lmk if I'm missing something). You'll still able to customize Oruga sass variable (Bulma Theme)

[vikiival]

The goal is to have something that help us to maintain the components (in neobrutalism style) without mess.

[preschian]

The goal is to have something that help us to maintain the components (in neobrutalism style) without mess.

since we want to refactor the components. do we want/need to implement monorepo/workspace stuff?
so we can move the "new components" under local packages (folder)

// folder structure

nft-gallery/
├── apps/
│   ├── marketplace/ --> our nuxt app
│   │   ├── assets/
│   │   ├── components/
│   │   ├── composables/
│   │   └── etc...
├── libs/
│   ├── etc...
│   ├── components/ --> our design system --> @kodadot/design
│   │   ├── avatar/
│   │   ├── button/
│   │   ├── card/
│   │   └── etc...
│   └── utils/ --> shared utils --> @kodadot/utils
├── etc...
├── package.json
└── README.md

the downside:

• git commit history?
• need to adjust deployment pipelines and GitHub actions

after we use the monorepo/workspace structure, maybe we can implement https://turborepo.org/showcase also and put our logo there

[yangwao]

do we want/need to implement monorepo/workspace stuff?

libs/ is maybe something that could be put into the packages repository? https://github.com/kodadot/packages

With Vik briefly chatted and his idea was to make it as components through packages iirc,
downside would be it would figure out release pipeline tho during changes ofc

otherwise I'm up to for new structure as now it's good time to change this

[vikiival]

With Vik briefly chatted

Maybe the best steps for now:

• 1. separate components from nft-gallery (as pointed out by @preschian)
• 2. make 90% of components
• 3. move them to separated repo so it can be used by anyone with Vuetsama stack (Vue + Web3 + polkadot/kusama)

[preschian]

move them to separated repo so it can be used by anyone with Vuetsama stack (Vue + Web3 + polkadot/kusama)

downside would be it would figure out release pipeline tho during changes ofc

yes, I think that is the downside if the package/component is in a separate repo. but we can discuss it in more detail once we land vue3 in the components

so, here is a summary of todos:

• setup pnpm workspaces
• move nuxt app to apps/marketplace (any recommendation for folder naming?)
• initialise our neobrutalism components in libs/components (any recommendation for folder naming?)
  • for newer components, please put it here
  • migrate older components here
  • setup historie https://histoire.dev/
  • no graphql and vuex calls in this components, only receive props for the data (+ emit events if needed)
• adjust github actions
• adjust netlify commands for deployment
• adjust cloudflare commands for deployment

is that correct? did I miss any step?

[vikiival]

only receive props for the data

Updated with (+ emit events if needed)
For inputs you would need to emit something ;)
otherwise great summary.

[roiLeo]

it's no longer relevant?

[vikiival]

it's no longer relevant?

I think we working JIT in beta.
So let's close it if it will be relevant again.

[yangwao]

it's no longer relevant?

I think we can have https://canary.kodadot.xyz which could be main, beta can be hyper-jpeg and production will be new branch if so

[preschian]

I think we can have canary.kodadot.xyz

can we have a canary on cloudflare-pages? for ssr-opengraph-beta. because that script is used as an edge, and only works on cloudflare-pages

[yangwao]

hmmm

can we have a canary on cloudflare-pages?

I think yes, I need to think why we want to keep netlify, but I guess for main development it has this good logs accesibility and hmm, paralyzed builds are much faster subjectively

ah I think netlify is cheaper in these terms

cf-pages, 5k builds, but we are build times under 5m

oh, they have 5 concurrent builds

[yangwao]

aaa, I think issue is you won't visit deploy preview until I add you to the CF ?

can you get deploy in incognito easily? #5416

[yangwao]

aaa, seems can be deployed only once and doesn't support domains per aliases per branch, only aliases for one deployments which is not case we need

and accidentally turn on zerotrust access policy and can't return it back ommmm and it probably requires some sophisticated settings for deploy preview access and maybe is possible at least fix one thing 😅

well in worst case, I'm happy to have.. CF deploy to have consistency towards production and development keep netlify bc what I recall it possible much easier, in worst case explore CF setup one more time

[yangwao]

done in

• new domains deployments for kodadot and development flow #5420