Add logs to deploy command? #473
Labels
No Label
bug
build
ci/cd
contributing
critical
design
documentation
duplicate
enhancement
help wanted
invalid
meta
question
release
release-candidate
security
test
wontfix
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: toolshed/abra#473
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
When an app fails to converge, you're suggested to run
abra app logs
but this only shows the latest lines, which don't necessarily indicate what happened. Is it possible to show the logs during deploy, on the same output? That way I could see what failed during deploy, instead of guessing when are logs available (I can't, always seem to get less output that I need)@fauno that's a very interesting idea 🤔 If others support this idea, we could think about wiring up a prototype to test it out. I think it would in theory give more clarity to what is going on?
And to check we're on the same page, if the deployment passes, the logs stop tailing? And if it fails, it stops tailing. And you get the same message at the end as per usual?
The current work-around is something like this after the deployment:
But I now notice that this actually hangs with 0 output 😭 That's a 🐛update: typo,
👉10 minutes
10 minutes ago
works 🎉Yeah that should do it! I didn't notice the
--since
flag :/@fauno cool! actually, it does work 😅 I just had a typo in the obscure
date
syntax in my comment above. hopefully that helps for now. but yeh, if you could try gather more input on this feature request, it'd be great!#478 feels related.
@fauno any ideas how a layout might look in combination with #478 (comment)? (🤯) Ideally we'd have both the status updates from Docker itself and the logs tailing alongside somewhere. We don't have so much screen real estate but I'd love to combine. This could make things finally visible and informative...see #473 (comment)@fauno a wild idea appears: we can record the start time of the deployment. then, run the deployment. when #478 is implemented we will know for sure if a deployment failed or not. if a deployment fails, we can dump all the logs from all containers since the deployment start time directly without prompt (because you would do this anyway). if the deployment succeeds, we show no logs. how does this sound for a design?
sounds great!
Alternatively, taking some parts of what
@forest
was talking about here we could also log all output of a failed deployment to file in~/.abra/logs/<server>/<app>_<timestamp>
(or something like this) for further inspection (and also ease ofscp ...
to fellow workers for inspection!I think that also might be an easier and a more sustainable option, giving people the full overview but then instead of a potentially confusing dump of some limited amount (or worse, too much) of logs in the terminal all at once!