Dev-Op: build CI/CD pipleline for frontend

[YektaY]

We will most likely have a tauri app we will be deploying. we will want to be able to have the dev one update when changes go to master and to stage a deployment prod that would need approval. We might use software factory here, depending on what works best.

[shilorigins]

@YektaY Have you thought about this pipeline yet? I'm done with the core of #57, and only have to decide how the builds should interact with releases and deployments.

tauri-action builds the package and can also create a new GitHub release with the artifacts or attach the artifacts to an existing release matching some name or tag pattern. The conflict comes from deploying to dev on every change to master. I see the primary options as:

1. Create a release on every change to master
2. Attach artifacts to the job instead of a release on every change to master

With option 1, Software Factory can pull the artifacts from the release using the tag and deploy them to the dev environment. All builds will be preserved indefinitely, so when it's time to deploy to prod, the artifacts can be copied to a new proper release without rebuilding. Old builds could be redeployed from any dev tag. Dev releases could be marked as pre-releases to further distinguish them from prod releases.

With option 2, SF can still deploy the artifacts to the dev environment using the build number, and artifacts can still be copied over to releases. However, these artifacts would only be preserved for up to 90 days, so we would have to rebuild artifacts if we ever wanted to create a release from a build older than 90 days, or ad-hoc deploy code from a PR older than 90 days.

Since (1) clutters the release list, has a larger footprint from storing so many artifacts, and covers unlikely use cases (deploying code more than 90 days old) that are easily worked around (triggering a new build during the deployment), I favor option 2.