To support tools written in Rust, we need to add a Rust buildpack. @dcaro can you give me some pointers on what needs to be done to add this?
For this we have to figure out how to provide custom buildpacks/add buildpacks to the base image.
We almost have a formed idea on how to do so, but needs some refinement (see T325799: [tbs] User story - I can use multiple language stacks for my application, https://github.com/toolforge/buildservice/pull/23).
| Title | Reference | Author | Source Branch | Dest Branch | |
|---|---|---|---|---|---|
| builds-builder: bump to 0.0.82-20231219180054-f6ab10bc | repos/cloud/toolforge/toolforge-deploy!160 | project_1317_bot_df3177307bed93c3f34e421e26c86e38 | bump_builds-builder | main | |
| rust: add buildpack | repos/cloud/toolforge/builds-builder!22 | dcaro | add_rust | main |
Sorry for the delay, lots of things happened xd
Now we have a working way to inject specific buildpacks into the pipeline, so this should be relatively easy to get in.
One issue that I see is that the upstream buildpack for rust (https://elements.heroku.com/buildpacks/emk/heroku-buildpack-rust) seems to not have been updated for a long time (4 years!), I can give it a try but might require sending a couple patches to update it.
dcaro opened https://gitlab.wikimedia.org/repos/cloud/toolforge/builds-builder/-/merge_requests/22
rust: add buildpack
Got it working! \o/ (with the example app https://github.com/emk/rust-buildpack-example-rocket)
raymond-ndibe merged https://gitlab.wikimedia.org/repos/cloud/toolforge/builds-builder/-/merge_requests/22
rust: add buildpack
project_1317_bot_df3177307bed93c3f34e421e26c86e38 opened https://gitlab.wikimedia.org/repos/cloud/toolforge/toolforge-deploy/-/merge_requests/160
builds-builder: bump to 0.0.82-20231219180054-f6ab10bc
raymond-ndibe merged https://gitlab.wikimedia.org/repos/cloud/toolforge/toolforge-deploy/-/merge_requests/160
builds-builder: bump to 0.0.82-20231219180054-f6ab10bc
raymond-ndibe opened https://gitlab.wikimedia.org/repos/cloud/toolforge/builds-cli/-/merge_requests/45
[builds-cli] fix build delete --all
Thanks!!! I skimmed through https://gitlab.wikimedia.org/repos/cloud/toolforge/rust-buildpack/-/blob/move_to_api_0.10/target/bin/compile?ref_type=heads and had a few suggestions on things to fix. I'll file some bugs in the next few days when I have time to play with this.
Q: Are we fully forking https://gitlab.wikimedia.org/repos/cloud/toolforge/rust-buildpack or is the intention that changes be submitted upstream first? (It seems pretty inactive IMO.)
The idea is not to fork it no, I just tried to add the minimum changes to make it work with the upstream builder (that uses cloud-native API, instead of internal heroku one).
I recommend trying to get the changes upstream instead, and then we can rebase on top. If you find a better maintained buildpack, we can move to that one too.
For example https://github.com/paketo-community/rust seems better maintained.
I'm considering shifting from heroku to the paketo builder due to the lack of activity and that double heroku buildpack API/cloud-native buildpack API and the lack of support on the upstream heroku builder for the heroku API based buildpacks, but it might require a bit of effort.
Here are the issues I see so far:
I recommend trying to get the changes upstream instead, and then we can rebase on top.
https://github.com/emk/heroku-buildpack-rust has seen no updates in 5 years, so trying to upstream changes seems pretty futile.
If you find a better maintained buildpack, we can move to that one too.
For example https://github.com/paketo-community/rust seems better maintained.
Is there a reason you didn't use that one in the first place then? I'm a bit confused.
Is there a reason you didn't use that one in the first place then? I'm a bit confused.
Yes, using that buildpack means using also the paketo builder, and that means using the set of supported languages that comes with it (and it's ecosystem).
We went with heroku builder initially, as the community around it is way larger (including a hub https://elements.heroku.com/) and that would allow us to both eventually support many other languages and engage with an open source community while doing so.
Can you open separated tasks for each thing you need?
You can already use rust as is, though it might not fit your exact use-case, so basic support is there.