* Update backend
* Update frontend
* Keep old plugin id
* Update docs
* Place doc images to a new directory
* Legacy support for stackdriver-auto alignment
* Consistent plugin name
* Apply suggestions from code review
Co-authored-by: Marcus Efraimsson <marcus.efraimsson@gmail.com>
Co-authored-by: Tobias Skarhed <1438972+tskarhed@users.noreply.github.com>
* Update docs
* Update public/app/plugins/datasource/cloud-monitoring/README.md
Co-authored-by: Marcus Efraimsson <marcus.efraimsson@gmail.com>
* Add reference to the data source formerly being named Stackdriver
* Update pkg/models/datasource.go
Co-authored-by: Carl Bergquist <carl@grafana.com>
* Fix gofmt
Co-authored-by: Marcus Efraimsson <marcus.efraimsson@gmail.com>
Co-authored-by: Tobias Skarhed <1438972+tskarhed@users.noreply.github.com>
Co-authored-by: Carl Bergquist <carl@grafana.com>
Profiling and tracing can now be enabled/disabled separately.
Adds argument for trace file path.
Support overriding profiling and tracing argument using
environment variables.
Update docs.
Fixes#20576
* pkg/cmd: Check errors
* pkg/cmd: Make sure server waits on services, even in case of error
* pkg/cmd: Inform of error to show help
* pkg/cmd: Only warn on failure to send systemd notification
* pkg/cmd: Don't log errors stemming from context cancelation
* pkg/cmd: Don't fail if unable to write to systemd
* Rename GrafanaServerImpl to Server
* Make flag dependencies explicit
* Extract method for building service graph
* Document and clarify methods
* Rename HttpServer to HTTPServer
* Feature: Introduce a grafana-cli wrapper
When our users install the *nix packed version of grafana, tendency is to use the services and scripts installed as part of the package for grafana-server. These leverage the default configuration options by specifying the several default paths.
This introduces a similar approach for the grafana-cli binary. We exposed it through a wrapper to ensure a proper configuration is in place. To enable that, we add the .real suffix to the original binary (grafana-cli.real) and then use a bash script named grafana-cli as the wrapper.
* Make the config and homepath flags global
* Introduce `configOverrides` as a global flag
This flag allows us to pass configuration overrides as a string.
The string follows the convention of configuration arguments separated by a space e.g. "cfg:default.paths.data=/dev/nullX cfg:default.paths.logs=/dev/nullX"
Also, it is backwards compatible with similar the previous configuration method through tailing arguments. Tailing arguments take presedence over the configuration options string.
* Only log configuration information in debug mode
* Move the grafana-cli binary to $GRAFANA_HOME/bin
As part of the package install process, we copy all the release files and
directories into the grafana home directory. This includes the /bin folder
from where we copied the binaries into their respective destinations.
After that, the /bin folder gets deleted as we don't want to keep
duplicates of the binaries around.
As part of this commit, we moved the re-creation of /bin within
grafana-home and the copy of the original binary (again) after the
folder gets deleted.
`grafana-cli` uses the third-party library to define the flags and not
the standard library. Using `flag.Parse` conflicts with the defined
flags from our third-party library.
In the case where `flag.Parse` is used, the CLI assumes that definitions
provided are not needed and will not define them; producing errors of
the kind `flag provided but not defined --example-flag`.
Using the context to read any arguments (including flags) is the
recommended approach by the third-party library.
grafana-cli should allow configuration overrides to be received from the command line. e.g.
```
grafana-cli admin reset-password cfg:default.paths.logs=custom/log/directory/
```
Seems like we missed the inclusion of `flag.Parse` as we run the command, to be able to consume them.
Additionally, it'll be useful for the user to know whenever these are being overriden or not - hence the addition of logging the configuration to be used as we run the command.
* Chore: explore possibilities of using makefile
This is an exploratory commit - I wanted to see how
revive/gosec linters could be integrated with makefile and our build scripts.
Looks better then I expected :)
* Chore: make revive happy
Revive execution was not supplied with path, if you restore there is couple
errors that were popping up - so I fixed them
* Chore: make revive happy
Since we do not like some of the default golint rules,
this commit proposes to use https://github.com/mgechev/revive.
And potential revive speed-up should't hurt :).
Right now, presented config (./conf/revive.toml) is permissive,
we might improve it over time however. Fixes for found revive
issues in the code are very limited so it wouldn't be large to review.
Also in this commit:
* Add annotations for makefile commands and declare phony targets
* Rename "gometalinter" script and CI command to "lint"
since we are doing there a bit more then using gometalinter package
* Add Makefile rules to .editorconfig
* Documentation which mentioned "golint" replaced with revive
Fixes#16109
Ref #16160
