Sending a custom HTTP header is a highly uncommon use case. For GitLab specifically, you can use the standard Authentication header instead: https://docs.gitlab.com/ee/api/#personalprojectgroup-access-tokens

@Wyverald I am hitting the same exact problem with the Accept header. docker hub registry expects specific media types to be sent via the HTTP request to use a newer registry feature.

Is there a way to do this under bazel? UrlRewriter etc didn't work.

any links for context?

https://github.com/opencontainers/distribution-spec/blob/main/spec.md#workflow-categories

Part that starts with The client SHOULD include an Accept header indicating which manifest content types it supports.

Which is currently can't be set; bazel automatically sets it to text/html, image/gif, image/jpeg, */*

@thesayyn I'm much more sympathetic towards adding an "Accept" header than a completely random one called "PRIVATE-TOKEN". Could you file a separate issue about this? Thanks.

@thesayyn I'm much more sympathetic towards adding an "Accept" header than a completely random one called "PRIVATE-TOKEN". Could you file a separate issue about this? Thanks.

filed #17829. I'll cc you

This may be useful: https://www.stevenengelhardt.com/2023/05/23/practical-bazel-downloading-private-release-assets-from-github/

FYI - you should be able to do this using a credential helper in Bazel 6.3.0 (soon to be released) or later.

FYI - you should be able to do this using a credential helper in Bazel 6.3.0 (soon to be released) or later.

The problem with credential_helper is that I have to tell my ruleset users to either put a bash script into their workspace or download a binary from the internet for every CI/Dev machine just to add a header. it's not bazel-like

I recently ran into this issue, but found out a solution. I'm responding here just to go ahead and document it (hopefully also helping anyone else who happens to stumble upon this in the future).

It is true that gitlab has historically used "PRIVATE-TOKEN: <access token>" as their header for their REST APIs / HTTP requests. However, as of 2019, the APIs now also accept the more common OAuth-style header, Authorization: Bearer <access token>. This can be seen here in their documentation, and it was added in this commit.

This can be shown working using curl -v --header "Authorization: Bearer $MY_ACCESS_TOKEN" "$MY_HTTP_REQUEST_URL".

This can be used with Bazel with:

http_archive(
    name = "my_external_repo",
    auth_patterns = {
        "gitlab.com": "Bearer <password>"
    },
    netrc = "/path/to/my/.netrc/if/not/wanting/to/use/the/one/in/my/home/dir/.netrc",
    sha256 = MY_EXT_REPO_SHA,
    url = MY_EXT_REPO_URL,
)

(one could also use the NETRC environment variable in lieu of using the netrc attribute.)

Note: the netrc file must be given in an absolute path. Relative paths are not supported; they resolve to the external/ directory in the cache. This is probably not where your .netrc file is -- nor anything else that you'd really want to reference (maybe should be addressed) 😇. The absolute path is required for both the attribute and the environment variable (they get piped into the same place).

Unfortunately, I believe none of this works with CI_JOB_TOKEN, only other access tokens.

Hope this helps!