Deploy test version

[EvgeniiaVak]

This issue is not about the real user-facing deployment (that is blocked by #8 ). This is about deploying a version of the website that our community can interact with during the development. This website should be connecting to the test network.

pre-requisites

• [x] #27
• [x] #20

TODO

• [x] set up CI to build release files - kinda done, but not really needed for deploying the test version #87
• [ ] hide testnet version from search engines - don't need to do much, because we "use client" in the root currently 😆 it pretty much throws SEO out of the window already
• [ ] (maybe) deploy to vercel (paid-only for organizations)
• [x] deploy to IPFS
• [ ] deploy to GitHub

---

Things to consider:

• Maybe we'll need a separate development branch, where we push all our usual pull requests, and it is automatically deployed to the test, but maybe having main branch directly is ok.
• We will probably need some kind of environment variables for separating testing deployment and real deployment in the future

[fliebenberg]

For now it is probably easier to just have a main branch, since everything is still "development". We can look at creating a development branch when we get close to launching the app on the mainnet. That way all PRs go into development and we do pulls into main on either a set timeframe or on feature deployments. I dont have any experience working on repos of this nature. I have mostly worked on my own, which makes things much simpler. So I am keen to hear how you think we should deal with different branches.

[EvgeniiaVak]

I agree, for now only main branch is good enough.

[fliebenberg]

Are you happy for me to close this issue for now? We can raise this again closer to deployment? I think we should have a bigger discussion about the shape of the repo once we get closer to deployment. For now we just work in feature-development branches and the main branch.

[fliebenberg]

One suggestion is that we start using a consistent naming convention for branches. When it is a feature we add "feature:" to the front of the branch name and if it is a fix, we add: "fix: " to the front of the branch name. It just makes it a bit clearer when looking through the branches. Happy for other suggestions to achieve the same thing.

[EvgeniiaVak]

@fliebenberg I wouldn't want to close this issue, the opposite I would like to deploy asap (I'm thinking right after we are done with #6 ) and share only with testers. The idea is to deploy the very basic functionality early so that people would be able to test and probably find bugs. Note this is not about MVP-user-ready deployment (that should be done after #8 discussion), this one is about deployment of our current state of the project, always fresh, might be broken or not pretty, but something for our non-dev community play with and leave feedback. We might want to think about how to hide it from search engines though 😆 And in general I vote for not closing unfinished issues so that we don't forget about them. Better to create a separate Backlog column if we want to separate the some-day-maybe and todo.

[EvgeniiaVak]

Ok, deploying to Vercel is not free when deploying from a GitHub org:

https://vercel.com/pricing

Will try deploying to GitHub.

[EvgeniiaVak]

@fliebenberg I was playing with the deployment: https://evgeniiavak.github.io/dexter-website/ (it's from my fork, not from DeXter-on-Radix org) and chrome gives the following errors when trying to connect to AlphaDEX:

Looks like a change is needed in the SDK? Maybe just replacing ws://ws.alphadex.net/ to wss://ws.alphadex.net/ would work?

[fliebenberg]

@EvgeniiaVak Yes, i had to add in the option for wss. I have rolled out a new version of the SDK, if you can update to that and check if it is working I would appreciate it. Let me know if there are still issues.

[EvgeniiaVak]

@fliebenberg new sdk version:

"alphadex-sdk-js": "^0.8.1",

did not really help, new errors now (and they are present even locally):

[fliebenberg]

@EvgeniiaVak can you just check again please. I think this error might have been related to the Gateway that was down. I have other users connecting without a problem and I can also connect, so we might need to bug-hunt a bit if you are still having this issue.

[EvgeniiaVak]

@fliebenberg nope, still not working, see this commit - https://github.com/DeXter-on-Radix/website/commit/52dccc86a9a80f69560d0ac6ae8a087b71676108 the only thing I changed is update the SDK, and it stops working (and before the update it works all right via http (locally))

or without checking out the commit, steps to reproduce:

1. make sure you are using the old sdk: npm i alphadex-sdk-js@0.8.0
2. run npm run dev and observe that everything is working ok
3. update to 0.8.1: npm i alphadex-sdk-js@latest
4. again npm run dev and observe that it's not working any more

[fliebenberg]

Hi. I am not sure why the wss is not working on the server, but will investigate. In the meantime, I have rolled back the change so that the latest version now again just uses ws://. You can just update to latest to revert back to ws://.

[EvgeniiaVak]

Moving this issue to post-MVP, because @Radstakes ( 🙏 ) deployed a version to IPFS and testing is now unblocked 💃

When resuming this issue: can continue on branch: https://github.com/DeXter-on-Radix/website/tree/github-deploy-workflow the deployment itself works (example of a fork deployed with a similar job https://evgeniiavak.github.io/dexter-website/ ), but the page does not work correctly - adex sdk needs to be updated to support https (for non-ipfs-browsers).

[EvgeniiaVak]

We have https://test.dexteronradix.com/ on netlify, if github deployment is ever needed, the workflow can be found on github-deploy-workflow branch.