Github tagged releases don't trigger S3 upload – is my config wrong?

Deployment
1

I’ve been wrestling with this issue for a few days, having slightly tweaked some deploy config based on another project.

My desired workflow is:

  • A commit to master should upload the artefact to S3 then deploy to my TEST AWS CodeDeploy environment
  • When I create a release on Github for my project (eg. v2.0.0), Travis should upload the artefact to S3 then deploy to my LIVE CodeDeploy environment

Here’s a recent build, trigger by a new release on Github. You can see that it skips the S3 stage. Why is v2.0.3 being treated as a branch when this is just a release?

Skipping a deployment with the s3 provider because this branch is not permitted: v2.0.3
Skipping a deployment with the codedeploy provider because this branch is not permitted: v2.0.3
Skipping a deployment with the codedeploy provider because this is not a tagged commit

Here’s my Travis config file.

2

OK, so, the build is working as specified, but perhaps there are too many messages to the point where it’s confusing to you.

You have 3 deployments defined in the file.

The first one,


being the default (with no on key), does not trigger because the build is not on the master branch. This yields the first message: 
Skipping a deployment with the s3 provider because this branch is not permitted: v2.0.3

The second one,


with on.tags: false is rejected because this is a tagged build. This yields the remaining two messages: 
Skipping a deployment with the codedeploy provider because this branch is not permitted: v2.0.3
Skipping a deployment with the codedeploy provider because this is not a tagged commit

The first of these two seems to be superfluous, since on.tags condition should skip checking the branch condition (as described in the document https://docs.travis-ci.com/user/deployment/#conditional-releases-with-on). The second message tells you that it is skipped because of the tags condition.

The last deployment


fires and you see the result https://travis-ci.com/github/biglotteryfund/craft-dev/builds/168594518#L461-L489

Now, to achieve your workflow, it seems that the cleanest logic would be to have two distinct sets of deployment providers that work separately; one set for the master branch, and another set for the tagged builds. I think you have most of them already; all that’s left to do is to add an S3 deployment that works on tags (with on.tags: true) and stick it between the 2 codedeploy deployments.

You can use YAML anchors to reduce duplication.

1 Like
3

Thank you – I actually just made some variation of this in the last 30 minutes or so based on a comment of yours over on Github! I’m sure I can clean this up a little though, appreciate the advice.

One thing that confused me here was the two messages referring to one of the CodeDeploy deployments. It would be cool if you could give each deployment a name, which Travis could then use, eg:

Skipping a deployment to "PRE-PROD" with the codedeploy provider because this branch is not permitted: v2.0.3
Skipping a deployment to "PRE-PROD" with the codedeploy provider because this is not a tagged commit

This would’ve made it clearer to me that the other CodeDeploy step was running, although obviously I saw the deploy attempt to go out in AWS shortly after.

Thanks for the help!