Deployment failure for rejected push (not fast forward) should fail the workflow

[rik]

We're seeing the following error in our workflows but they don't fail the workflow.

Error:  Push rejected because it was not a simple fast-forward. Use "force: true" to override.

I'm not sure if #184 was supposed to catch those. We're using v1.1.

[franky47]

It looks like deployment failure detection is not as reliable as it was, I also had aborted deployments marked as successful. I'll look into it.

Your issue mentions failure because of a non-linear commit history, I was thinking of adding a force option to pass to Clever Cloud, would that be useful? I'm thinking about staging environments where branching can often be non-linear (eg: switching from a feature preview to another).

[rik]

I was thinking of adding a force option to pass to Clever Cloud, would that be useful?

Yes it would. We started implementing that option but had issues verifying that it works in an actual workflow.

[franky47]

I see, I'll gladly review that PR once it's ready. What were your issues?

[rik]

We were struggling to run our code because of the Docker image in

actions-clever-cloud/action.yml

Line 39 in b4c20df

image: docker://47ng/actions-clever-cloud:v1.1.0

. In the end, we just changed that line to image: 'Dockerfile'.

PR submitted: #188 but I think this issue should stay open as it is two separate problems.

[mockersf]

I tried using this option but couldn't just use the latest master version of this repo because of the docker image.

Could you tag an updated version of the docker image and push a new version of the action with it?

[franky47]

I've published v1.2.0 which includes the force: true option.

Thanks for your contribution @rik!

[rik]

Thanks!

I think the particular issue should stay open though because it is . My patch gives an option to force deploys regardless of the fast-forwardable state but the original problem is: if a deploy fails because it can't fast-forward, the action will not fail the workflow.

[franky47]

Let's track deployment failures not leading to workflow failures in the original #184 issue.