This is both a bit tricky and really easy with Bazel. The easy part,
especially compared to other build systems is that we can do this
regardless of the state of the repository -- Bazel will hermetically
check that everything is up-to-date, allowing the cache to be a bit
stale but still totally functional.
The easy part is that we can just ask Bazel to use an output base that
we cache and restore. This is super nice and even avoids most of the
Bazel installation bits.
The tricky part is that we need this to reconnect correctly to the
installed tree, so we need to exclude a crucial symlink that will then
get re-created at the right moment.
This gets really tricky due to LLVM and Clang (and this we would
struggle with no matter what build system we used). Building LLVM
creates a *ton* of object code. Just a huge amount. As a consequence,
we'd run into GitHub's limit for action cache size (5gb) really quickly
with 4 configurations.
So we can do another bit of tricky business and exclude the downloaded
`external` tree. This gets rebuilt easily, and there's no real need to
download it with the cached state -- its downloaded either way.
There are two follow-ups that I'd like to make here. One is to prod the
Bazel team to make things like persisting your output base a bit easier
to do reliably. Even better to make it easier to do *partial*
persisting.
Second follow-up is to work to make our usage of LLVM *much* less
wasteful. There are a bunch of steps here from changing how we use
sanitizers to how LLVM is built. Those will be follow-ups though.
I tried what I could, but I don't think this action will work while Carbon is private.
"Error: Resource not accessible by integration"
https://github.com/carbon-language/carbon-lang/runs/2441129284?check_suite_focus=true
I'd seen this mentioned on some actions:
https://github.com/marketplace/actions/github-project-automation#personal-access-token-secretsgithub_token
However, I thought it might've been a side-effect of the APIs they were using (I did have this running on a local repo), but I think fork PRs are where the problem lies...
This probably isn't exactly right, but it at least gives *some* low
latency way to update when all the dependencies have been addressed.
Right now, I think only the cron run will unblock dependent PRs.
This supports tracking PR-to-issue and issue-to-issue dependencies in
addition to PR-to-PR, and this seems likely to be increasingly important
as we have decisions being made via issues.
No since spending the GitHub action minutes (or waiting to merge) on
Bazel when only changing markdown or other files that aren't part of the
build and test.
This is primarily using the configuration matrix facilities of GitHub
actions to consolidate the overall configuration. Beyond avoiding
duplication, this also allows the default and release builds to run in
parallel. The checkout time is duplicated between these, but the rest of
the time is nicely parallelized. This has the most dramatic effect on
macOS builds. Overall, this should reduce the latency on testing from
22-28 minutes to 15-20 minutes from what I've seen which seems
worthwhile.
This does reduce the detail provided in the names of the different
configurations. However, the Bazel build mode is preserved. That seems
like the most critical pieces of information.
Much of this started with me just trying to learn more about GitHub
actions, but once understanding how the job matrix worked, it seemed
worthwhile to send out as an actual change.
- Shift some things around to adjust to being in bazel.
- Add separate build/serve/publish scripts for use by bazel (not set up for direct execution, but bazel requires +x).
- Fix some tests I noticed not running unittest.main as a result of the switch.
- Move md files into filegroups for build reuse.
- Disable automatic site publishing (now `bazel run //website/jekyll:publish`)
Site publishing seems like it'd be too much trouble to keep automated... The C++ toolchain essentially needs to be set up due to the repo config, along with syncing the LLVM submodules, etc. That seems a bit annoying to do on each run of the publish-docs action, and not something I really want to maintain. If we get a CI, we can focus on it more there, but this feels like it'd just be a one-off to maintain as a github workflow.
The jekyll build keeps top-level without expanding them. So the site works, but the publish copy failed because some symlinks to files that aren't visible through the site (like CONTRIBUTING.md, versus the site's CONTRIBUTING.html) didn't work.
One implication here is that both proposals/README.md and the website should use basically the same format for their proposal lists. Another subtle change is that the website sidebar was previously sorted by *filename*, and is now sorted by *title*, which seems better because it's something that readers can see.
Enumerating why files change:
- gen_sidebar.py is the centerpiece, with a couple helpful functions for re-use elsewhere
- Delete the old sidebar html includes
- Modify the Makefile to handle gen_sidebar.py reasonably well (let's be honest... I'm not great at Makefiles)
- Move proposal listing out to its own file (proposals.py) for re-use
- Add a few PYTHONPATH things + `__init__.py` files to get modules importing correctly (may be a better way at this, I've hit a wall though).
Added here:
- .pre-commit-config.yaml
- docs/project/contribution_tools.md
- src/scripts/pre-commit-toc.js
- CONTRIBUTING.md
- proposals/* (just to switch TOC formats)
The rest consists of auto-generated fixes.
The switch from doctoc to markdown-toc is because doctoc wants to put a TOC in every file, whereas markdown-toc only does it if you have an insertion point.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
* Add github action to publish docs.
This change add a placeholder action which:
(A) Authenticates with gcloud using the appropriate GCP AS.
(B) Copies the docs/ folder as-is into
www.carbon-lang.dev/test-doc-root/
Chandler Carruth
Jon Meow
Matthew Riley
Dave Abrahams
Bryce Adelstein Lelbach aka wash
Eric