8f43fdbcf5
* render-tests: Remove test output from flaky test reporter Remove the output from the summary output by render-tests in the flakiness reporting mode. Sometimes this output is very large depending on the test that failed, and we fail to post it to Slack due to the length. This only changes what is written to the summary file. Stdout still contains the failed test output. When posted to Slack, the message will have a link to the run logs which will contain the failed test output. This output will be sorted alphabetically by package/test name and not by failure rate, as it was before. * render-tests: Print number of failure, not percentage Print the number of failures from the total number of tests in the flakiness report instead of percentages. Since we run less than 100 test runs, the percentage is not that useful. It is more useful to see that a test failed only once, for example, not 14.1% of the time. * render-tests: Fix expected/actual ordering in tests Fix the tests for render-tests where expected/actual params were backwards. * render-tests: Dont collect test output against package Keep individual test output separate from package-level output. Previously, all individual test output was recorded against a package too and only the package output was printed if no tests in the package failed. This meant we lost output for package-level failures such as data races and crashes (segfaults) when there was an individual test failure too. There was no reason I could tell why it was done this way, so remove it. This should now print all test failures. * render-tests: Include packages in top flakiness summary Include packages as well as individual tests in the flakiness summary, as packages can have failures where no individual tests failed, such as data races or crashes - both of these are recorded as a package-level failure and not against individual tests. Without these in the summary, we miss some failures. * Change (M from N) to (M/N) in flaky summary |
||
---|---|---|
.. | ||
charts | ||
flake | ||
gpg | ||
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-centos7 | ||
Dockerfile-centos7-assets | ||
Dockerfile-centos7-fips | ||
Dockerfile-connect | ||
Dockerfile-grpcbox | ||
Dockerfile-multiarch | ||
Dockerfile-multiarch-base | ||
Dockerfile-multiarch-clang | ||
genproto.sh | ||
grpcbox.mk | ||
images.mk | ||
install | ||
keychain-setup.sh | ||
locale.gen | ||
Makefile | ||
profile | ||
README.md |
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
migrationBranch
variable 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 apps login drone
and follow any prompts. - Run
tsh proxy app drone
and 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
migrationBranch
string 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.