Restructure site/ directory into docs/ which only contains Bazel documentation.

The new docs/ directory in the bazel source tree will only contain the Bazel
docs site, which is hosted at docs.bazel.build. This change deletes the
marketing site and blog, which have been migrated to the bazel-website and
bazel-blog GitHub repositories respectively.

This change also updates the serve-docs.sh and ci/build.sh under scripts/ in
preparation for publishing the docs site.

Note that to help make reviews more manageable, this change is limited to
moving files to their new locations. Here are the follow-up changes:

* Update all links in docs to remove versions/master in paths and to add
  correct bazel.build subdomain when linking to pages on the marketing site
  or the blog.
* Set up versioned directories on GCS bucket and add tooling for versioning
  docs

This change is also coordinated with
https://bazel-review.googlesource.com/c/11568/ to have the PublishSite job
publish to docs.bazel.build rather than www.bazel.build.

Issue #2397

RELNOTES: None
PiperOrigin-RevId: 157612651

1 files changed, 0 insertions, 114 deletions

diff --git a/site/versions/master/docs/skylark/build-style.md b/site/versions/master/docs/skylark/build-style.md
deleted file mode 100644
index d7787593aa..0000000000
--- a/site/versions/master/docs/skylark/build-style.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
-layout: documentation
-title: Style guide for BUILD files
----
-
-# BUILD file style guide
-
-In `BUILD` files, we take the same approach as in Go: We let the machine take care
-of most formatting issues.
-[Buildifier](https://github.com/bazelbuild/buildifier) is a tool that parses and
-emits the source code in a standard style. Every `BUILD` file is therefore
-formatted in the same automated way, which makes formatting a non-issue during
-code reviews. It also makes it easier for tools to understand, edit, and
-generate `BUILD` files.
-
-`BUILD` file formatting must match the output of `buildifier`.
-
-## Formatting example
-
-```python
-package(default_visibility = ["//visibility:public"])
-
-py_test(
-    name = "foo_test",
-    srcs = glob(["*.py"]),
-    data = [
-        "//data/production/foo:startfoo",
-        "//foo",
-        "//third_party/java/jdk:jdk-k8",
-    ],
-    flaky = 1,
-    deps = [
-        ":check_bar_lib",
-        ":foo_data_check",
-        ":pick_foo_port",
-        "//pyglib",
-        "//testing/pybase",
-    ],
-)
-```
-
-## File structure
-
-We recommend to use the following order (every element is optional):
-
-  * Package description (a comment)
-
-  * All `load()` statements
-
-  * The `package()` function.
-
-  * Calls to rules and macros
-
-Buildifier makes a distinction between a standalone comment and a comment
-attached to an element. If a comment is not attached to a specific element, use
-an empty line after it. The distinction is important when doing automated
-changes (e.g. to decide if we keep or remove a comment when we delete a rule).
-
-```python
-# Standalone comment (e.g. to make a section in a file)
-
-# Comment for the cc_library below
-cc_library(name = "cc")
-```
-
-## Conventions
-
- * Use uppercase and underscores to declare constants (e.g. `GLOBAL_CONSTANT`),
-   use lowercase and underscores to declare variables (e.g. `my_variable`).
-
- * Labels should be canonicalized. Use `//foo/bar` instead of `//foo/bar:bar`.
-   Use `:bar` if it is defined in the same package. *Rationale*: It makes clear
-   if a label is local to a package. Sorting a list of labels is messy if all
-   labels do not use the same conventions.
-
- * Labels should never be split, even if they are longer than 79 characters.
-   Labels should be string literals whenever possible. Rationale: It makes
-   find and replace easy. It also improves readability.
-
- * The value of the name attribute should be a literal constant string (except
-   in macros). *Rationale*: External tools use the name attribute to refer a
-   rule. They need to find rules without having to interpret code.
-
-## Differences with Python style guide
-
-Although compatibility with
-[Python style guide](https://www.python.org/dev/peps/pep-0008/) is a goal, there
-are a few differences:
-
- * No strict line length limit. Long comments and long strings are often split
-   to 79 columns, but it is not required. It should not be enforced in code
-   reviews or presubmit scripts. *Rationale*: Labels can be long and exceed this
-   limit. It is common for `BUILD` files to be generated or edited by tools, which
-   does not go well with a line length limit.
-
- * Implicit string concatenation is not supported. Use the `+` operator.
-   *Rationale*: `BUILD` files contain many string lists. It is easy to forget a
-   comma, which leads to a complete different result. This has created many bugs
-   in the past. [See also this discussion.](https://lwn.net/Articles/551438/)
-
- * Use spaces around the `=` sign for keywords arguments in rules. *Rationale*:
-   Named arguments are much more frequent than in Python and are always on a
-   separate line. Spaces improve readability. This convention has been around
-   for a long time, and we don't think it is worth modifying all existing
-   `BUILD` files.
-
- * By default, use double quotation marks for strings. *Rationale*: This is not
-   specified in the Python style guide, but it recommends consistency. So we
-   decided to use only double-quoted strings. Many languages use double-quotes
-   for string literals.
-
- * Use a single blank line between two top-level definitions. *Rationale*: The
-   structure of a `BUILD` file is not like a typical Python file. It has only
-   top-level statements. Using a single-blank line makes `BUILD` files shorter.