Fix yum repo cleanup

[wadells]

Previously, "${ARTIFACT_PATH}" was interpreted as Drone variable subsitution, resulting in "rm -rf ${ARTIFACT_PATH}/*" becoming "rm -rf /*", which deleted credentials on the filesystem. This causes the error seen here:

+ rm -rf "/*"
+ aws s3 sync --no-progress --delete --exclude "*" --include "*.rpm*" s3://$AWS_S3_BUCKET/teleport/tag/10.3.2/ "$ARTIFACT_PATH"
fatal error: An error occurred (AuthorizationHeaderMalformed) when calling the ListObjectsV2 operation: The authorization header is malformed; a non-empty Access Key (AKID) must be provided in the credential.

https://drone.platform.teleport.sh/gravitational/teleport/16371/2/5

This has been latent in the publishing logic for since https://github.com/gravitational/teleport/pull/14203/files#diff-b54b39f1afced2465e1f3641db9d5bbf4f3a7fcf890996dfedd3c197bcb7f8c7R5472, but it happened to not matter because we weren't storing anything important in the container's filesystem. I do wonder how the aws command was still available following the delete.

Backports:

• v11 [v11] Fix yum repo cleanup #17338
• v10 [v10] Fix yum repo cleanup #17335
• v9 [v9] Refactor Drone Pipelines to use AWS role assumption #17255

Testing Done

None -- a development build won't ever hit these codepaths. I'm happy to take suggestions of how we might test it.

[zmb3]

😱

[fheinecke]

Yea I definitely missed that on my initial implementation in the linked PR

I would recommend just doing $$ instead of removing braces. If I remember right Drone will still interpret $VAR the same as it would interpret ${VAR}. If you look at dronegen/promote.go that's how var escaping is handled.

Regarding testing... the only real way to test it is to inject "testing code" (like different secret names) that point to AWS resources in the dev account and then update the trigger to execute on branch push. Then revert those testing changes before merge. Very messy but it's the best way I'm aware of.

[wadells]

I would recommend just doing $$ instead of removing braces. If I remember right Drone will still interpret $VAR the same as it would interpret ${VAR}. If you look at dronegen/promote.go that's how var escaping is handled.

$ARTIFACT_PATH is what is used in the rest of the pipeline. See the mkdir on the line immediately above or the s3 command on the line after. I can use $$ if you prefer, but it'll be inconsistent with the other usages.

Regarding testing... the only real way to test it is to inject "testing code" (like different secret names) that point to AWS resources in the dev account and then update the trigger to execute on branch push. Then revert those testing changes before merge. Very messy but it's the best way I'm aware of.

Do you want me to test this? I can do so. I don't feel it is needed, but that is also how I got into this situation 😆 😭

[fheinecke]

$ARTIFACT_PATH is what is used in the rest of the pipeline. See the mkdir on the line immediately above or the s3 command on the line after. I can use $$ if you prefer, but it'll be inconsistent with the other usages.

Sorry yes you are correct. After reviewing the docs here it looks like $ARTIFACT_PATH and $${ARTIFACT_PATH} will be executed as expected, where ${ARTIFACT_PATH} will trigger Drone's substitution. Your changes look good to me as is.

Do you want me to test this?

I think it's relatively safe to assume that this will work and fix the problem as expected. Quite frankly I think it'd take longer to test than it would to open/merge another PR with a follow-up fix should something go wrong during migration of the latest release.