Use Firebase Hosting Preview Channels to deploy a web app for every pull request.

[nilsreichardt]

We are building for every PR a web preview, which will be deployed to Firebase Hosting. The link to the website will posted as comment (like: #119 (comment)).

The previews are helping reviewer and other users to quickly view the changes in a compiled version.

A link to a preview expires after 30 days.

---

Closes #8

[github-actions]

Visit the preview URL for this PR (updated for commit c53c001):

https://sharezone-test--pr119-web-preview-channels-q1asu2sl.web.app

_{(expires Mon, 14 Feb 2022 11:33:59 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

[nilsreichardt]

@Jonas-Sander Web previews are not working 👍 You can review now. They are using the sharezone-debug Firebase project. Could this be a problem, when users are trying to log in into their account, but the credentials are not valid for sharezone-debug?

[Jonas-Sander]

I think we should also add a warning in the future that its a temporary web app and that no personal data should be entered - like #27

[Jonas-Sander]

Maybe we should also add this to our cli tool sz deploy web-app --stage preview in the future.
We don't have to do it in this PR, we can run with this for now.

[Jonas-Sander]

Isn't a web app redeployed everytime a change is made? I think we should then choose at the very maximum 3 days.

Or is it 30 days from first deploy? Anyways I would lower it anyways.

[nilsreichardt]

Isn't a web app redeployed everytime a change is made? I think we should then choose at the very maximum 3 days.

Or is it 30 days from first deploy? Anyways I would lower it anyways.

The default is 7 days. Should we pick this or even lower, like 3 days?

[nilsreichardt]

I think we should also add a warning in the future that its a temporary web app and that no personal data should be entered - like #27

Should we do this in this PR?

[Jonas-Sander]

Isn't a web app redeployed everytime a change is made? I think we should then choose at the very maximum 3 days.

Or is it 30 days from first deploy? Anyways I would lower it anyways.

The default is 7 days. Should we pick this or even lower, like 3 days?

I mean there are two cases:

• the web app expires x days after the most recent deploy (so a new commit "refreshes" the expiry date)
• the web app expires x days after the first commit (so new commits don't "refresh" the expiry date)

In the first case I would say three days in the second one maybe seven (could be even more). We could also say in the latter case that we don't deploy for draft PRs so we don't start deploying a web app when it's not necessary so we don't already start the expiry date counter.

I hope I didn't make it too complicated :D

[Jonas-Sander]

Right now it says

Visit the preview URL for this PR (updated for commit 8339a78):

https://sharezone-test--pr119-web-preview-channels-q1asu2sl.web.app

(expires Sun, 06 Mar 2022 15:58:37 GMT)

06.03.2022 - what happens to the date if you push a new commit?

[Jonas-Sander]

I think we should also add a warning in the future that its a temporary web app and that no personal data should be entered - like #27

Should we do this in this PR?

No, in another one I'd say.

[nilsreichardt]

I mean there are two cases:

• the web app expires x days after the most recent deploy (so a new commit "refreshes" the expiry date)
• the web app expires x days after the first commit (so new commits don't "refresh" the expiry date)

In the first case I would say three days in the second one maybe seven (could be even more). We could also say in the latter case that we don't deploy for draft PRs so we don't start deploying a web app when it's not necessary so we don't already start the expiry date counter.

I hope I didn't make it too complicated :D

It expires x days after the last commit. I would not pick three days, because this would also require that we review the pull request in these three days, otherwise we are not able to use the preview. Because of this, I would pick 7 days, which gives us a bit more freedom.

[Jonas-Sander]

It expires x days after the last commit. I would not pick three days, because this would also require that we review the pull request in these three days, otherwise we are not able to use the preview. Because of this, I would pick 7 days, which gives us a bit more freedom.

Yeah, true, let's do 7:)

[nilsreichardt]

@Jonas-Sander Changed it 7d 👍 You can now review again.

[Jonas-Sander]

I think we can just run flutter pub get inside /app and not run sz pub get (which is probably slower)

Can you fix this?

[Jonas-Sander]

See comment above

[Jonas-Sander]

LGTM