Add automation to automatically release zipped apps

[xhluca]

Closes #559

Whenever a commit is pushed to master:

• Automatically bump version
• Compress each app directory into a zip file
• Create a release and upload all the zipped apps

Issue for app: #[issue number here]

App pull request

• This is a new app
• I am improving an existing app (redesigns/code "makeovers")

About

• Playground deployment URL (new version):
• Current gallery app URL: (delete this line if inapplicable)
• Python app repository link: (delete this line if you are working on a Python app)

Workflow

• I have created a branch in the appropriate monorepo, and the
  elements necessary for successful deployment are in place.
• If the app is a redesigned and/or restyled version of an
  existing gallery app, I've summarized the changes requested in the
  appropriate Streambed issue and confirm that they have been applied.
• If the app is on the Dash Gallery portal, I have added a link to
  the GitHub repository for the source code in the portal description.
• If the app is a reimplementation of a Python gallery app for the
  DashR gallery, the app in this PR mimics, as closely as possible,
  the style and functionality of the existing app.=
• I have removed all Google Analytics code from the app's
  assets/ folder.

The pre-review review

I have addressed all of the following questions:

• Does everything in my code serve some purpose? (I have removed
  any dead and/or irrelevant code.)
• Does everything in my code have a clear purpose? (My code is
  readable and, where it isn't, it has been commented appropriately.)]
• Am I reinventing the wheel? (I have used appropriate packages to
  lessen the volume of code that needs to be maintained.)

[alexcjohnson]

What if we only ever had one release available? ie after uploading the new release we delete the previous one(s)? This feels like a bit of a misuse of the release mechanism, but it would make https://github.com/plotly/dash-sample-apps/releases much cleaner, and folks would likely just go there and download the zip they want.

[xhluca]

Yeah it shouldn't be too hard. (edit: I just tried it here and it worked)

I guess it does make it cleaner, although Github seems to automatically hide the assets of older releases to make it easier to navigate.

Moreover replacing the version number with "latest" automatically resolves it. Though I agree it looks a lot cleaner when you look at the tags.

I think one potential advantage will be to more easily access older versions of a certain app, especially if we start versioning based on dash's major version (e.g. dash-sample-apps v1.* corresponds to dash v1.*, etc.) as we start refactoring older apps using new syntax (e.g. pattern matching). However this can still be done by simply cloning the entire repo, which shouldn't be too large once we refactor the git history and move the data files to plotly/datasets.

[alexcjohnson]

💃 OK, let's keep it as you have, and we can revisit if the many releases become overwhelming. It feels a little confusing to me since most releases will only update one or two apps, but I agree that it could sometimes be useful to go back in time to an older version of an app.

Just a documentation comment, but this looks great!

[xhluca]

Thanks, I updated the readme with your suggestions; will merge now.

separate note: wouldn't we want to suggest the same pattern above when cloning the whole repo? ie cd into the app dir, set up the virtual env in that dir, and run the app from there? The way we describe it now with running things from the repo root makes it unclear how to handle app-specific venvs.

I think it's a good idea. In fact I feel a lot of the readme might be confusing for the community; it feels to me it was written for internal use. Would be nice to refactor the entire readme and move some parts to contributing.md