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

Git hash stamping for an external repository #4464

Closed
jfroy opened this issue Jan 16, 2018 · 3 comments
Closed

Git hash stamping for an external repository #4464

jfroy opened this issue Jan 16, 2018 · 3 comments
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) stale Issues or PRs that are stale (no activity for 30 days) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: feature request

Comments

@jfroy
Copy link

jfroy commented Jan 16, 2018

Description of the problem / feature request:

I need to get the git hash from a git_repository define in a WORKSPACE. Using a workspace_status_command option as described in #216 does not work, since the top level workspace ends up providing the git hash, not the external repository.

Feature requests: what underlying problem are you trying to solve with this feature?

I need to incorporate the git hash in the build because it is used as a cache validation key. It must be a github git hash because we need to be inter-operable with caches produced on other machines. The project's normal cmake build system has no problem handling this.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Write a genrule that consumes bazel-out/volatile-status.txt in Workspace A, import Workspace A in Workspace B using git_repository, run bazel build --workspace_status_command= with the example workspace status command (https://github.com/bazelbuild/bazel/blob/master/tools/buildstamp/get_workspace_status). The genrule will see the git hash of Workspace B, not Workspace A, even of the genrule is in Workspace A.

What operating system are you running Bazel on?

No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux rodete
Release: rodete
Codename: rodete

What's the output of bazel info release?

release 0.9.0

Have you found anything relevant by searching the web?

Mostly what is in #216, which works OK for a single workspace but not at all when using external workspaces.

@royvandam
Copy link

royvandam commented Dec 10, 2018

It looks like this information is already passed to Bazel by the _git_repository_implementation function: https://github.com/bazelbuild/bazel/blob/master/tools/build_defs/repo/git.bzl#L109

Hence I would also assume this is some how retrievable using some form of query. But I have no luck so far in figuring out how this would work. Is there someone able to elaborate if this would be feasible?

@dslomov dslomov added team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. P3 We're not considering working on this, but happy to review a PR. (No assignee) and removed category: extensibility > external repositories labels Mar 21, 2019
@aehlig aehlig removed their assignment Feb 1, 2020
@philwo philwo added the team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website label Jun 15, 2020
@philwo philwo removed the team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website label Nov 29, 2021
@github-actions
Copy link

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

@github-actions github-actions bot added the stale Issues or PRs that are stale (no activity for 30 days) label May 24, 2023
@github-actions
Copy link

github-actions bot commented Jun 7, 2023

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) stale Issues or PRs that are stale (no activity for 30 days) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: feature request
Projects
None yet
Development

No branches or pull requests

6 participants