Prepare for bzlmod

[manuelnaranjo]

This PR will be an enabler so we can adopt bzlmod, but in order to simplify the process let's first do a bazel upgrade.

Changes:

• adding e2e tests for all the possible conditions we support: 5, 6 and 7 all without bzlmod
• adoption toolchain support for bazeldnf
• refactor the external API to the tools to reduce the external dependencies required to consume from us
• build the binary with bazel 6

[manuelnaranjo]

@rmohr this is ready for review, I'm splitting my bzlmod migration into multiple steps, this is the first step, refactor the public API, adopt a few good practices from other rules from the rules template, make sure we have e2e test for multiple bazel versions that would consume from bazeldnf and adoption of toolchains (reusing the pre-built binaries or doing built if requested).

The next step is for bazel 6 and 7 to add bzlmod, we will start with simple module extension reusing the current rpm rules and consuming rpm dependencies from WORKSPACE file (to avoid getting blocked by MODULE.bazel update process) and then on a follow up state figure out the API for MODULE.bazel

[manuelnaranjo]

FYI this is what the bzlmod with toolchains support starts looking like: https://github.com/rmohr/bazeldnf/compare/main...bookingcom:bazeldnf:mnaranjo/bzlmod-toolchain?expand=1

[manuelnaranjo]

FYI this is what the bzlmod with toolchains support starts looking like: https://github.com/rmohr/bazeldnf/compare/main...bookingcom:bazeldnf:mnaranjo/bzlmod-toolchain?expand=1

For simplicity I'm starting to consider we need to split the repo in 2 bazel repos, the first one is either prebuilt or build on demand bazeldnf binary (TBH maybe if we move to prebuilt protobuf it may be way faster to build than right now, but that only works with bazel7) and then another one that exposes the bzl rules, I'm having some trouble when consuming the bzlmod setup and I want to redirect the preloads to the upstream repo or to another repo

[rmohr]

I really don't like having two repos. But I love this PR! LGTM.

[rmohr]

I really don't like having two repos.

But if necessary we can do it, but I think I need a little bit more background on the issues you are facing.

[manuelnaranjo]

I'm not saying 2 git repos, but 2 Bazel repos, so 2 separate MODULE.bazel, the biggest challenge is actually the release process where we need to build the binaries and then have a file that gives us the sha per release. I worked in another rules after doing this and I got it to work just fine, need to check how it's different it may not be needed to split. The template for prebuilt binaries is made for cases like buildifier or some other external tool, where one repo provides the standalone binary and another one gives rules to consume those. While in this case both the rules and the binary are tight together. Anyhow, let me see how we take it from here and I come with another PR

[rmohr]

Sounds good! Thanks for doing that!

What you describe sounds pretty similiar what the release process is doing today: Once a release is tagged, the binaries get built and then updated references are pushed to the branch directly.

[manuelnaranjo]

So what others are doing is they keep a reference in the code to some valid state, so when using it in dev mode it works, and then during the release process after the binaries got built they push the new values into that file, but the file never gets checked in, which makes the repo a bit simpler to follow IMO.

I would say the biggest advantage of that approach is that you don't need github actions to be able to write into the repo, maybe somehow reducing how a public repo CI can be exploited?

[rmohr]

Any approach which allows us to stay within one git repo is fine by me. If we don't have to write from an action to the repo, even better :)