Global enhancements

[crazy-max]

@tianon First of all thank you for this great project! I planned to move to gosu since su-exec has some bugs like ncopa/su-exec#21 and does not seem to be taken into account.

So as a modest gift for your project, here is a PR that offers some enhancements:

• Use buildx bake and goreleaser
• More platforms support
  • arm/v7
  • mips/hardfloat
  • mips/softfloat
  • mipsle/hardfloat
  • mipsle/softfloat
  • mips64/hardfloat
  • mips64/softfloat
  • mips64le/hardfloat
  • mips64le/softfloat
• Add vendor and lint validation bake targets
• Add dependabot
• Fix go.sum
• Mutualize tests and handle them through bake and GHA
• Publish Docker image (from scratch with only gosu binary)
• Switch to GitHub Actions
  • On git push tag event semver like v1.13.0:
    • Artifacts will be available in the pipeline through actions/upload-artifact
    • Will create the GitHub Release and push artifacts
    • Will create and push Docker tags tianon/gosu:1.13.0 / tianon/gosu:latest
  • On git push (master branch)
    • Artifacts will be available in the pipeline through actions/upload-artifact
    • Will push Docker tag tianon/gosu:edge
  • On git pull_request event
    • Artifacts will be available in the pipeline through actions/upload-artifact

Everything is already in place and tested on https://github.com/crazy-max/gosu as well as the GitHub Actions pipeline.

Live example of usage through Dockerfile available here.

[crazy-max]

Arbitrary Docker slug registries. Change if needed.

[crazy-max]

Arbitrary Docker slug. Change if needed.

[crazy-max]

Arbitrary Docker slug registries. Change if needed.

[crazy-max]

⚠️ Before merging:

• Update Docker slug registries if needed
• The following GitHub Actions secrets need to be created for this repo: DOCKER_USERNAME, DOCKER_PASSWORD, GHCR_USERNAME, GHCR_TOKEN.

You may also need to create a dummy workflow on master to be able to enable GitHub Actions on this repo and also trigger a build for this pull request. Something like this would be enough:

# .github/workflows/dummy.yml
name: dummy

on:
  workflow_dispatch:
  push:
  pull_request:

jobs:
  dummy:
    runs-on: ubuntu-latest
    steps:
      -
        name: Checkout
        uses: actions/checkout@v2

[tianon]

Wow, this is ... big. You've obviously put a lot of work into it, and I don't want to discourage that, but it's definitely hard to review something that's so large and so fundamentally changes all the workflows of how I maintain this repository. 😬

Maybe you could choose your top three improvements so we can discuss something a little more focused?
(To be clear, I'm looking to discuss why you want these changes, not asking you to make more changes/PRs yet 😅)

[crazy-max]

Hey @tianon, yeah I know that's pretty big sorry for that but I wanted a functional multi-platform Docker image to ease the integration in a Dockerfile like this:

ARG GOSU_VERSION=1.13.0

FROM crazymax/gosu:${GOSU_VERSION} AS gosu
FROM alpine
COPY --from=gosu / /
RUN gosu --version
RUN gosu nobody true

So that's my major request about this repo, a multi-platform scratch image with gosu bin inside :)

For the rest I use bake to ease the workflow a lot:

git clone https://github.com/crazy-max/gosu.git gosu
cd gosu

# validate (lint, vendors)
docker buildx bake validate

# test (test-alpine and test-debian bake targets)
docker buildx bake test

# build docker image and output to docker with gosu:local tag (default)
docker buildx bake

# build multi-platform image
docker buildx bake image-all

# create artifacts in ./dist
docker buildx bake artifact-all

Everything dockerized so no shell script to call locally.

Finally the GitHub Actions to avoid tempered artifacts and more transparency around releases as it seems to be built locally on your computer right? Nothing wrong with that, I have total confidence in you, especially since the artifact is signed but I think for this kind of project it's quite legit :)

And one thing leading to another here is this PR ahaha

Let me know what you think, and don't worry if you prefer to close this PR, That's a gift :)

[tianon]

Yeah, I'm sorry but there's definitely no way I can merge a complete rewrite of my entire repository/workflow. I'm happy to discuss specific changes/improvements such as publishing images that contain the gosu binary ready-for-use.

I'd definitely love to get to reproducible binaries such that it really doesn't matter where they build (although we likely won't be getting distribution builds such as https://packages.debian.org/sid/gosu and https://pkgs.alpinelinux.org/package/edge/testing/x86_64/gosu using the same build flags we do, and certainly not statically, but at least that would make the builds I publish easily verifiable).

Of course, you're welcome to maintain your code as a fork (this is open source, after all 😄) but I would ask that if you do so that you don't call it "gosu" to avoid confusion. 👍

[crazy-max]

Of course, you're welcome to maintain your code as a fork (this is open source, after all 😄) but I would ask that if you do so that you don't call it "gosu" to avoid confusion. 👍

Done :)

[tianon]

To circle back on this, I've pushed https://hub.docker.com/r/tianon/gosu (549de11), which is usable most trivially across all supported architectures something like:

COPY --from=tianon/gosu /gosu /usr/local/bin/

If you want something that's FROM scratch, that's trivial to create via something like:

FROM scratch
COPY --from=tianon/gosu /gosu /

(I would suggest specifying --platform on your build if there's a specific target architecture you're wanting.)