clever-tools
clever-tools copied to clipboard
Option to skip deployment logs
Would it be possible to provide an option to skip deployment logs?
Having an option such as --skip-logs
to launch deployment commands (clever deploy
, clever restart
) making the commands exit as soon as Clever Cloud start the deployment on its side.
It could be useful when CI/CD systems offer limited build time (BitBucket Pipelines, GitLab CI, etc.) and one want to minimize deployments time in order to minimize CI/CD costs.
As a user of the CLI, this proposal could be a workaround for #318 where the CLI would never exit because of a random issue with the Clever Cloud server-side event dispatching system.
Hello,
With what you describe, we could not know if the build succeeds or fails, am I right?
@hsablonniere, thanks for the feedback!
Yes, you're right, with this option we would not know the result of the build and deploy stages from Clever, only if the code has been pushed (proper fast-forward, no conflicts) and the deployment process has started. However, when using a CI/CD pipeline, you should be able to predict if your app builds and runs before launching the deployment step!
I understand this is a compromise not everyone might be ready to take, but given that you can also receive notifications from Clever (e.g. in a Slack channel) when a deployment succeeds or fails, you can be notified anyway in the end. The only real downside I can see is that the reporting for accurate deployment success/failure is not unified within a single CI/CD server.
Also, as I said in the first message, this is primarily an attempt to find a workaround for issue #318 which does not seem to be easily fixable on your end.
If this proposal does not align with Clever-Cloud philosophy, feel free to close this issue.
@hsablonniere Just so you know, because of issue #318 randomly appearing when deploying application on Clever Cloud, I just burnt 100 minutes of build time on a CI/CD server again (which is a lot)! And this is because I went back to check the CI/CD server after a while, this could have kept on going indefinitely I suppose (except for a server timeout of some sort).
The app is nicely deployed on Clever Cloud but the clever
CLI is still hanging on "Your source code has been pushed to Clever Cloud", not even providing the logs, so no way to even know the status of the deployment in the end...
Again, I can only see 2 solutions here:
- Fixing the things server-side to provide a robust deployment process not hanging indefinitely
- Allowing the client to skip the logs by exiting right after the code is properly pushed to Clever
@rclement Hey, sorry for the delay
- We could try some kind of
--skip-logs
or--ignore-logs
or else, I will discuss this with the team - We could also consider a timeout
- I also need to understand why #318 happens
May I suggest a flag name reflecting the early return behaviour more than the "skip logs" behaviour?
Yes, I'm more inclined towards something like --fire-and-forget
; maybe we can find a name already used in other places which conveys that behavior.
@rclement Hey, sorry for the delay
* We could try some kind of `--skip-logs` or `--ignore-logs` or else, I will discuss this with the team * We could also consider a timeout * I also need to understand why #318 happens
@hsablonniere Thanks for the feedback! Indeed, a timeout could be a nice all-encompassing workaround for now, providing this safety-net to everyone without having to specify a specific flag to skip the logs.
I had the same issue as @rclement in #318, which led to a 6h-long workflow run. The project is public so it did not have any impact on build minutes or limits, but some application logs were leaked in the process. Hopefully the deployment logs can help you identify the source of the issue.
In the mean time, I'm implementing an optional timeout in the GitHub action to handle this case.
As accidentally commented on #318 already:
My workaround for #318 is to not use clever-tools for deployment in CI. Instead we use git push
. AFAIU, this has exactly the behavior you want, @rclement:
- Only pushes changes
- Gives feedback if pushing works (fast-forwardable, etc)
- Does not wait for actual deployment and not show any logs.
However, when using a CI/CD pipeline, you should be able to predict if your app builds and runs before launching the deployment step!
@rclement You "should be able to predict if your app builds" (quotes :wink:) but you won't be able to predict if it runs. For example, some of my apps, don't start if the env variables are incorrect.
@rclement @divarvel @franky47 @justfortherec OK, let's try to close this.
I have a fix for #318 (almost ready). We changed the way the CLI detects "deployment is finished" so the infinite build should never happen again.
About the timeout
I though about the "timeout" feature we considered and I think this should be the CI server concern. I may lack some knownledge on "do they support this?". Now that we have a fix for #318, I'm not so sure a timeout is still relevant so let's discuss if we really want this in the CLI.
EDIT: Because there are always unknown unknowns, we're going to add a --timeout
which will default to 45min.
EDIT2: Maybe no default... Still in discussion...
EDIT3: We need more feebacks on #318 fix to know if this is necessary.
About the no logs
As we discussed it, having a "successful" clever deploy --just-push-and-dont-log
would only mean the inner git push was OK but the deploy (build+deploy+run) on Clever may have failed. This could be a bit weird to understand without context. Now that we have a fix for #318, I'm not so sure a "no logs" feature is still relevant so let's discuss if we really want this in the CLI.
@franky47 The clever deploy
command has a --quiet/-q
options. With this, it will push, wait for "deployment end" without displaying the logs.
The fact that the logs are displayed is not much of an issue in my case, however in some cases the hanging deployment process made it that runtime logs were displayed in the CI/CD output. Fortunately, there was no sensitive information there, but this could be a security issue.
I'm all for --fire-and-forget
or --stop-early
or something like that. I have some use cases where I would just need to run a deploy/restart and do not want clever-tools too keep around waiting for the deployment to end.
AMQP calls that nowait, which would be a good fit I think