(before|after)_deploy should be run only once before and after all deployment providers

[BanzaiMan]

Right now, these sections fire for each deployment provider. If a command is not idempotent (say, git fetch --unshallow), having multiple providers lead to reproducible error.

[sarahhodne]

I noticed this while refactoring the code, and remember saying something about it, but for some reason I ended up making it run once per provider still. I think it might be because this is documented behaviour?

[BanzaiMan]

There is one mention of the current behavior at the end of http://blog.travis-ci.com/2013-10-02-continuous-deployment-pypi-npm-and-more/.

[jayzes]

I was the initial reporter on this one - I actually think the behavior as it is makes sense. Really the only part that’s confusing is that there’s no logging to indicate that the before_deploy section (in my case) was failing, so it's difficult to debug what's going on. Perhaps just changing the logging setup for this step would be enough?

[vilmosioo]

I don't really understand why you would want before_deploy to run twice for two providers, without a way to identify which provider you are preparing to deploy for.
Is this the intended behaviour? Or am I missing something?

[dieend]

I just realized that it's run for every provider. I zipped the build in before_deploy, and deploy to multiple provider. Well, the zip size multiplied. Is this the default behavior?

This should be only run once, or give a way to run before_deploy for specific provider.

[jnorgan]

Same issue here. Anyone have a clean work around for this?

[yoavram]

You can create an empty file (touch tmp) and check if it exists...

[rolebi]

Same problem here.

The way the logs are displayed in the UI is really misleading too.

Currently they are not displayed in a chronological manner but rather aggregated for all providers so that when the second deployment trigger, the previously displayed before_deploy section is updated resulting in a 'jumpy' console when using 'Scroll to End of Log' feature.

Having before/after/deploy sections per provider would be really appreciated, currently you have to look at raw logs to understand what's going on.

---

I don't really understand why you would want before_deploy to run twice for two providers, without a way to identify which provider you are preparing to deploy for.

Agreed, if not possible to run only once, having an env var that tracks which deployment provider is running would be great.

You can create an empty file (touch tmp) and check if it exists...

Or create an env var that keeps track of that. e.g.

before_deploy:
  - >
    if ! [ "$BEFORE_DEPLOY_RUN" ]; then
      export BEFORE_DEPLOY_RUN=1;
      my_cmd 1;
      my_cmd 2;
      ...
    fi

[vvondra]

Just got hit by this, it took me a while to realize what's going on from the build log

[BanzaiMan]

I wonder how changing this behavior would affect existing builds.

[vvondra]

I say half of the users don't notice this behaviour and the before_deploy step is idempotent - right now they just experience longer build times.
The other half reaches this ticket and behaviour and apply the check from #2570 (comment)

I'd keep the possibility to run something before each deploy and not change. Make the documentation better and visibly mention this. Same for after_deploy

[camelspeed]

I just ran into this issue and I won't rehash what's been said by many but I will vote up what @vvondra and @rolebi said about clear visible documentation about the behavior and intent. This subtle behavior will lead to insidious bugs for sure.

Regarding #2570 by @BanzaiMan, perhaps the default behavior stays as-is and a property is added to change that behavior to only run "once for all providers" (e.g. run_per_provider: false (default: true)). Would something like that work so that both sides are supported and we prevent custom workarounds in our code that ought to be part of the CI behavior configuration?

[da1nerd]

I just ran across this myself. In my case I'm using travis to automatically increment build numbers in the repository. The builds were increment by two because I had two deploy providers.

+1 for at least providing clearer logging. However, I agree with @vilmosioo that it makes more sense for before_deploy to be ran once rather than for each provider.

[brianparry]

+1 for either running before_deploy once for all providers or a per-provider before_deploy option.

[aberonni]

+1 any update on this?

[ernie58]

+1 any update on this?

[aeneasr]

This is still an issue

[stale]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please do feel free to either reopen this issue or open a new one. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues

[tdmalone]

^ Ping to keep this open, as it's still an issue.

[stale]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue in 24 hours. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please do feel free to either reopen this issue or open a new one. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues

[tdmalone]

unstale

[BanzaiMan]

It might be too difficult and disruptive to change before_deploy and after_deploy. Perhaps introducing a new phase might be a better idea.

[harvey-woo]

+1 any update on this?

[BanzaiMan]

@harvey-woo Sorry, no updates.

[marcandrews]

How about adding before_all_deploy and after_all_deploy phases?

[harvey-woo]

@BanzaiMan Ok, i'll follow @rolebi 's solution

[diversit]

Also running into this issue. Also do not understand why 'before' and 'after' would run for each provider. The goal is to create a single binary and deploy it to multiple targets, in my case Github and Bintray. By running for each provider there is a chance the created binaries are not equal and that is not what you want I think.

Reading through this issue, it is apparently not possible or wanted to change the current behaviour because it exists for so long already. Instead of creating new phases I propose to add a boolean property to allow running the before/after for all or per provider. E.g. run_deploy_scripts_per_provider: false.

Default value should be false so it's still backwards compatible. This default could be changed in more in the future release, since that seems to be the expected behaviour, and still allows the old behaviour by setting property to false.

[palxex]

At least we need a method to detect which provider the {before,after}_deploy script for.
For example we have 3 provider, 2 script and 1 bintray, I only want perform after_deploy after bintray, but now I've no method detecting, the only way is performing it 3 times.
Suggest: add "name" for each provider, and DEPLOY_NAME environment for {before,after}_deploy; for my scenario, SCRIPT_1, SCRIPT_2 and BINTRAY. then I could detect via the variable and only perform needed action exactly when needed; those who only want once could also archiving it in this design.

[MarkCallow]

In my case I am running a script to notarize my macOS .pkg. It takes a long time and running it twice is completely unnecessary and very very time consuming. Are the deployments guaranteed to always be executed in the same order? I'd prefer to notarize just before the deployment to GitHub releases rather than the other deployment which is of documentation to gh_pages.

With all the traffic here, why is this still not fixed? An excellent and compatible solution has been suggested by @diversit . What is the issue preventing it being fixed?