| commit | 79c7e3574651a123efa499ebd5494a59f49d409a | [log] [tgz] |
|---|---|---|
| author | Mathieu Binette <mbinette@google.com> | Mon Dec 10 18:14:08 2018 |
| committer | Mathieu Binette <mbinette@google.com> | Mon Dec 10 21:59:06 2018 |
| tree | 42175ee8eaa9a82e1e024ea695e276f5f00b97e0 | |
| parent | 5da3fd90a4f37acab9a81b870da8f55140986e81 [diff] |
Implement RunCommand (cel_agent & cel_ctl)
(CL bonus: fixed existing `cel_ctl passwd ...` which didn't quite work (?))
Usage examples:
- Simple command:
> cel_ctl run --command 'echo "Hello world"' \
--instance client --builtins test.asset.textpb test.host.textpb
- Executable or big script:
> gsutil copy my_program.exe gs://my-bucket/
> cel_ctl run --command 'gsutil copy gs://my-bucket/my_program.exe .' \
--instance client --builtins test.asset.textpb test.host.textpb
> cel_ctl run --command 'my_program.exe my_arguments' \
--instance client --builtins test.asset.textpb test.host.textpb
I considered exiting `cel_ctl run` with EXITCODE=0 in the case of succesfully
executed failed commands to distinguish infra failures from command failures on
the VM, but some cases were ambiguous (e.g. failure to start the process, ...).
`cel_ctl run` will return 0 when the command succesfully exit(0) on the VM.
Aything else will throw.
I also thought about adding a `--file` flavor to `cel_ctl run` but decided
against it for now - it didn't feel flexible enough (e.g. `copy -r` for
executable dependencies, arguments, ...).
We can add a `cel_ctl copy` subcommand later to cover the most common use
cases (download/upload/extract archives, directories with `-r`, etc) and
replace steps 1 & 2 of the "Executable or big script" example.
Credit where credit is due:
- cel_agent monitoring code based off the GCE Agent reset password code.
- cel_ctl code heavily inspired by the existing `cel_ctl passwd` subcommand.
Coming up in a separate change:
- Integration with E2E tests
Change-Id: I582c99419332ead94b33036b8b0463c04e8907d5
Reviewed-on: https://chromium-review.googlesource.com/c/1362168
Reviewed-by: Fei Ling <feiling@chromium.org>
Chrome Enterprise Lab is an inaccurately named set of tools for building enterprise labs quickly and easily. The labs so built can be used for system level end-to-end testing of Google Chrome/Chromium.
Have a peek at the Design document.
Also have a peek at the Code of Conduct.
Most of the code is in Go. See Guide to code to get a head start on the code in this repository.
Go: Download Go from the Go download page. This project requires Go 1.9.4 or later. The build will fail with prior versions.
Depot Tools: Used for managing the checkout and the contributor workflow.
Protocol Buffers Compiler: Protocol buffers are used extensively for wranging all the data that needs to be shuttled around. Can be installed automatically via ./build.py deps --install.
Dep : Used for Go depedency management. This can be installed automatically by running ./build.py deps --install from the root of the source tree.
Go support for Protocol Buffers : This can be installed automatically by running ./build.py deps --install from the root of the source tree.
There are two ways to get the source. One is to use managed deps, and the other is to use plain go get. The latter workflow doesn't quite work yet due to this repository not being integrated with go.chromium.org. So this page only mentions the managed dependency workflow.
Clone this repository:
Assumes that $GOPATH is a single path and not a : delimited list.
mkdir -p ${GOPATH}/src/chromium.googlesource.com/enterprise cd ${GOPATH}/src/chromium.googlesource.com/enterprise git clone https://chromium.googlesource.com/enterprise/cel cd cel
Get the dependencies:
python build.py deps --install
Use the build script:
python build.py build
Also make sure the tests pass.
python build.py test
See CONTRIBUTING.