* Unify x86/AMD64 build process
Currently, our ARM64 pipeline builds limited subset of Teleport features as none of the 3rd party dependencies (openssh, libbpf etc) are not built on AMR64. This change build all dependencies on AMR64 in the same way as we do on x86.
FIPS changes are not included as we do not support FIPS on ARM64.
* Apply suggestions from code review
Co-authored-by: Roman Tkachenko <roman@goteleport.com>
---------
Co-authored-by: Roman Tkachenko <roman@goteleport.com>
Update to libbpf 1.0.1 and github.com/aquasecurity/libbpfgo v0.4.5-libbpf-1.0.1. As we're building our releases on CentOS 7 anyway we can also switch to mainstream libbpf instead of using our fork.
Moving our CentOS build assets, aka Clang-10 is the first step to enabling our full Teleport to build on ARM64. This change should also save us some $$ as getting the assets from S3 sounds expensive.
* Update JS grpc-tools to 1.12.4
1.11.2 didn't have support for arm64 so we had to do all this extra stuff
in the Dockerfile.
1.11.3 added support for Darwin arm64 and 1.12.4 finally adds support for
Linux arm64. This means we can completely remove extra cruft and just
install grpc-tools 1.12.4 on all architectures.
* Add comment to ptyHostService.proto
* Add check if protos are up to date.
A new check has been added that will detect if protobufs are up to date. The
script will exit abnormally if protobufs need to be regenerated.
* Alan's feedback.
* Restoring the script.
* Update script comment.
* Add in the set -eu.
* Add a comment for the pull_request/merge_group bit in the new github action.
* Remove helper script.
* Reduce the runner size.
* Remove CLANG_FORMAT from Makefiles
It was used to format protos but we use Buf for that since v10.
* Move installing grpc_node_plugin into Dockerfile
This commit basically takes grpc_node_plugin compilation from
Dockerfile-teleterm and moves it to Dockerfile.
* Replace Dockerfile-teleterm with Dockerfile
After moving grpc_node_plugin compilation to Dockerfile, the only remaining
thing that Dockerfile-teleterm does is installing rpm so that we can make
an RPM package for Connect during tag builds.
Installing this package can be simply moved to Dockerfile.
* Remove grpc-teleterm Make target in favor of grpc
* Add updated protobufs
It looks like they're a result of someone changing protos in lib/prehog
without running `make grpc-teleterm` separately. Which is why we're getting
rid of grpc-teleterm as a separate Make target in the first place. ;)
Consolidates more of the build logic into the build.assets Makefile, transplanted from the workflow file in teleport.e
See comment gravitational/teleport.e#673 (comment)
The existing `build.assets` makefile targets had the actual build steps
coupled together with building the build box image. Because of how GHA
image builds work, we need to uncouple those tasks.
GHA also builds OSS and Enterprise teleports in parallel, so we needed
a new target to build the Enterprise release without also automatically
building the OSS bundle in series.
Co-authored-by: Roman Tkachenko <roman@goteleport.com>
* Include Go version in the cache key to prevent cache reuse when upgrading Go.
* Push buildboxes to Github container registry to avoid public ECR rate limiting.
Signed-off-by: Roman Tkachenko <roman@goteleport.com>
Co-authored-by: Victor Sokolov <gzigzigzeo@gmail.com>
* Use Teleport's standard buildbox
This commit edits the teleport-operator container image build process to
rely on Teleport's standard buildbox. This will make sure we are using a
single go version at all time.
This also removed unused environment variables from
`operator/Makefile`.
* Extract BUILDBOX variables out of build.assets/Makefile
* Put `teleport-operator` bin out of the Teleport source volume
* Add piv build dependencies.
- Add LIBPCSCLITE build tag.
- Add libpcsclite static linking using gravitational/pcsc fork.
- Enable use of dynamic pcsc library with LIBPCSCLITE=dynamic.
- Refactor CGOFLAG in Makefile.
- Update Centos7 Dockerfile and drone.
* Refactor RELEASE_MESSAGE for readability. Now produces message like: "RELEASE_MESSAGE=Building with GOOS=linux GOARCH=amd64 REPRODUCIBLE= and with PIV support and without PAM support, FIPS support, BPF support, Windows RDP client, libfido2, Touch ID."
Co-authored-by: Jakub Nyckowski <jakub.nyckowski@goteleport.com>
Uses Drone to build Teleport Connect for Windows on a Native
Windows builder.
This PR adds 2 pipelines to the Drone YAML:
1. `push-build-native-windows-amd64`: Invoked on a push to master,
branch/v*, etc., and asserts that Teleport Connect can be built, and
2. `build-native-windows-amd64`: Invoked when a branch tag is
committed to the teleport Repo. Builds Teleport Connect and uploads
it to dronestorage
These builds are run on a native windows builder (as opposed to tsh,
which is built in a linux environment and cross-compiled for Windows)
Change the proto layout of `api/` to a more standard setup, allowing the use of
modern tools (like Buf) to format/lint (and maybe, one day, generate sources).
The new layout looks like this:
``` api/ proto/ <- root of protos and proto imports teleport/ <- base
package for Teleport protos (akin to "google/" or "gogoproto/") legacy/ <- root
of "legacy" protos (most linters disabled) client/ proto/ types/ events/
webauthn/ wrappers/ ```
Non-legacy `api/` protos are expected to follow this layout:
``` api/ proto/ teleport/ mynewpackage/ <- package name v1/ <- protos
explicitly versioned gen/ proto/ <- root for generated sources
(multi-language possible, separate from hand-written code) go/ mynewpackage/ v1
<- generate Go sources go here. ```
Some outstanding issues, like lack of `go_package` declarations and non-standard
import paths (`import "github.com/gravitational/teleport/.../some.proto"`) are
fixed.
Legacy protos still have irregular package declarations. It's possible to fix
that, but it's a bit harder to reason about, as generated sources change in
possibly-meaningful ways.
Future iterations could change legacy packages to match the directory structure
and apply a similar change to protos within lib/ packages, but this seems
sufficient for a first step.
* Add Buf to buildbox
* Unify API protos under Buf
* Fix proto generation
* Reformat protos
* Update generated protos
* Generate protos using Buf
* Appease linter
* Review: make sure gogo protobuf versions are in sync
* Clean leftovers from previous attempts
* Fix operator/Makefile
* Rename internal make gRPC targets to `*/host`
* Sort `make fix-license` targets (nit)
* Add proof of concept of Connect pipeline
The proof of concept includes a lot of copy-pasted lines which will get
cleared up in subsequent commits.
* Extract copying artifacts into separate functions
The tag pipeline no longer needs to worry about Connect artifacts.
* Reuse steps to install & cleanup toolchains
* Share toolchain configuration commands between pipelines
* Share build commands among different pipelines
* Download webapps only if a pipeline builds Connect
As seen by the changes to .drone.yml, this removes unnecessary webapps
clones from these tag pipelines: build-darwin-amd64, build-darwin-amd64-pkg,
build-darwin-amd64-pkg-tsh. None of them needs webapps to function anymore
and the pkg pipelines never needed webapps in the first place.
In order to do so, we add a new make target:
make teleterm
This (temporarily) assumes that the gravitational/webapps repo is
cloned at the right version as a sibling to the teleport repo.
(We'll be able to get rid of this when we merge webapps into Teleport)
Additionally, update dronegen to include the name of the calling
function that generated the snippet instead of the line number.
This gets rid of lots of superfluous diffs in the generated
.drone.yml file.
Lastly, rewrite the Go program for getting the right webapps version
in bash, because Go is not available at this step of the drone pipeline.
Co-authored-by: Grzegorz Zdunek <grzegorz.zdunek@goteleport.com>
