mirror of
https://github.com/gravitational/teleport
synced 2024-10-19 16:53:57 +00:00
3ac5a0aedb
* Adjust go_package of lib/prehog Go protobufs This makes them follow the pattern set out by api/proto and proto. * Adjust go_package of lib/teleterm Go protobufs * Use single buf.gen.yaml to generate JS protos This also entailed changing the location of lib/teleterm protos and changing the value of their package specifier to match the conventions in other parts of the codebase. This is a breaking change but that is fine for Connect as the protos are used locally only and each build ships with matching protobufs. * Make web/packages/teleterm use protobufs from gen-proto-js We used to copy protobufs over to web/packages/teleterm/src/services/tshd since webapps used to be in a separate repo. This is no longer the case, so we can just make teleterm use protobufs from gen-proto-js. * Move prehog & teleterm protos into proto/teleport/lib * Generate JS protos to gen/proto/js * Move lib/teleterm Go protobufs to gen/proto/go * Move lib/prehog Go protobufs to gen/proto/go * Rename lib/teleterm proto package * Re-enable linter rules for teleterm & prehog * Update prehogv1 path in usagereporter_test.go * Use except instead of ignore_only to allow Google API-style responses * Add UNARY_RPC to api/proto & proto * Ignore gen/ when running addlicense * buf-js.gen.yaml: Remove comment about lack of go_package for JS * Move prehog protos to proto/prehog/v1alpha * Adjust prehog's go_package to match proto package |
||
|---|---|---|
| .. | ||
| charts | ||
| macos | ||
| pam | ||
| pkgconfig | ||
| rpm | ||
| rpm-sign | ||
| tooling | ||
| windows | ||
| .bashrc | ||
| .dockerignore | ||
| .gitignore | ||
| build-common.sh | ||
| build-fido2-macos.sh | ||
| build-package.sh | ||
| build-pkg-tsh.sh | ||
| build-test-compat.sh | ||
| build-webassets-if-changed.sh | ||
| Dockerfile | ||
| Dockerfile-arm | ||
| Dockerfile-arm-fips | ||
| Dockerfile-centos7 | ||
| Dockerfile-centos7-assets | ||
| Dockerfile-centos7-fips | ||
| Dockerfile-fips | ||
| Dockerfile-multiarch | ||
| genproto.sh | ||
| images.mk | ||
| install | ||
| locale.gen | ||
| Makefile | ||
| profile | ||
| README.md | ||
| teleterm_linux_arm64.toolchain.cmake | ||
Dockerized Teleport Build
This directory is used to produce a containerized production Teleport build. No need to have Golang. Only Docker is required.
It is a part of Gravitational CI/CD pipeline. To build Teleport type:
make
Safely updating build box Dockerfiles
The build box images are used in Drone pipelines and GitHub Actions. The resulting image is pushed to Amazon ECR and ghcr.io. This means that to safely introduce changes to Dockerfiles, those changes should be split into two stages:
- First you open a PR which updates a Dockerfile and get the PR merged.
- Once it's merged, Drone is going to pick it up, build a new build box image and push it to Amazon ECR.
- Then you can open another PR which starts using the new build box image.
DynamoDB static binary docker build
The static binary will be built along with all nodejs assets inside the container. From the root directory of the source checkout run:
docker build -f build.assets/Dockerfile.dynamodb -t teleportbuilder .
Then you can upload the result to an S3 bucket for release.
docker run -it -e AWS_ACL=public-read -e S3_BUCKET=my-teleport-releases -e AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY teleportbuilder
Or simply copy the binary out of the image using a volume (it will be copied to current directory/build/teleport.
docker run -v $(pwd)/build:/builds -it teleportbuilder cp /gopath/src/github.com/gravitational/teleport/teleport.tgz /builds
OS package repo migrations
An OS package repo migration is semi-manually publishing specific releases to the new APT and YUM repos. This is required in several situations:
- A customer requests that we add an older version to the repos
- We add another OS package repo (for example APK)
- A OS package promotion fails (for example https://drone.platform.teleport.sh/gravitational/teleport/14666/1/3), requires a PR to fix, and we don't want to cut another minor version
Multiple migrations can be performed at once. To run a migration do the following:
- Clone https://github.com/gravitational/teleport.git.
- Change to the directory the repo was cloned to.
- Create a new branch from master.
- Add the Teleport versions you wish to migration as demonstrated here:
151a2f489e (diff-2e3a64c97d186491e06fb2c7ead081b7ace2b67c4a4d974a563daf7c117a2c50). - Set the
migrationBranchvariable to the name of the branch you created in (3) as demonstrated here:151a2f489e (diff-2e3a64c97d186491e06fb2c7ead081b7ace2b67c4a4d974a563daf7c117a2c50). - Get your Drone credentials from here: https://drone.platform.teleport.sh/account.
- Export your drone credentials as shown under "Example CLI Usage" on the Drone account page
- Open a new terminal.
- Run
tsh app login droneand follow any prompts. - Run
tsh proxy app droneand copy the printed socket. This should look something like127.0.0.1:60982 - Switch back to your previous terminal.
- Run
export DRONE_SERVER=http://{host:port}, replacing{host:port}with the data you copied in (10) - Run
make dronegen - Commit the two changed files and push/publish the branch
- Open a PR merging your changes into master via https://github.com/gravitational/teleport/compare
- Under the "checks" section, click "details" on the check labeled "continuous-integration/drone/push"
- Once the pipelines complete, comment out the versions you added and blank out the
migrationBranchstring set in (4, 5) as demonstrated here:9095880560 (diff-2e3a64c97d186491e06fb2c7ead081b7ace2b67c4a4d974a563daf7c117a2c50) - Run
make dronegen - Commit and push the changes.
- Merge the PR and backport if required.