You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
There is one tagged released of RoboSats (v0.1.0-MVP). After this release, given how fluid back and frontend have been, there has been a continuous delivery of every new small fix. Images have been tagged with a short commit hash. This works well since the application only runs on the server and the client downloads the latest frontend on every session. However, we are starting to ship clients that do not update every time they are opened (node apps, Android, etc).
Describe the solution you'd like
We should start versioning releases and implement frontend functionalities to check whether there is a version mismatch with the backend and instruct users to update their application.
Tasks toward automated versioning and releases
Create Github workflow that writes down version textfile on root and /frontend dirs. GH workflow builds frontend, node client, backend and Android app, on new push to a tag with semver. Each build would be a job on the workflow, some jobs would need other jobs (e.g. Android app needs frontend). All of these jobs already exist as separte workflows on /.github/workflows/.
Same workflow should create a CHANGELOG.md (auto-changelog) and create a Github Release with artifacts (e.g. robosats-0.2.0-alpha.apk) and links to tagged dockerhub images. This action seems to do what we need https://github.com/softprops/action-gh-release
Tasks toward client version mismatch detection
Backend reads the version from textfile version on root dir (currently reads commit_sha.txt) and serves as on /api/info
Frontend build hardcodes version in main.js. After the first /api/info request, if a mismatch with backend version is found, the frontend should display a dialog Update your RoboSats client. Shows link to Github release tagged with the same version as the /api/info response
Additional context
After implementing the pipeline, we could create a first release following the new practice as v0.2.0-alpha
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
There is one tagged released of RoboSats (v0.1.0-MVP). After this release, given how fluid back and frontend have been, there has been a continuous delivery of every new small fix. Images have been tagged with a short commit hash. This works well since the application only runs on the server and the client downloads the latest frontend on every session. However, we are starting to ship clients that do not update every time they are opened (node apps, Android, etc).
Describe the solution you'd like
We should start versioning releases and implement frontend functionalities to check whether there is a version mismatch with the backend and instruct users to update their application.
Tasks toward automated versioning and releases
version
textfile on root and/frontend
dirs. GH workflow builds frontend, node client, backend and Android app, on new push to a tag with semver. Each build would be a job on the workflow, some jobs wouldneed
other jobs (e.g. Android app needsfrontend
). All of these jobs already exist as separte workflows on/.github/workflows/
.robosats-0.2.0-alpha.apk
) and links to tagged dockerhub images. This action seems to do what we need https://github.com/softprops/action-gh-releaseTasks toward client version mismatch detection
version
on root dir (currently readscommit_sha.txt
) and serves as on/api/info
version
inmain.js
. After the first/api/info
request, if a mismatch with backend version is found, the frontend should display a dialogUpdate your RoboSats client
. Shows link to Github release tagged with the same version as the/api/info
responseAdditional context
After implementing the pipeline, we could create a first release following the new practice as
v0.2.0-alpha
The text was updated successfully, but these errors were encountered: