-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added deployment workflow for rust API #1800
Conversation
@@ -205,6 +205,16 @@ jobs: | |||
with: | |||
password: ${{ secrets.PYPI_TOKEN }} | |||
|
|||
deploy-rust: | |||
runs-on: kuzu-self-hosted-linux-building |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is a very simple job that does not require compilation, consider move it to a GitHub-hosted runner instead of using our own infrastructure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The choice was deliberate. It's running a full build of the crate before uploading it, which is particularly important since the rust API only includes certain files when packaging both because the tools/rust_api/kuzu-src
symlink breaks the way it usually omits untracked git files, and because there's a maximum upload size and including stuff like the dataset directory would make the result too large. There's no verification that it can be built with the included files in CI, so having this last-minute check is important (and while it's . Having the check in CI instead would be slow, but would probably be a lot less so with sccache set up correctly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that kuzu-self-hosted-linux-building
is a different environment than the regular CI. It is based on CentOS 7 as defined in https://github.com/kuzudb/kuzu/blob/master/scripts/pip-package/Dockerfile. Could you please also update the Dockerfile to add rust dependencies? I will redeploy after this PR is merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, that I missed. I confused it with linux-self-hosted-testing
. Since the results of the build aren't what's being published, it probably should just use the testing environment shouldn't it? I don't know what exactly the difference between the two environments are but I'm assuming it's something to do with the libraries it links against.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes the building environment uses a distro with old glibc
so the prebuilt binaries can have better compatibility. You can use the testing environment since the binaries are not going to be published.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have updated it to use kuzu-self-hosted-testing
steps: | ||
- uses: actions/checkout@v3 | ||
|
||
- run: cargo publish |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For cargo publish, is there a way to dry-run or deploy to a test environment similar to npm or pypi? If so, we should do dry run unless isDeploy
is set to true so we can perform a test run without actually deploying.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, there's a --dry-run
option which skips uploading. I don't think there's a test registry like test.pypi.org, but we could just upload the packaged crate file to github.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. Please add the dry-run based on the flag. We should always upload the packaged files to GitHub as well for debugging purpose in case something goes wrong and the deployment fails.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
Let's add the script and invoke it on CI to ensure that the deployment can still be done correctly even if we forget to update the version for rust. You can get the version number from |
656f245
to
8696cff
Compare
uses: actions/upload-artifact@v3 | ||
with: | ||
name: kuzu-deploy-crate | ||
path: target/package/*.crate |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that the path here is not correct. I tested run this job once and it’s not able to find any artifact. https://github.com/kuzudb/kuzu/actions/runs/5522371969/jobs/10071856122
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoops. I wrote it relative to tools/rust_api
, but that's not the working directory for that step.
8696cff
to
0591fdd
Compare
Codecov ReportPatch and project coverage have no change.
Additional details and impacted files@@ Coverage Diff @@
## master #1800 +/- ##
=======================================
Coverage 91.13% 91.13%
=======================================
Files 776 776
Lines 28373 28373
=======================================
+ Hits 25857 25858 +1
+ Misses 2516 2515 -1 ☔ View full report in Codecov by Sentry. |
Note that this will publish the version as recorded in
tools/rust_api/Cargo.toml
, so that will need to be updated before the deployment pipeline is triggered.Alternatively we could have a script which detects the version and rewrites the file to use the most up to date version, but it would be helpful to keep the version up to date so that anyone adding kuzu as a git dependency sees a meaningful version.