Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to override how psake's internal logging is handled #301

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

UberDoodles
Copy link
Contributor

Description

There is a new WriteOutput function, which is used throughout the psake code whenever messages need to be logged. The function simply passes the message and message type to an "outputHandler" script block, which can be overridden in psake-config. So you can override exactly how output is handled by overriding that outputHandler script block.

The default outputHandler script block further routes the output according to it's output type (warning, verbose, error, etc) to corresponding script blocks which can also be overridden by psake-config. So you also have the option of overriding how a single type of output is handled.

The default outputHandlers for each message type outputs the message exactly as it would have been prior to this new feature, so it is a non-breaking change.

Related Issue

#65

Motivation and Context

As described in the issue, if your psake build file uses a different method of logging to psake's internal logging method, it can be difficult to try and handle the messages from each consistently. This change allows you to make psake's internal logging more consistent with your own. You can even have psake's messages routed to your own custom functions.

How Has This Been Tested?

New spec files added to verify the basic functionality, that all of psake's internal logging uses the new WriteOutput function, and that it handles situations where the config items have been overridden with invalid values.

Screenshots (if appropriate):

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

When I updated the function to copy the outputHandlers from the previous config, I foolishly made it copy the reference to the previous outputHandlers hashtable; not the value. So when you run a nested build, it's outputHandlers config persists after the nested build ends, and affects the outer build.

I've now corrected it to Clone() the hashtable.
@stale
Copy link

stale bot commented Aug 21, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Aug 21, 2020
@stale stale bot removed the stale label Sep 4, 2020
@stale
Copy link

stale bot commented Nov 5, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Nov 5, 2020
@stale stale bot closed this Nov 19, 2020
@devblackops devblackops reopened this Nov 19, 2020
@stale stale bot removed the stale label Nov 19, 2020
@devblackops devblackops self-assigned this Nov 19, 2020
@jozefchmelar
Copy link

This is very useful! I use it in my own fork of psake. I was about to make a PR but it turns out you made it first! Good work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants