Skip to content
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

migrate bazel build to Bzlmod #1022

Open
cieslarmichal opened this issue Dec 28, 2024 · 6 comments
Open

migrate bazel build to Bzlmod #1022

cieslarmichal opened this issue Dec 28, 2024 · 6 comments
Assignees
Labels
good first issue Good for newcomers help wanted Extra attention is needed

Comments

@cieslarmichal
Copy link
Owner

WARNING: WORKSPACE support will be removed in Bazel 9 (late 2025), please migrate to Bzlmod, see https://bazel.build/external/migration

@cieslarmichal cieslarmichal added help wanted Extra attention is needed good first issue Good for newcomers labels Dec 28, 2024
@gmottajr
Copy link
Contributor

gmottajr commented Jan 2, 2025

Hi @cieslarmichal,
I would like to contribute with your migrating of Bazel build from WORKSPACE to Bzlmod. Before proceeding, I’d like to gather more details to better assess the scope of the migration and ensure a smooth transition.

Could you please provide more information on the following points?

  1. Complexity of External Dependencies:

    • How many external dependencies are we currently managing in the WORKSPACE file? Are these dependencies mainly using simple rules (e.g., http_archive or git_repository), or do we rely heavily on custom repository rules and advanced configurations?
  2. Custom Repositories and Workarounds:

    • Are there any custom-built repositories or unique repository rules that we need to account for? If so, could you provide examples of these rules and how they are integrated into the build? This will help us understand how to replicate them in Bzlmod, especially if they require non-standard handling.
  3. Size of Your Bazel Build:

    • Could you clarify the size of the overall project? For example, how many external dependencies are we dealing with, and are there any particularly complex build configurations or large-scale integrations? This will help estimate how much work is involved in ensuring everything migrates properly.

Additionally, it would be helpful if you could share any acceptance criteria you have in mind for the migration. Are there specific requirements we need to meet, such as ensuring that all builds are still working after migration or that certain tools are compatible?

Lastly, could you provide a list of basic unit tests that you would expect to be present post-migration? This will help ensure that we maintain the functionality and stability of the build after the migration process.

I look forward to your response so we can plan the migration accordingly!

Thanks,
Jr.

@cieslarmichal
Copy link
Owner Author

Hello we only use following deps in MODULE.bazel file:

bazel_dep(name = "rules_foreign_cc", version = "0.10.1")
bazel_dep(name = "googletest", version = "1.14.0")

you can check existing bazel config in project root, files: WORKSPACE.bazel, MODULE.bazel and BUILD.bazel

the acceptance criteria would be to run bazel build //:faker-cxx command without errors

also as the last step of this migration please remove --enable_workspace flags from github pipelines (currently enabled because we have legacy build config)

@gmottajr
Copy link
Contributor

gmottajr commented Jan 3, 2025

Hi @cieslarmichal,
Sounds good,
Thank you for the details!

I’ve reviewed the current setup and am aligning on the strategy for migrating from the legacy WORKSPACE system to Bzlmod. Below is a breakdown of the strategy for Phase 1 to ensure a smooth migration while minimizing disruptions:

1. Initial Assessment:

  • MODULE.bazel already includes:
    bazel_dep(name = "rules_foreign_cc", version = "0.10.1")
    bazel_dep(name = "googletest", version = "1.14.0")
  • The WORKSPACE.bazel file still contains some legacy dependency configurations, and we need to migrate these to MODULE.bazel using the bazel_dep format.
  • BUILD.bazel should remain unchanged unless we need to adjust how dependencies are imported or configured.

2. Acceptance Criteria:

  • The key acceptance criterion for Phase 1 is ensuring that the build command:
    bazel build //:faker-cxx
    runs successfully without errors after the migration.
  • This will confirm that all dependencies are correctly configured in Bzlmod and the build environment is working properly.

3. Phase 1 Plan - Migration of Dependencies:

Step 1: Migrate Dependencies from WORKSPACE.bazel to MODULE.bazel

  • Review the WORKSPACE.bazel file to identify dependencies declared using http_archive, git_repository, or other repository rules.
  • Move these dependencies to the MODULE.bazel file in the format:
    bazel_dep(name = "dependency_name", version = "x.y.z")

Step 2: Ensure MODULE.bazel Is Up-to-Date

  • Once the migration of dependencies is complete, ensure that all external dependencies are correctly added as bazel_dep entries in MODULE.bazel.
  • For now, do not remove or alter any other existing configurations in MODULE.bazel unless explicitly necessary.

Step 3: Verify Build Integrity

  • After migrating the dependencies, run the following command to ensure that the build process works as expected:
    bazel build //:faker-cxx
  • This will ensure that the new Bzlmod setup resolves the dependencies correctly, and the build process is intact.

4. Final Step for Phase 1: Clean Up Legacy Flags

  • After confirming that everything works and dependencies are correctly resolved, we’ll remove the --enable_workspace flag from the GitHub pipelines configuration. This flag is currently enabling the legacy workspace behavior.
  • This will mark the completion of Phase 1 and fully transition to Bzlmod.

5. Next Steps:

  • I’ll start by creating a feature branch (feature/migrate-to-bzlmod) for this migration process.
  • I’ll begin by migrating the dependencies from WORKSPACE.bazel to MODULE.bazel.
  • Once the migration is complete, I will test the build with:
    bazel build //:faker-cxx
    and ensure everything works.
  • After confirming the build works, I will remove the --enable_workspace flag from the pipelines as the final step.

Once I’ve completed this phase, I’ll send a pull request for review. Please let me know if this approach looks good to you or if you have any further suggestions.

Please let me know your thoughts!

Best regards,
Jr.

@cieslarmichal
Copy link
Owner Author

Hello, great plan! Let's do this 👌

@gmottajr
Copy link
Contributor

gmottajr commented Jan 6, 2025

Hi @cieslarmichal,

I’ve completed the first phase of migrating the project to Bzlmod, and I’ve created a new PR with the necessary changes. The main updates include:

Replaced the WORKSPACE.bazel file with a MODULE.bazel file to handle dependencies using Bzlmod.
Defined dependencies for rules_foreign_cc, googletest, and rules_cc in the MODULE.bazel file.
Successfully built and tested the project to ensure everything works post-migration.

As part of this, I’ve backed up the removed WORKSPACE.bazel file for safety. These files are now located in a folder called backup_workspaces/ in the project directory. You can choose to exclude them definitively, or let me know if I should remove them permanently.

Feel free to review the changes, and let me know if anything needs further attention!

Best regards,
Jr.

@cieslarmichal
Copy link
Owner Author

Hello, nice job, old files can be deleted as they are in git history anyway 😁👌

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants