maint: remove interstitial linux subdir from S3 publish

[robbkidd]

This is a follow-up fix to the build/release overhaul in #103.

A similar change was made in multiple places, but the publish_s3 job was missed:

• In maint: release process updates for friendlier ARNs #103 for an OS-specific directory ZIP files will be created in
• In [release] Prepare v11.0.0 #108 for publishing assets to the GitHub Release from the Linux-specific directory

With this PR's change, the built artifacts will appear in S3 directly under the honeycomb-lambda-extension/<VERSION> subdirectory of the honeycomb-builds bucket to match the contents for past releases as opposed to in a honeycomb-lambda-extension/<VERSION>/linux subdirectory. This gets things back into alignment with the download URL given in docs for retrieving the layer contents for use in custom Docker images.

[kentquirk]

Can you elaborate a bit more, please? Like, why doesn't this change need to be made in multiple places, and what is the actual effect of eliminating these 6 characters? Are they just meaningless? Why were they there in the first place?

[robbkidd]

Yes! I should have elaborated from the beginning.

If what I write below makes sense, I'll copy some or all of it to the PR description for merge-commit-message posterity.

Quick Answers:

why doesn't this change need to be made in multiple places

The change was previously made in multiple places (in #103 and in 53da4b2 which was a follow-up change/fix like this one); this spot is a place that was missed.

what is the actual effect of eliminating these 6 characters?

The built artifacts will appear directly in S3 under the honeycomb-lambda-extension/<VERSION> subdirectory of the honeycomb-builds bucket (which matches the contents for past releases) instead of in a honeycomb-lambda-extension/<VERSION>/linux subdirectory. This gets things back into alignment with the download URL given in docs for retrieving the layer contents for use in custom Docker images.

Are they just meaningless? Why were they there in the first place?

A longer story …

A fair amount of build and release fiddly bits changed in #103. One major change was moving the compile/build and creation of ZIP files for layer publishing to the Makefile. Because the compile/build can happen for any GOOS, I wanted to put guard rails up to prevent us from accidentally pushing up, say, a macOS darwin build in a published release layer. It only makes sense to publish linux-flavored layers. With all the building and zipping happening in the Makefile, I leveraged target file paths to sorta-kinda namespace compiled executables by their GOOS value and to declare the ZIP file targets as linux-only (in 46d7dbc).

So, GOOS appears in paths in the CI build environment, but any GOOS other than linux is useless/breaking in the context of release artifacts. Therefore, the publsh_* jobs need to publish only linux things and ought not to include "linux" in the paths for release artifacts because that's always been assumed.

[kentquirk]

Thanks for the explanation!