support external servers for internal builds about bazelisk HOT 8 CLOSED

@FaBrand - do you mean the use indicates a version (perhaps with additional version tags) and the bazeliskrc maps that version (could be a simple normal version revision, but user wants a forked bazel) into a provider/repository/path?

I could make either user tagged versions or plain bazel versions work, but it is probably better to be able to override something like 1.0.0 to be your own package implementation. In my case I've got trivial patches that make bazel recognize cuda as c++ through file extension handling, and maybe some ld script extensions still.

@philwo Yes, I think to cover my use cases being able to try both disk and http, a sort of availability mirroring is highly desirable over just having an http url to support a variety of common user cases (intranet, remote, no internet), disk only paths have other reasons for wanting (security) too. It would also be nice if the complexity of the file (the one hiding behind github.com/.../api/) was not very complicated and human maintainable. Speaking of no internet, just to make sure, if all assets required to build were downloaded previously, making sure that if internet goes away, that things work is definitely good to have.

• support http and disk paths
• support mirrors for providers (e.g. many http and disk paths potentially providing the assets )
• support no internet / disk path access after assets have been downloaded
• map simple / plain bazel versions into custom bazel builds (as well as user tagged versions)

from bazelisk.

We have a similar Situation at work.
We use bazel with bazelisk quite extensively and i was thrilled to read the enterprise ready 1.0 Release.
However this assumes that the fork resides on github.com and does not allow for different URLs from local Systems
e.g. github.company.com/api/...

I already had some thoughts about how to provide this Information.

First idea i came up with was to extend the pattern that is already used with the fork Version.
However this has the drawback that each User needs to write out the whole shebang everytime, when testing with a different Version.
That lead me to my second thought

Having e.g. a .bazeliskrc could store that information better and statically per repo.
So the User could still use just USE_BAZEL_VERSION=0.XX.X
And bazelisk takes the repo/api URL from the rc file.

I would be glad to know what you think about that. If you agree, i could open a PR, but would need some help through review since my GO proficiency is not that well (yet) 😁

from bazelisk.

We actually need a similar feature inside Google, too. I'd be happy to review a PR and no worries about the Go proficiency, I'm also figuring this out as we go here. ;)

Let me think a bit about a possible design and get back to this on Friday!

@nevion, @FaBrand and others, feel free to discuss your requirements here, so that we can make sure to address everyone's use case. For example, being able to get the binaries from a local directory instead of an HTTP server might useful for us.

from bazelisk.

Thinking about this for our own needs, I"m not sure if it makes sense to just support a version, a URL, or a separately configured version and url template. The quick and dirty is to just support a URL in place of a version string. But... in our case, a url can't work simplicitur because the url carries both version and platform information. (e.g. darwin vs. linux) since we pin in our repo, but we have CI on a different platform than our developer workstations.

from bazelisk.

• Having bazelisk address a github repository that is a clone/mirror of github.com/bazelbuild/bazel that is accessible through a internal api/address. e.g. https://github.company.net/api/v3/repos/organisation/bazel_fork or https://github.company.net/api/v3/repos/user/bazel_fork

• For user convenience make this url configurable in a static way (either .bazelversion or maybe a .bazeliskrc or .bazelisk/...)

This is based on the assumption that all users in the organization would use bazel through the net-based approach and are working with the same github installation.

@nevion regarding the version question
The idea was to not have to write but rather keep the way a fork is selected atm.

$ USE_BAZEL_VERSION=github.company.net/organization/bazel/0.27.0 bazelisk build ...

So the static information about where the repositoriese are hosted can be put somewhere else.
I don't have any requirements to have this configurable. (maybe disable the usage from a local installation with an env var to explicitely take the github.com variant)

From here on just brainstorming:
instead of having a .bazeliskrc file that would need more parsing, a directory e.g. .bazelisk/... would be easier. Specifc settings could be determined just by the existence of that file and just read plaintext with maybe basic sanitization
e.g.

.bazelisk/
    github_url
    github_api
    disk_location

where each file could contain the organiziation specific address. In case the file isn't there, just use the default as it is now

from bazelisk.

@nevion @philwo I finally found the time to prepare a draft. What do you think about #91 ?

A possible rc file could look like this: (Not considered valid though)

from bazelisk.

Was this fixed by #107?

from bazelisk.

In a way.. yes! Thanks. :)

#107 added support for fetching Bazel from custom URLs and @fweikert's recent refactoring added support for implementing custom repositories by implementing the ReleaseRepo / CandidateRepo / ForkRepo / ... interfaces. For example, inside Google we have a custom repository class that fetches the binaries and version info from a network filesystem. With a simple custom main method you can then wire it up so that Bazelisk uses this repository for everything.

I'll close this, if there's anything missing please feel free to open a new more specific issue or comment here!

from bazelisk.