More debug output - Githubissues

cloudfoundry / cf-deployment-concourse-tasks

Apache License 2.0

23 stars 76 forks source link

More debug output #84

Closed axelaris closed 5 years ago

axelaris commented 5 years ago

What is this change about?

This change add more debug output to bbl-up task.

Please provide contextual information.

I love to use this tool for deploying CloudFoundry. However, as an engineer, I definitely need to understand what is going on when I trigger the job. Without a debug output I'm acting like a blind. Moreover, Concourse destroys containers after successful deployment, so I will not be able to troubleshoot anything in future, because bbl-up.txt will gone within container.

Please check all that apply for this PR:

[ ] changes an existing task

Did you update the README as appropriate for this change?

[ ] N/A

How should this change be described in release notes?

n/a

What is the level of urgency for publishing this change?

[ ] Slightly Less than Urgent

Tag your pair, your PM, and/or team!

n/a

cf-gitbot commented 5 years ago

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/161883845

The labels on this github issue will be updated when the story is started.

cfdreddbot commented 5 years ago

:white_check_mark: Hey axelaris! The commit authors and yourself have already signed the CLA.

Changdrew commented 5 years ago

hi @axelaris, we are okay adding --debug as an option to bbl-plan via a task.yml param; however, we cannot use tee because this would have the unintended consequence of leaking credentials on public concourse pipelines.

Is it possible for you to block the pipeline when a build fails to prevent concourse from deleting the instance?

axelaris commented 5 years ago

Hi @Changdrew. I understand your point. Can we make the drain configurable then? Please find the update. By default, the behavior will be same as before. But now it is possible to set a DEBUG_MODE variable to see all the output. So it will be up to operator now. Make sense?

heyjcollins commented 5 years ago

This makes sense, but I'm still curious about an alternative approach which I think would preserve the output you need 'till you decide it can be blown away.

Is it possible to have the pipeline stop running builds if a build fails to prevent concourse from deleting the instance?

axelaris commented 5 years ago

When build fails - it is possible to access container data (to hijack), but for a short period of time. Then container got deleted.
When build succeeded - the container goes away immediately. It's by Concourse design.
When I develop or debug a pipeline - I have to wait until it finishes to see the result, instead of taking immediate action if anything goes wrong. Iteration takes longer, I'm losing a lot of time on that.

Isn't enough reasons to have debug mode implemented?