Add ga-beacon analytics to gendocs scripts
hack/run-gendocs.sh puts ga-beacon analytics link into all md files, hack/verify-gendocs.sh verifies presence of link.
This commit is contained in:
Jeff Lowdermilk
parent
b67f72a316
commit
e1d595ebbd
|
|
@ -19,3 +19,6 @@ Docs in this directory relate to developing Kubernetes.
|
|||
and how the version information gets embedded into the built binaries.
|
||||
|
||||
* **Profiling Kubernetes** ([profiling.md](profiling.md)): How to plug in go pprof profiler to Kubernetes.
|
||||
|
||||
|
||||
[]()
|
||||
|
|
|
|||
|
|
@ -332,3 +332,6 @@ the change gets in. If you are unsure, ask. Also make sure that the change gets
|
|||
## Adding new REST objects
|
||||
|
||||
TODO(smarterclayton): write this.
|
||||
|
||||
|
||||
[]()
|
||||
|
|
|
|||
|
|
@ -5,3 +5,6 @@ Coding style advice for contributors
|
|||
- https://github.com/golang/go/wiki/CodeReviewComments
|
||||
- https://gist.github.com/lavalamp/4bd23295a9f32706a48f
|
||||
|
||||
|
||||
|
||||
[]()
|
||||
|
|
|
|||
|
|
@ -38,3 +38,6 @@ PRs that are incorrectly judged to be merge-able, may be reverted and subject to
|
|||
## Holds
|
||||
|
||||
Any maintainer or core contributor who wants to review a PR but does not have time immediately may put a hold on a PR simply by saying so on the PR discussion and offering an ETA measured in single-digit days at most. Any PR that has a hold shall not be merged until the person who requested the hold acks the review, withdraws their hold, or is overruled by a preponderance of maintainers.
|
||||
|
||||
|
||||
[]()
|
||||
|
|
|
|||
|
|
@ -333,3 +333,6 @@ export KUBERNETES_MINION_MEMORY=2048
|
|||
|
||||
#### I ran vagrant suspend and nothing works!
|
||||
```vagrant suspend``` seems to mess up the network. It's not supported at this time.
|
||||
|
||||
|
||||
[]()
|
||||
|
|
|
|||
|
|
@ -267,3 +267,6 @@ git remote set-url --push upstream no_push
|
|||
```
|
||||
hack/run-gendocs.sh
|
||||
```
|
||||
|
||||
|
||||
[]()
|
||||
|
|
|
|||
|
|
@ -175,3 +175,6 @@ take the place of common sense and good taste. Use your best judgment, but put
|
|||
a bit of thought into how your work can be made easier to review. If you do
|
||||
these things your PRs will flow much more easily.
|
||||
|
||||
|
||||
|
||||
[]()
|
||||
|
|
|
|||
|
|
@ -64,3 +64,6 @@ Eventually you will have sufficient runs for your purposes. At that point you ca
|
|||
If you do a final check for flakes with ```docker ps -a```, ignore tasks that exited -1, since that's what happens when you stop the replication controller.
|
||||
|
||||
Happy flake hunting!
|
||||
|
||||
|
||||
[]()
|
||||
|
|
|
|||
|
|
@ -17,3 +17,6 @@ Definitions
|
|||
* design - priority/design is for issues that are used to track design discussions
|
||||
* support - priority/support is used for issues tracking user support requests
|
||||
* untriaged - anything without a priority/X label will be considered untriaged
|
||||
|
||||
|
||||
[]()
|
||||
|
|
|
|||
|
|
@ -24,3 +24,6 @@ The following conventions for the glog levels to use. [glog](http://godoc.org/g
|
|||
* Logging in particularly thorny parts of code where you may want to come back later and check it
|
||||
|
||||
As per the comments, the practical default level is V(2). Developers and QE environments may wish to run at V(3) or V(4). If you wish to change the log level, you can pass in `-v=X` where X is the desired maximum level to log.
|
||||
|
||||
|
||||
[]()
|
||||
|
|
|
|||
|
|
@ -32,3 +32,6 @@ to get 30 sec. CPU profile.
|
|||
## Contention profiling
|
||||
|
||||
To enable contention profiling you need to add line ```rt.SetBlockProfileRate(1)``` in addition to ```m.mux.HandleFunc(...)``` added before (```rt``` stands for ```runtime``` in ```master.go```). This enables 'debug/pprof/block' subpage, which can be used as an input to ```go tool pprof```.
|
||||
|
||||
|
||||
[]()
|
||||
|
|
|
|||
|
|
@ -14,3 +14,6 @@ We want to limit the total number of PRs in flight to:
|
|||
* Maintain a clean project
|
||||
* Remove old PRs that would be difficult to rebase as the underlying code has changed over time
|
||||
* Encourage code velocity
|
||||
|
||||
|
||||
[]()
|
||||
|
|
|
|||
|
|
@ -163,3 +163,6 @@ After this summary, preamble, all the relevant PRs/issues that got in that
|
|||
version should be listed and linked together with a small summary understandable
|
||||
by plain mortals (in a perfect world PR/issue's title would be enough but often
|
||||
it is just too cryptic/geeky/domain-specific that it isn't).
|
||||
|
||||
|
||||
[]()
|
||||
|
|
|
|||
|
|
@ -97,3 +97,6 @@ These guidelines say *what* to do. See the Rationale section for *why*.
|
|||
if you use another Configuration Management tool -- you just have to do some manual steps
|
||||
during testing and deployment.
|
||||
|
||||
|
||||
|
||||
[]()
|
||||
|
|
|
|||
Loading…
Reference in New Issue