This makes gocross and its bootstrap script understand an absolute
path in go.toolchain.rev to mean "use the given toolchain directly".
Signed-off-by: David Anderson <danderson@tailscale.com>
We need to build gocross from multiple repos, but Go's innate
git hash embedding only works when you build gocross from this repo,
not when you build it from elsewhere via 'go build
tailscale.com/tool/gocross'. Instead, explicitly embed the version
found with 'git rev-parse HEAD', which will work from any git repo.
Signed-off-by: David Anderson <danderson@tailscale.com>
This avoids accidentally overwriting variables from the input
environment, which might non-deterministically change the behavior
of gocross.
Signed-off-by: David Anderson <danderson@tailscale.com>
Turns out directing the printed script into the bootstrap location leads
to irritating "text file busy" problems and then having to muck about with
tempfiles and chmod and all that. Instead, have gocross write everything
with the right values.
Signed-off-by: David Anderson <danderson@tailscale.com>
So that when importing and using gocross from other repos, there's
an easy way to get at the right wrapper script that's in sync with
the gocross binary.
Signed-off-by: David Anderson <danderson@tailscale.com>
trimmed builds don't have absolute path information in executable
metadata, which leads the runtime.Caller approach failing
mysteriously in yarn with complaints about relative package paths.
So, instead of using embedded package metadata to find paths,
expect that we're being invoked within the tailscale repo, and
locate the tsconnect directory that way.
Signed-off-by: David Anderson <danderson@tailscale.com>
These RPCs will be used to power the future 'tailscale lock remove' default behavior
of resigning signatures for which trust is about to be removed.
Signed-off-by: Tom DNetto <tom@tailscale.com>
Also add some basic tests for this implementation.
Signed-off-by: Andrew Dunham <andrew@du.nham.ca>
Change-Id: I307ebb6db91d0c172657befb276b38ccb638f828
armv5 because that's what we ship to most downstreams right now,
armv7 becuase that's what we want to ship more of.
Fixes https://github.com/tailscale/tailscale/issues/7269
Signed-off-by: David Anderson <danderson@tailscale.com>
CI status doesn't collapse into "everything OK" if a job gets
skipped. Instead, always run the job, but skip its only step in PRs.
Signed-off-by: David Anderson <danderson@tailscale.com>
Replaces the former shell goop, which was a shell reimplementation
of a subset of version/mkversion.
Signed-off-by: David Anderson <danderson@tailscale.com>
With this change, you can collect version info from either a git
checkout of the tailscale.com Go module (this repo), or a git
checkout of a repo that imports the tailscale.com Go module.
Signed-off-by: David Anderson <danderson@tailscale.com>
No particular reason. Just good point of our release cycle for some #cleanup.
It also makes dependabot happy about something we're not using?
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
This ensures that we put the kubeconfig in the correct directory from within the macOS Sandbox when
paired with tailscale/corp@3035ef7
Updates #7220
Signed-off-by: Maisem Ali <maisem@tailscale.com>
This isn't currently supported due to missing support in upstream
dependencies, and also we don't use this package anywhere right now.
Just conditionally skip this for now.
Fixes#7268
Change-Id: Ie7389c2c0816b39b410c02a7276051a4c18b6450
Signed-off-by: Andrew Dunham <andrew@du.nham.ca>
So that I just get a quick PR to approve and merge instead of
periodically discovering that the SRI hash has bitrotted.
Signed-off-by: David Anderson <danderson@tailscale.com>
OSS-Fuzz doesn't update their version of Go as quickly as we do, so
we sometimes end up with OSS-Fuzz being unable to build our code for
a few weeks. We don't want CI to be red for that entire time, but
we also don't want to forget to reenable fuzzing when OSS-Fuzz does
start working again.
This change makes two configurations worthy of a CI pass:
- Fuzzing works, and we expected it to work. This is a normal
happy state.
- Fuzzing didn't compile, and we expected it to not compile. This
is the "OSS-Fuzz temporarily broken" state.
If fuzzing is unexpectedly broken, or unexpectedly not broken, that's
a CI failure because we need to either address a fuzz finding, or
update TS_FUZZ_CURRENTLY_BROKEN to reflect the state of OSS-Fuzz.
Signed-off-by: David Anderson <danderson@tailscale.com>
