Make testing a PR easier

[christianbrb]

Description

Currently we have got the problem, that it is difficult to get a branch/PR in a state where it can be tested by the reviewer.

We have discussed several solutions:

• Looking at CircleCI or https://vercel.com/features/deployment-previews to build and deploy a PR branch
• Alternative: Get it built by the CI, download and serve locally

Additional actions:

• Having a different account for testing
• Test steps more detailed (exclude bugs)

Acceptance criteria

• Decide on an approach and estimate after discussion

Tasks

• [ ]

[nephix]

Vercel makes it very easy but reusing the build artifacts makes sense as well since we already build the dapp+sdk on every branch push. Would only need to:

• deploy it somewhere
• make it unique per pull request
• remove deployment when pull request gets closed/merged

If that's too complicated, downloading the artifacts and running them locally sounds good as well imo 👍 GH allows zip attachments with a max size of 25MB so should work for us

[christianbrb]

Seems to be ready for the iteration for me

@nephix @kelsos @andrevmatos Please remove the label if there is more refinement needed.

[kelsos]

The vercel flow seems reasonable to me, and easy.

[nephix]

Zeit/Vercel's Now doesn't seem to offer a lot of monorepo support yet so it probably makes sense to go with a different option

vercel/vercel#3547

[nephix]

Another option would be to use netlify/vercel and tell it via CLI to deploy the build artifacts that we build via CircleCI:

$ netlify deploy --dir raiden-dapp/dist --site 714de093-0a95-4dc4-a978-ff660e317d91 --auth NETLIFY_AUTH_TOKEN --json

{
  "site_id": "714de093-0a95-4dc4-a978-ff660e317d91",
  "site_name": "light-client-preview",
  "deploy_id": "5ebe756f0a2659511cf450be",
  "deploy_url": "https://5ebe756f0a2659511cf450be--light-client-preview.netlify.app",
  "logs": "https://app.netlify.com/sites/light-client-preview/deploys/5ebe756f0a2659511cf450be"
}

And then in a second step comment the deploy_url to the pull request (this orb might help? https://circleci.com/orbs/registry/orb/benjlevesque/pr-comment)

I feel like integrating it into the work flow may be a lot more work though than just calling it locally and then adding it to the pull request 🤔

[christianbrb]

@kelsos Do we know how to move forward with this issue?

Two other options:

• https://devcenter.heroku.com/articles/github-integration-review-apps
• https://sanderknape.com/2020/05/deploy-pull-requests-github-actions-deployments/

[kelsos]

I already checked the review-apps but I am not sure about the cost of that.

The whole idea is to automate the deployment using CI, but where to deploy is a question. I had a discussion with Nils on that but I am still not sure about deploying new instances of anything on each PR.

[christianbrb]

@andrevmatos to create a server (docker image)

[christianbrb]

Briefly discussed with @kelsos to take out complexity.

If there is no objection we would just provide the tool @andrevmatos proposed that downloads the published artifacts from CircleCI, starts an express server, and serves the content on the dev/tester local machine without publishing it on a remote server.

[christianbrb]

Decided in the daily: We go with the simple local approach :)

[andrevmatos]

I'm not sure what simple local approach means... for me, a simple local approach is what we have currently: checkout branch, build and serve. Simpler local than that, could only be download and serve, but that's not less work than what we have. And beyond that, just do this automatically upon accessing a URL of a service hosted somewhere. I'm looking for options on how it could look like local or remote.