Add a couple of parameters for the developer key ID and bundle ID for
signing/notarizing binaries. Keep the hard-coded values as defaults for
now, but we will remove these soon when all the call sites of the tool
have been updated to pass these values.
We want to parameterize these values so we can use different signing
keys in GitHub Actions and to make the tool agnostic to which binaries
it is signing.
* Added `--target-cloud` flag to OS package repo tool
* Updated OS package repo tool to use "version channel" instead of "artifact version"
* Added help flag examples
* Install deb/yum repos when using node-join script
When a repo is available for the current Linux distro/version, use it
instead of just installing Teleport from the deb/rpm files.
It fallsback to the traditional binary installation when the repo is not
available.
* comment /etc/os-release
* remove sudo; add comment to runners
* improve is_repo_available function
As we're now using a GitHub app to dispatch workflow requests from Drone to GHA, this patch updates the workflow runner script to handle app authentication.
In preparation for moving some builds from Drone to GHA, we need some
way for Drone to invoke a workflow in GHA and await the result. Handles
timeouts and workflow inputs as well.
Co-authored-by: Nic Klaassen <nic@goteleport.com>
Co-authored-by: Anton Miniailo <anton@goteleport.com>
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>
Ports used by the unit tests have been allocated by pulling them out of a list, with no guarantee that the port is not actually in use. This central allocation point also means that tests cannot be split into separate packages to be run in parallel, as the ports allocated between the various packages will be allocated multiple times and end up intermittently clashing.
There is also no guarantee, even when the tests are run serially, that the ports will not clash with services already running on the machine.
This patch (largely) replaces the use of this centralised port allocation with pre-created listeners injected into the test via the file descriptor import mechanism use by Teleport to pass open ports to child processes.
There are still some cases where the old port allocation system is still in use. I felt this was already getting beyond the bounds of sensibly reviewable, so I have left those for a further PR after this.
See-Also: #12421
See-Also: #14408
This commit updates drone to build Teleport Connect by:
* cloning `gravitational/webapps` as a sibling directory to
gravitational/teleport
* checkout out the right version of webapps by running a simple
Go program (this step is only necessary until we move webapps
into the teleport repo)
* Running the Teleport Connect build and copying artifacts
Code signing should run on tag builds automatically as part the
electron build, assuming the Apple Account credentials are
properly loaded into the keychain.
Notarization will also happen automatically if both
`$APPLE_USERNAME` and `$APPLE_PASSWORD` are set.
In order to make the above happen, this patch also includes:
* Installing and removing a per-build Node instance in the
toolchain directory on Darwin
* Moving the toolchain temporary directory out of ~/ and into /tmp.
Drone usually sets `$HOME` to a temporary directory for each build,
but unfortunately we need it to point to the actual build user's
home directory in order for the notarisation tooling to find the
right keychain. Having $HOME point to a long-lived directory risks
both pollution from build detritus and builds stomping on one another.
In an in an attempt to isolate the builds from each other and protect
`~build` as best we can, as much of the build state as possible
(including ephemeral toolchains) has been moved under `/tmp`.
Co-authored-by: Trent Clarke <trent@goteleport.com>
We do not publish pre-releases to apt repos, but we do publish them to
github. That means we need to filter them out when considering if an
apt release should be published. We don't want v8.3.3 to be blocked by
v9.0.0-dev.1, only by v9.0.0.
Honestly, this is a bit of a mess, but it only needs to hold out a bit
longer until https://github.com/gravitational/teleport/pull/10746 lands.
Contributes to https://github.com/gravitational/teleport/issues/10800
This gives us a robust way to find the latest published release for a
Major or Major.Minor version. This logic is useful for our automation
that publishes up-to-date teleport:X docker images
Contributes to https://github.com/gravitational/teleport/issues/9494
These should not be factored in when checking for the latest release
when we decide if we should release apt packages.
This also fixes a bug in sorting logic, where we were sorting
lexigraphically instead of by semver.
9 was comparing greater than 10, due to use of lexographic sorting
This would cause us to fail to publish apt packages when we roll over to
a patch release > 9.
Linting for non-go files was accidentally dropped in the transition to
GCB (sorry!). This patch restores linting for non-go files and fixes
any lint failures that have crept in during the interim.
Actually tracking down the cause of a failure in the integration tests can
be hard:
* It's hard to get an overall summary of what failed
* The tests sometimes emit no output before timing out, meaning any
diagnostic info is lost
* The emitted logs are too voluminous for a human to parse
* The emitted logs can present information out of order
* It's often hard to tell where the output from one test ends
and the next one begins
This patch attempts to address these concerns without attempting to rewrite
any of the underlying teleport logging.
* It improves the render-tests script to (optionally) report progress per-
test, rather than on a per-package basis. My working hypothesis on the
tests that time out with no output is that go test ./integration is
waiting for the entire set of integration tests tests to be complete
before reporting success or failure. Reporting on a per-test cycle gives
faster feedback and means that any timed-out builds should give at least
some idea of where they are stuck.
* Adds the render-tests filter to the integration and integration-root make
targets. This will show an overall summary of test results, as well as
- Discarding log output from passing tests to increase signal-to-noise
ratio, and
- Strongly delimiting the output from each failed test, making failures
easier to find.
* Removes the notion of a failure-only logger in favour of post-processing
the log events with render-tests. The failure-only logger catches log
output from the tests and only forwards it to the console if the test
fails. Unfortunately, not all log output is guaranteed to pass through
this logger (some teleport packages do not honour the configured logger,
and reports from the go race detector certainly don't), meaning some
output is presented at the time it happens, and other output is batched
and displayed at the end of the test. This makes working out what
happened where harder than it need be.
In addition, this patch also promotes the render-tests script into a fully-
fledged program, with appropriate makefile targets, make clean support, etc.
It is now also more robust in the face on non-JSON output from go test
(which happens if a package fails to compile).
Cam Hutchison