Do not publish any pre-release versions to deb/rpm repos

[wadells]

Summary

We've seen a couple pre-release tags escape into our packages repos:

• teleport_6.2.14-debug
• teleport_6.2.18-label-debug

Instead of blocking a shortlist of unwanted tags, we now do not release
packages for any version with a '-' (prerelease) or a '+' (includes
build metadata), as either of these are noise our customers probably
don't need to see.

Testing Done

$ echo v6.2.18-label-debug.2  | egrep -v '[-+]'
$ echo $?
1
$ echo v8.0.0+12345678  | egrep -v '[-+]'
$ echo $?
1
$ echo v8.0.0  | egrep -v '[-+]'
v8.0.0
$ echo $?
0

Other Tasks

I'll remove the two pre-release versions from our deb and rpm repos if/when this merges and is fully backported.

[russjones]

@wadells This will prevent debug builds from getting into the deb/rpm repos, however it won't prevent rolling back to older versions.

A hack I have been thinking about to fix this problem, we write a small Go program and just check it into build.assets, let's say we call it version-check. In Drone you run it like this:

./build.assets/version-check $DRONE_TAG

The program would be very small, a few hundred lines. Basically calls the GitHub API to get all tags (you can use https://github.com/google/go-github) and just makes sure $DRONE_TAG is strictly newer than the newest tag returned from the GitHub API.

Still won't solve the problem of not hosting multiple versions in our deb repo, but would prevent pre-releases and rollbacks.

[wadells]

@wadells This will prevent debug builds from getting into the deb/rpm repos, however it won't prevent rolling back to older versions.

Correct -- this is orthogonal to the deb repo rollback issue. One of @fspmarshall's debug builds last week triggered this PR. I think this is a nice beginner change as I get familiar with a new part of Teleport's build. I believe this change has merit on its own, but let me know if you'd rather I roll it in with a fix for #8166.

A hack I have been thinking about to fix this problem, we write a small program and just check it into build.assets, let's say we call it version-check. In Drone you run it like this:

./build.assets/version-check $DRONE_TAG

The program would be very small, a few hundred lines. Basically calls the GitHub API to get all tags (you can use https://github.com/google/go-github) and just makes sure $DRONE_TAG is strictly newer than the newest tag returned from the GitHub API.

Still won't solve the problem of not hosting multiple versions in our deb repo, but would prevent pre-releases and rollbacks.

This will catch rollback (the bigger issue) but we'd still be vulnerable to v8.1.0-something tags slipping though without the change herein.

[russjones]

You would also add checking for pre-releases in the Go program.

The advantage here is you would:

• Use a parser to parse structured data (semver) instead of grep.
• Consolidate all logic to one spot.

[wadells]

You would also add checking for pre-releases in the Go program.

The advantage here is you would:

* Use a parser to parse structured data (semver) instead of grep.

* Consolidate all logic to one spot.

Roger -- sounds like you're not interested in this version of the fix. I'll include pre-release filtering in the rollback patch stack.