Refactor LLVM git dependency in clang [chromium/src : main]
Hans Wennborg (Gerrit)
Hans Wennborg added 1 comment![]( "Open in Gerrit")
Is there a spec or other document about what schema the consumer of this json file supports? Do we know that there's a path forward for e.g. the tarballs in GCS, cherrypicks we apply from github etc., or will that need to be built out later?
As I mentioned before, I'm positive about specifying our build inputs in a more declarative way, but wary about moving them out of the build/update scripts.
We can make it easier for tools and CI pipelines to inquire about the version and other dependencies by adding command-line options to the script, including one that outputs json.
My preference would be if update.py can continue to be the source of truth for what version it will update to. It is a nice property that the script is self-contained, and CLANG_REVISION has been where we define our clang version for a very long time. Moving it will break things, so we shouldn't do it without good reason.
Related details
- Dan Le Febvre
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Dan Le Febvre (Gerrit)
Dan Le Febvre added 1 comment![]( "Open in Gerrit")
Is there a spec or other document about what schema the consumer of this json file supports? Do we know that there's a path forward for e.g. the tarballs in GCS, cherrypicks we apply from github etc., or will that need to be built out later?
As I mentioned before, I'm positive about specifying our build inputs in a more declarative way, but wary about moving them out of the build/update scripts.
We can make it easier for tools and CI pipelines to inquire about the version and other dependencies by adding command-line options to the script, including one that outputs json.
My preference would be if update.py can continue to be the source of truth for what version it will update to. It is a nice property that the script is self-contained, and CLANG_REVISION has been where we define our clang version for a very long time. Moving it will break things, so we shouldn't do it without good reason.
Is there a spec or other document about what schema the consumer of this json file supports? Do we know that there's a path forward for e.g. the tarballs in GCS, cherrypicks we apply from github etc., or will that need to be built out later?
I have all of that tested in another CL but I don't want to submit some large CL in one go. But all of those things you mentioned should go in the same JSON file.
As I mentioned before, I'm positive about specifying our build inputs in a more declarative way, but wary about moving them out of the build/update scripts.
Is your concern that we don't know who else is parsing these python files to get version numbers? Outside of chromium. At some point something will change and break this type of workflow.
>
> We can make it easier for tools and CI pipelines to inquire about the version and other dependencies by adding command-line options to the script, including one that outputs json.
yes but its absolutely not ideal to be executing random python files in secure environments just to get version numbers.
>
> My preference would be if update.py can continue to be the source of truth for what version it will update to. It is a nice property that the script is self-contained, and CLANG_REVISION has been where we define our clang version for a very long time. Moving it will break things, so we shouldn't do it without good reason.
I think for now its probably OK but we will need higher BCID levels in the near future and this whole python file being authoritive for dependencies just wont be sustainable.
Related details
- Hans Wennborg