CI: Publish tags to Dockerhub

[bndw]

Creates a tag in Dockerhub for git tags. Unfortunately, I'm not sure how to test this and it may require an update to .circleci/config.yml to explicitly set the build_image job to run on tags.

Implements #1742

[mattklein123]

@bndw I'm not totally sure how this will work. The tag will definitely not exist when the initial master build is done. Perhaps we can do some type of "deploy" action. I will look at the Circle docs.

[bndw]

@mattklein123 Agreed, the tag event would be a separate webhook from Github.

It looks like the deploy action is the right place to do this with CircleCI; here's an example from the docs:

The following example runs

1. build and test jobs for all branches and only config-test.* tags.
2. deploy only for config-test.* tags

workflows:
  version: 2
  build-n-deploy:
    jobs:
      - build:
          filters:
            tags:
              only: /^config-test.*/
      - test:
          requires:
            - build
          filters:
            tags:
              only: /^config-test.*/
      - deploy:
          requires:
            - test
          filters:
            tags:
              only: /^config-test.*/
            branches:
              ignore: /.*/

In order to get this working I think we'd need the deploy step added to the build_image job. Lmk your thoughts and I can update the PR.

[zuercher]

I think you want -n (test that the string is non-zero length) as opposed to -z (tests for zero length string).

[mattklein123]

@bndw I'm definitely not opposed to this and it would be pretty cool, but I've invested as much time as I can on CI for right now so won't be able to take a look. If you want to sort through docs and try to figure out how to make this work definitely interested.

[bndw]

@mattklein123 This should be working now.

In order to turn on tag support, we added filters for tags to the release job. Tags must be prefixed with v otherwise they're ignored (this is the current tagging scheme).

ci/docker_push.sh ignores any tag events because it's used to build new images and push them. ci/docker_tag.sh ignores everything but tag events and simply pulls the images at the given tag's SHA, tags them with the git tag, and pushes them.

I've setup a test Github Repo, CircleCI project, and Dockerhub repository to test this all out. If you take a look at #32 and #34 you can see both the commit event building and pushing images and the tag event pulling, tagging, and pushing images, respectively.

EDIT: Sorry, it looks like when I tried to rebase my fork it added all the recent changes to this PR. Is there a work around for this so the PR is actually readable?

[mattklein123]

@bndw just squash/rebase on master and force push with DCO. It's a small PR. We can review the final version. Thanks for working on this!

[bndw]

@mattklein123 Rebased.

It seems I broke the DCO check by inadvertently pushing a previous commit under different git user; my commits are signed with my gmail address (desired), but the check is looking for a different address. Is there some way to reset or skip this?

[mattklein123]

I don't actually understand what the bot keys on. I think it might key on the email attached to your account but I'm not sure? @caniszczyk?

[caniszczyk]

https://patch-diff.githubusercontent.com/raw/envoyproxy/envoy/pull/1743.patch

Add "bndw benwoodward@boaweb.com" as a valid email to your GitHub profile and you should be set.

[bndw]

@caniszczyk Just checked and that's an existing, secondary email on my Github profile 😬

[bndw]

It looks like the DCO bot is hung up on the previous commit (pre-squash). The single commit on the PR, 0c21c81, is signed off with the [preferred] gmail address. Is it possible to override the DCO integration?

[mattklein123]

@bndw I don't think it looks at other commits, just the ones now in this PR since you squashed it. It must not be looking at secondary emails? Can you just resign the commit with the boaweb one?

[bndw]

@mattklein123 I'd strongly prefer to have this contribution associated with the gmail account, and that's the account the single commit is signed with:

CI: Publish tags to Dockerhub
Signed-off-by: bndw <benjamindwoodward@gmail.com>

Perhaps opening a new PR would reset the check?

[mattklein123]

I don't think that's the problem but sure let's try that.

[bndw]

Closing this PR to open a new one, with the idea that the DCO bot is hung up on a previously use email address for the sign-off.

[hiimbex]

hiya! Jumping in from over at probot/dco.

The check that we do is merely to make sure that your commit was signed with what git commit -s would expect.

$ git config --global -l
user.name=Bex Warner
user.email=bexmwarner@gmail.com

I could not sign the commit Signed-off-by: Bex Warner <bexmwarner@other.com>

A solution can be to rebase with the correct email in your git config settings and sign off again.