sgammon
v0.11.2 has not been released to Bazel registry
v0.11.2 tag exists in repository, but not in Bzlmod registry: https://registry.bazel.build/search?q=graal
Thanks for flagging @marekkrk. The release flow is a little buggy and it failed at 0.11.2. I haven't had time to fix it yet. I'll see if I can get it out, and fix the pipeline in the next release so that releases are no longer delayed.
@sgammon same for 0.12.0 as well... the README mentions it - but it's not on https://registry.bazel.build/modules/rules_graalvm.
I guess that neccessarily means using WORKSPACE.bazel instead of MODULE.bazel, for now? Or is there another way / workaround? @fmeum
bazelisk build //tools/hello:hello-native
WARNING: Target pattern parsing failed.
ERROR: Skipping '//tools/hello:hello-native': error loading package 'tools/hello': Unable to find package for @@[unknown repo 'rules_graalvm' requested from @@]//graalvm:defs.bzl: The repository '@@[unknown repo 'rules_graalvm' requested from @@]' could not be resolved: No repository visible as '@rules_graalvm' from main repository. Was the repository introduced in WORKSPACE? The WORKSPACE file is disabled by default in Bazel 8 (late 2024) and will be removed in Bazel 9 (late 2025), please migrate to Bzlmod. See https://bazel.build/external/migration.
ERROR: error loading package 'tools/hello': Unable to find package for @@[unknown repo 'rules_graalvm' requested from @@]//graalvm:defs.bzl: The repository '@@[unknown repo 'rules_graalvm' requested from @@]' could not be resolved: No repository visible as '@rules_graalvm' from main repository. Was the repository introduced in WORKSPACE? The WORKSPACE file is disabled by default in Bazel 8 (late 2024) and will be removed in Bazel 9 (late 2025), please migrate to Bzlmod. See https://bazel.build/external/migration.
INFO: Elapsed time: 0.156s
INFO: 0 processes.
ERROR: Build did NOT complete successfully
How does one actually use rules from Git repos which have not been releases to https://registry.bazel.build? (Both for this, but also generally speaking; I'm curious.) According to https://bazel.build/external/migration something like this in MODULE.bazel might work:
http_file = use_repo_rule("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")
http_file(
name = "rules_graalvm",
sha256 = "",
url = "https://github.com/sgammon/rules_graalvm/archive/2071b847ac7c6206c48df400f6e6a10c28e64400.zip",
)
non_module_dependencies = use_extension("//:extensions.bzl", "non_module_dependencies")
use_repo(non_module_dependencies, "rules_graalvm")
gvm = use_extension("@rules_graalvm//:extensions.bzl", "graalvm")
gvm.graalvm(
name = "graalvm",
distribution = "ce", # `oracle`, `ce`, or `community`
java_version = "23", # `17`, `20`, `22`, `23`, etc.
version = "23.0.0", # pass graalvm or specific jdk version supported by gvm
)
use_repo(gvm, "graalvm")
register_toolchains("@graalvm//:jvm")
register_toolchains("@graalvm//:sdk")
but that's giving me:
ERROR: /home/vorburger/git/github.com/enola-dev/enola/MODULE.bazel:188:9: Traceback (most recent call last):
File "/home/vorburger/git/github.com/enola-dev/enola/MODULE.bazel", line 188, column 9, in <toplevel>
use_repo(non_module_dependencies, "rules_graalvm")
Error in use_repo: The repo name 'rules_graalvm' is already being used by a repo rule at /home/vorburger/git/github.com/enola-dev/enola/MODULE.bazel:181:10
ERROR: Error computing the main repository mapping: error executing MODULE.bazel file for <root>
With that I'm giving up on this, and just sticking to bazel_dep(name = "rules_graalvm", version = "0.11.1").
That's strange, 0.12.0 is mentioned in README, but the corresponding tag does not exist in repository.
@vorburger The following works:
WORKSPACE.build
http_archive(
name = "rules_graalvm",
sha256 = "3ef2f1583a4849d03209a43b0b507f172299c3045e585b6ffa7144a2bc12ae18",
strip_prefix = "rules_graalvm-0.11.2",
urls = [
"https://github.com/sgammon/rules_graalvm/releases/download/v0.11.2/rules_graalvm-0.11.2.zip",
],
)
load("@rules_graalvm//graalvm:repositories.bzl", "graalvm_repository")
graalvm_repository(
name = "graalvm",
distribution = "oracle",
java_version = "21",
version = "21.0.2",
)
load(
"@rules_graalvm//graalvm:workspace.bzl",
"register_graalvm_toolchains",
"rules_graalvm_repositories",
)
rules_graalvm_repositories()
register_graalvm_toolchains()
BUILD.bazel
load(
"@rules_graalvm//graalvm:defs.bzl",
"native_image",
)
@marekkrk Thanks for helping here and for noticing that missing tag. Releases have fallen a bit behind since the infra to deploy to BCR is currently broken. I'll try to get that fixed in the next few days.
@vorburger As mentioned in this thread, you should be able to use these rules with a repository override in MODULE.bazel, even if they are not published to BCR. If you have trouble with this, please ping the thread (make sure to mention me) and I would be happy to help diagnose.
Hey @sgammon @vorburger 👋🏽 , what's currently stopping this from staying in-sync/up-to-date on BCR? We'll need to get this all working before Bazel 9 LTS - assume. I love rules_graalvm - but we gotta streamline this to get this in everyones hands.
Also - @sgammon - what would need to be done within MODULE.bazel for the manual override?
@BenNeighbour rules_graalvm was early to adopt BCR, and the publishing framework has changed a bit since it was first written as part of Bazel Contrib. I believe those updates broke us somewhere along the way. It should probably be pulled out and put in fresh, following their directions.
It might make a good issue for contribution because BCR's publishing procedures are documented.
I also need to release the latest GVM versions at 24, so an update is due soon anyway. Thanks for the kind words. I'll make sure to get to this soon if someone else doesn't beat me to it :)
Regarding the override in MODULE.bazel - declare the module as normal first, and then use git_override, pointing to this repo and your desired commit or branch.
Thanks @sgammon! :) Can't wait to start helping on this one - as this is very important for my organization + personal projects right now.
My knowledge on the very low-level details of how GraalVM builds universe, etc, are limited, and I wonder how possible it is to achieve full incremental builds (like a normal java binary), if at all...
I think the primary usecase is just to run the graalvm target on-release/packaging before dockerizing via rules_oci, but would be great to open a discussion on this.
Also, do we think this could eventually become part of rules_jvm_external, to get this out far and wide, or do you intend to keep this under sgammon as this grows?
@BenNeighbour Hey, thanks! That's very kind.
I can help on the low-level Native Image side of things. I understand how the native-image binary works pretty well. If you have any questions once you sit down to contribute, just open a discussion or issue and tag me.
incremental builds
Yes, that will be possible someday, using the Native Image Layers feature that will soon ship in stable form. It has been in the works for a long time. Once that releases, we should add rules/targets for image layers in Bazel so that skipping and caching can apply and effectively provide incremental native image support.
AFAIK the flags have stabilized so we might even consider adding some of those rules now, even though it's not stable yet, and perhaps guarding with an opt-in flag or something. I can ask at the next Native Image meeting if those flags are ready for us to rely on (I think they are).
eventually become part of
rules_jvm_external
Sure, I would be happy to consider making these rules available somewhere more neutral than my personal account, but it might end up being the case that the GraalVM team could maintain these (or at least host them under their native-build-tools repo, or something).
Maybe the Native Image and GraalVM JDK parts could be split out, and the JVM parts added to rules_jvm_external? That might make sense. But, seeing as releases here are tied to GVM's cycle, it might be best to keep the Native Image parts somewhere dedicated. I'm down to evaluate moving this repo someday, yes, if the opportunity and right landing place presents itself.
Bazel Contrib might also be an option