Closed artivis closed 1 year ago
Patch and project coverage have no change.
Comparison is base (
6647066
) 94.54% compared to head (34f67b2
) 94.54%.
:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
Thank @artivis, this looks great! We will find a Linux machine with discrete GPUs to test it.
Thanks for the quick review. I fixed the default branch in the snap ci workflow.
Hi @artivis ! Sorry to bother you again, but we need some help regarding snap.
After this PR is merged, we did some cleanup to only build and publish on release. The first run of the workflow went smoothly, and I could see the package uploaded and waiting for release on the snapcraft web interface. However, the workflow has been failing since then, and we're a bit lost...
This is our first time to publish a package on snapcraft, and we appreciate your guidance! 🙏
Hey there no problem.
Looking at the failing job, it seems that you had a heavy hand while cleaning up. Indeed the variable "$grade"
isn't defined anymore (unbound varible
).
This being said, my bad for not giving you more context for this PR.
Snaps come with a whole release management system baked in. One can manage several releases of one's app depending on the status of the development stable/candidate/beta/edge.
To publish to stable/candidate, the snap grade must be marked as 'stable'. That's what's happening here on: the snap is marked as 'stable' solely on tags, therefore preventing to push ongoing developments to the stable/candidate releases.
Similarly, the ci originally built the snap for all change pushed to the master branch, but would push on-going development (no-tag) to edge
and tags to candidate
. The promotions edge
->beta
& candidate
->stable
are then expected to be done manually on the store web page after rigorous testing ;)
That's really one release management schema, others are definitely possible.
If you have further questions, feel free to ping me :)
Thank you for such a detailed response!
Looking at the failing job, it seems that you had a heavy hand while cleaning up. Indeed the variable "$grade" isn't defined anymore (unbound varible).
Oh I see! I thought the grade
in snapcraft.yaml can be used as a variable. 😂
The promotions edge->beta & candidate->stable are then expected to be done manually on the store web page after rigorous testing ;)
This design is great! I'll test it on the web interface. We plan to gradually optimize our release process after implementing the chat API.
This PR adds snap packaging which (eventually) allows to easily install the app on dozens on Linux distro,
Run it then with,
The snap sets by default,
PORT=8080
since 80 requiressudo
MODEL_CACHE_DIR=~/snap/basaran/common/models
SERVER_THREADS=4
They all can be overloaded by the user through the usual environment variables.
Together with the packaging comes a new workflow that runs the packaging and push the artifacts to the store. This being said, you would have to create an account on the store and generate a access token.
Note that I could only test it on my laptop (no discrete gpu) and thus may require some tweaking.