Adopt bzlmod to build the repository #77
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
manuelnaranjo
force-pushed
the
mnaranjo/repo-uses-bzlmod
branch
7 times, most recently
from
b1cbf2e to
7917ec9
Compare
|
@rmohr this is ready for a review, it looks bigger than it is because of all of the e2e tests with different mode and repetated files. I can split it into smaller PRs if you want, but I think it's worth to review as whole |
|
Ping @rmohr |
manuelnaranjo
force-pushed
the
mnaranjo/repo-uses-bzlmod
branch
2 times, most recently
from
8cd688b to
e8ad817
Compare
The repository uses bzlmod to build, getting all it's external dependencies through bzlmod instead of the WORKSPACE
Stop waisting valuable CI time in protoc building
Prebuilts are now handled differently and require a proper release process, in order to allow forks to also release we need to consume GITHUB_REPOSITORY while rendering the repo files. To build our binary and provide a prebuilt for those consuming over bzlmod, then we need a better repository structure. Change the release process, which is now heaviliy inspired in https://github.com/aspect-build/bazel-lib which also provides a few prebuilt golang binaries
Adding a tag that allows to expose an rpm file, similar to the approach we have in WORKSPACE mode
Adding the bzlmod to our CI tests
manuelnaranjo
force-pushed
the
mnaranjo/repo-uses-bzlmod
branch
from
e8ad817 to
f9fe1e4
Compare
Adding tests that build the bazeldnf binary before doing it's work
Introducing a proxy repository to make it easier to consume rpms by not polluting the public repository namespace
Adding a very basic lock file support, we don't generate the lock file yet, this will come in the future. It allows reducing complexity from MODULE.bazel though
Now gazelle can handle skylib targets, which are used by stardoc
Now we can generate the markdown files describing our interface from our code
When consuming bazeldnf most of the time users don't want to build the binary
The release script had a typo
CI was pulling the wrong binary name, artifacts have a version prefix
My version string had a v prefixed which was wrong
The release workflow is spending more time in updating the cache than building, and there's no benefit as consecutive builds will get a different cache anyway
manuelnaranjo
force-pushed
the
mnaranjo/repo-uses-bzlmod
branch
from
f9fe1e4 to
57e5310
Compare
|
@genert FYI I'm already using bazeldnf through bzlmod with: This is enough to start getting it tested while we get Roman's attention again |
|
ping @rmohr, maybe you're back from holidays now? |
|
Excellent! Thanks so much! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Introducing bzlmod support to the repo. For bzlmod we don't support Bazel < 6.
We expose a basic extension so others can start using bazeldnf. We provide a legacy mode that has a lot of RPM information on MODULE.bazel and exposes 1 bazel repository per RPM, then there's another non legacy mode where we provide a proxy repository to reduce some complexity out of MODULE.bazel and finally there's a mode with a json lock file to move all the RPM tracking into a non starlark file. We don't provide yet a way to generate such lock file. All this modes get an e2e test.
On top of this we also allow to use a prebuilt and non prebuilt bazeldnf binary. When building the binary if we're in bazel 7+ then we use a prebuilt protoc which speeds up the build considerably.
Here's a sample of the release CI artifacts pipeline
This builds on top of #76