Setting visibility of image_bzl to public so that it can be used when…

[ngeor]

… documenting custom rules with stardoc (Fixes #1916)

PR Checklist

Please check if your PR fulfills the following requirements:

• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• [ x] Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• Other... Please describe:

What is the current behavior?

Issue Number: N/A

What is the new behavior?

Does this PR introduce a breaking change?

• Yes
• [ x] No

Other information

[google-cla]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[ngeor]

@googlebot I signed it!

[ngeor]

Good morning folks, can I please get a review? 🙏 @alexeagle @gravypod @pcj @smukherj1

[alexeagle]

I'm surprised if the issue is only in Java - should we change this everywhere?
Note that you can just pass --nocheck_visibility to Bazel to bypass the checking when you build your stardoc target

[ngeor]

Right, I only use Java so that's why I reported it only for Java :) From some colleague who is more experienced with Bazel, he mentioned rules_docker might be a bit inconsistent regarding visibility. Let me see if I can use the flag you mentioned.

[ngeor]

I gave it a try, with a mix of sometimes referencing bzl files and sometimes bazel_library targets, I got it to work. But, I can't actually use the --nocheck_visibility flag because that means every single build command we run against our repo (e.g. bazel build //...) won't work anymore unless we specify that flag.

[ngeor]

Ok, my colleague advised me to use patches. I am applying patches on top of rules_docker. I should've done this before I created the MR, apologies for this. This revealed two more issues:

• another file we need to be changed is repositories/BUILD. As you predicted, more files might be needed to be public for other people, but for me just these two suffice. I opted in my patch to just make a library with a wildcard:

bzl_library(
    name = "repositories",
    srcs = glob(["*.bzl"]),
)

Furthermore, I see I need to patch another repo, Bazel Gazelle, because you use it and they don't even provide a bazel_library. I patched that as well and then I was able to use stardoc in a more sane way.

[ngeor]

Related PR for gazelle bazelbuild/bazel-gazelle#1092

[alexeagle]

thanks for fixing in gazelle too :)

[ngeor]

Thank you for merging @alexeagle , I took the latest git sha from rules_docker and gazelle and I was able to use stardoc to auto-generate the documentation for our Bazel rules/macros!