Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dist: don't push images #1365

Merged
merged 1 commit into from
Aug 16, 2021
Merged

dist: don't push images #1365

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 8 additions & 7 deletions dist.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,10 +3,10 @@
# 1. commit to bump the version and update the changelog/readme
# 2. tag that commit
# 3. use dist.sh to produce tar.gz for all platforms
# 4. upload *.tar.gz to bitly s3 bucket
# 5. docker push nsqio/nsq
# 4. aws s3 cp dist s3://bitly-downloads/nsq/ --recursive --include "nsq-1.2.1*" --profile bitly --acl public-read
# 5. docker manifest push nsqio/nsq:latest
# 6. push to nsqio/master
# 7. update the release metadata on github / upload the binaries there too
# 7. update the release metadata on github / upload the binaries
# 8. update nsqio/nsqio.github.io/_posts/2014-03-01-installing.md
# 9. send release announcement emails
# 10. update IRC channel topic
Expand Down Expand Up @@ -45,9 +45,10 @@ done

rnd=$(LC_ALL=C tr -dc 'a-zA-Z0-9' < /dev/urandom | head -c10)
docker buildx create --use --name nsq-$rnd
docker buildx build --tag nsqio/nsq:v$version . --platform linux/amd64,linux/arm64 --push
docker buildx build --tag nsqio/nsq:v$version --platform linux/amd64,linux/arm64 .
if [[ ! $version == *"-"* ]]; then
echo "Tagging nsqio/nsq:v$version as the latest release."
docker buildx build --tag nsqio/nsq:latest . --platform linux/amd64,linux/arm64 --push
echo "Tagging nsqio/nsq:v$version as the latest release"
shas=$(docker manifest inspect nsqio/nsq:$version |\
grep digest | awk '{print $2}' | sed 's/[",]//g' | sed 's/^/nsqio\/nsq@/')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this looks like a job for jq - but if it works for you it's fine with me

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, of course. I wasn't quite sure what our policy for shell compatibility has been, although I suppose you already need quite a few dependencies (golang, docker).

docker manifest create nsqio/nsq:latest $shas
fi
docker buildx rm nsq-$rnd
Copy link
Contributor

@danbf danbf Aug 17, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think without the buildx rm the builders will pile up. not sure how much resources they use.

it might be possible to do an intelligent builder cleanup prior to setting up new builders using docker buildx ls and interpreting the results. for now on our systems if something happens and the builder gets orphan'd, i've just been removing it manually.

in our circle-ci setup on sso ( buzzfeed/sso#319 ) since we use ephemeral build machines we really don't have to care about the orphan builders.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think one could also skip the create and use steps, and just buildx build for local builds, right? It would just cause build cache to accumulate until you docker system prune or similar?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like having a namespace to inspect as an artifact of the build. I don't expect this script to be used in any automated context, so practically speaking it's fine.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for local builds i think just doing an old school docker build is fine. it's really only for the multi-arch push that we need to do the create/use/build-and-push chain.