Age | Commit message (Collapse) | Author |
|
PiperOrigin-RevId: 303805784
|
|
PiperOrigin-RevId: 303773475
|
|
|
|
This enables all relevant santizers (though most analyzers will not find
much, it will prevent instances from creeping in), and codifies existing
exceptions in tools/nogo.js to be fixed.
|
|
There is a canonical naming convention for Examples, which are checked
by analyzers. This must be fixed since adding exceptions for generated
code will be more challenging.
|
|
The posix_server works fine when run in locally or in docker but fails in the
kokoro GCP build environment. Linking libpthread statically fixes it.
PiperOrigin-RevId: 302139082
|
|
Fixes random stuff that is broken on bazel/kokoro.
- random output coming back as "bytes" object instead of str
- missed syntax error in bazel
- a flag is missing in the version of gcloud on kokoro
PiperOrigin-RevId: 301915289
|
|
PiperOrigin-RevId: 301382690
|
|
|
|
This is frequently causing the core build scripts to fail. The core ubuntu
distribution will perform an auto-update at first start, which may cause the
lock file to be held. All apt-get commands may be done in a loop in order to
retry to avoid this issue. We may want to consider retrying other pieces, but
for now this should avoid the most frequent cause of build flakes.
PiperOrigin-RevId: 297704789
|
|
PiperOrigin-RevId: 297693838
|
|
PiperOrigin-RevId: 297628615
|
|
PiperOrigin-RevId: 296519566
|
|
Sometimes, when we start a new instance, the file
lock on "apt" is locked. Add a loop to the master
installer.
In addition, the "apt-get install" fails to register
runsc in docker, so run the appropriate scripts to
get that to happen.
Also, add some helpful log messages.
PiperOrigin-RevId: 296497357
|
|
PiperOrigin-RevId: 296322954
|
|
Users of the API only care about whether the copy in/out succeeds in
their entirety, which is already signalled by the returned error.
PiperOrigin-RevId: 296297843
|
|
This simplifies the script slightly.
PiperOrigin-RevId: 296272077
|
|
PiperOrigin-RevId: 296104390
|
|
This can happen due to conditional compilation, where a subset of the
source files contain no marshallable types. go-marshal is still
required to write an output file in these cases, since bazel defines
the output package before calling go-marshal.
PiperOrigin-RevId: 296074321
|
|
Since we tag entire packages as marshallable, due to conditional
compiling for different architectures we can end up with sets of
source files that don't contain any marshallable types. It's safe to
silently ignore this scenario.
PiperOrigin-RevId: 295831871
|
|
This lets go-marshal replace various calls to binary.Size() throughout
the sentry without requiring concrete objects.
PiperOrigin-RevId: 295299965
|
|
PiperOrigin-RevId: 295269654
|
|
Note that this is not an automated test.
PiperOrigin-RevId: 295238672
|
|
- Add missing build tags to files in the abi package.
- Add the marshal package as a sentry dependency, allowed by deps_test.
- Fix an issue with our top-level go_library BUILD rule, which
incorrectly shadows the variable containing the input set of source
files. This caused the expansion for the go_marshal clause to
silently omit input files.
- Fix formatting when copying build tags to gomarshal-generated files.
- Fix a bug with import statement collision detection in go-marshal.
PiperOrigin-RevId: 295112284
|
|
Add new Marshallable interface methods CopyIn/CopyOut, which can be directly
called on the marshalled object, avoiding an interface indirection. Such
indirections are problematic because they always cause the marshalled object to
escape.
PiperOrigin-RevId: 295028010
|
|
PiperOrigin-RevId: 294930818
|
|
This is to avoid conflicts with types that share the same
[short] package and type names, e.g. proc.smapsData exist
in pkg/sentry/fs/proc and pkg/sentry/fsimpl/proc.
Updates #1663
PiperOrigin-RevId: 294485146
|
|
The name 'bazel' also doesn't work because bazel will treat it specially.
Fixes #1807
PiperOrigin-RevId: 294321221
|
|
PiperOrigin-RevId: 294271541
|
|
PiperOrigin-RevId: 294265019
|
|
Change adds the following:
- logic to run from "baked images". See [GVISOR_DIR]/tools/images
- installers which install modified files from a workspace. This
allows users to run benchmarks while modifying runsc.
- removes the --preemptible tag from built GCE instances. Preemptible
instances are much more likely to be preempted on startup, which
manifests for the user as a failed benchmark. I don't currently have
a way to detect if a VM has been preempted that will work for this
change.
https://cloud.google.com/compute/docs/instances/preemptible#preemption_process
https://cloud.google.com/compute/docs/instances/preemptible#preemption_selection
PiperOrigin-RevId: 293697949
|
|
These were out-of-band notes that can help provide additional context
and simplify automated imports.
PiperOrigin-RevId: 293525915
|
|
Note that files will need to be appropriately segmented in order for the
mechanism to work, in suffixes implying special tags. This only needs to happen
for cases where marshal or state structures are defined, which should be rare
and mostly architecture specific.
PiperOrigin-RevId: 293231579
|
|
PiperOrigin-RevId: 292458933
|
|
Because the abi will depend on the core types for marshalling (usermem,
context, safemem, safecopy), these need to be flattened from the sentry
directory. These packages contain no sentry-specific details.
PiperOrigin-RevId: 291811289
|
|
The preferred Copyright holder is "The gVisor Authors".
PiperOrigin-RevId: 291786657
|
|
PiperOrigin-RevId: 291745021
|
|
This formalizes the adhoc scripts previously in kokoro. The image targets can
be used by e.g. benchmarks in order to automated image prepation.
PiperOrigin-RevId: 290982744
|
|
For everyone's joy, this is a tool that reopens issues that
have been closed, but are still referenced by TODOs in the
code. The idea is to run it in Kokoro nightly. Kokoro changes
are coming up next.
PiperOrigin-RevId: 288789560
|
|
PiperOrigin-RevId: 286667216
|
|
With the ticks, the command `master` is actually be run and the output included
(which is nothing). This is confusing, as we actually mean to say "master" in
the description of the Go branch.
PiperOrigin-RevId: 282426081
|
|
PiperOrigin-RevId: 281795269
|
|
The tag script, when not run interactively, will fail without a provided commit
message (since it now uses annotated tags). For now, use a trivial message. In
the future, this could be extended to provide automated release notes.
PiperOrigin-RevId: 281112651
|
|
This fixes a number of issues with the repository build process:
* Fix the overall structure of the repository.
* Fix the debian package description.
* Fix the broken version number for packages.
* Update the digest algorithm used for signing the release.
I've validated that installation works from a separate staging bucket.
Updates #852
PiperOrigin-RevId: 278716914
|
|
Also, construct the README directly so that edits can be made.
PiperOrigin-RevId: 277782095
|
|
2 jobs were finished in this patch:
1, add a new attribute to specify the target platform.
2, check the source files that whether we can build this file for target platform by checking file name and build tags.
Signed-off-by: Bin Lu <bin.lu@arm.com>
|
|
PiperOrigin-RevId: 275139066
|
|
The RELEASE file must be at the top-level for the signed
repository to work correctly.
PiperOrigin-RevId: 269897109
|
|
They are no-ops, so the standard rule works fine.
PiperOrigin-RevId: 268776264
|
|
PiperOrigin-RevId: 268772451
|