-
-
Notifications
You must be signed in to change notification settings - Fork 24
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
IB Tasks Appear Broken? #16
Comments
I wrote the dynamic IB generator for PSAke tasks so probably missed an edge
case with the latest update, I'll take a look!
…On Tue, Dec 18, 2018, 3:39 AM Paul Broadwith ***@***.***> wrote:
Latest 0.3.0 Beta version. The Build task in PowerShell.IB.Tasks is empty task
Build. As a consequence nothing happens when running invoke-build -File
.\.build.ps1 -task build
Expected Behavior
In previous version 0.2.0 the Build task was task Build StageFiles,
BuildHelp which built the module.
Current Behavior
You get this:
[image: image]
<https://user-images.githubusercontent.com/12760779/50151622-53d23080-02b9-11e9-806a-201a15dd83a1.png>
Possible Solution
Change the PowerShell.IB.Tasks file to either use the same build tasks as
previous version or use the tasks specified in
$PSBPreference.Build.Dependencies which by default is 'StageFiles',
'BuildHelp' (this doesn't appear to be used anywhere but I could be missing
it).
- Module version used: 0.3.0-beta
- Operating System and PowerShell version: Windows 10, Windows
PowerShell 5.1.17134.407
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#16>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AOjVUk-LLv2xd6zSJURHkeVZNJ8HVaTqks5u6NQIgaJpZM4ZYIVs>
.
|
Thanks for finding this @pauby and thanks for taking a look @JustinGrote! I created issue #17 to highlight we need to improve the Pester tests for this project. Right now, there is only basic tests that do not actually verify functionality. |
I raised #20 earlier but I have come across another issue that is related to the conversion between psake and InvokeBuild. The task This seems to be a wider issue around conversion. I'm not sure if it's worhwhile continuing to convert the tasks or whether it would be better simply to keep both sets of tasks updated manually, given that the amount they will change will likely be minimised due to most of the grunt work being done inside functions? |
@JustinGrote Can speak to how much work would be involved in shoring up the conversion script. |
(1) The original script Convert-psake.ps1 is not intended for unsupervised (2) True parsing and conversion of psake scripts is probably doable (not 100%) (3) What can be done for the current issue In the code supposed to be converted to IB you may omit parameter names in Assert ($PSBPreference.Publish.PSRepositoryApiKey -or $PSBPreference.Publish.PSRepositoryCredential) "API key or credential not defined to authenticate with [$($PSBPreference.Publish.PSRepository)] with."
Alternatively, in the custom script derived from the original Convert-psake.ps1 function Assert-PSake([Parameter()]$conditionToCheck, $failureMessage) { Assert-Build $conditionToCheck $failureMessage }
Set-Alias assert Assert-PSake As a result, the below script ("generated") is a valid IB script using psake function Assert-PSake([Parameter()]$conditionToCheck, $failureMessage) { Assert-Build $conditionToCheck $failureMessage }
Set-Alias assert Assert-PSake
task t1 {
Assert -conditionToCheck $false -failureMessage "Oops..."
} |
Sorry for the delay. So the way the new script works is proxying the psake statement such as Task with "Convert-Task", which then parses the psake statement and spits out the IB equivalent. The Invoke-Command however is processing variables such as $PSBPreference prior to passing it to Convert-Task, thus resulting in a null because it hasn't been set in the build environment, and hence why build comes up with no dependencies. $PSBPreference wasn't a thing when I wrote the initial script, and it didn't fail the pester test because a Build task actually did get created, so a more specific test to ensure all related parameters are also generated would catch this in the future. I'll have to figure out a way to take variables specified in PSake command parameters and "escape" them so that the final generated code preserves them rather than evaluate them. It would likely go around line 33 and use AST to find variables and escape them out as single quoted strings or something, then post-process the result of Convert-X and re-insert the variables into the statement before output. |
Would you consider manually-written InvokeBuild tasks, instead of generated ones. One thing I'm missing in the current IB tasks is that they don't 'inherit' their properties/parameters as I do in my gaelcolas/SampleModule. i.e. Param (
[string]
$VariableNamePrefix = $(try {property VariableNamePrefix} catch {''}),
[switch]
$ForceEnvironmentVariables = $(try {property ForceEnvironmentVariables} catch {$false})
)
task Set_Build_Environment_Variables {
$BH_Params = @{
variableNamePrefix = $VariableNamePrefix
ErrorVariable = 'err'
ErrorAction = 'SilentlyContinue'
Force = $ForceEnvironmentVariables
Verbose = $verbose
}
Set-BuildEnvironment @BH_Params
foreach ($e in $err) {
Write-Build Red $e
}
} I can override the parameters of that task in my IB entry point... (i.e. where I define Task .) Param (
[string]
$VariableNamePrefix = $(try {property VariableNamePrefix} catch {$PSBPreference.BuildHelpers.Prefix}),
[switch]
$ForceEnvironmentVariables = $(try {property ForceEnvironmentVariables} catch {$PSBPreference.BuildHelpers.ForceEnvironmentVariables })
)
# [...] So in your default Param(
[string]$VariableNamePrefix = 'BH'
)
Task . Set_Build_Environment_Variables,
Do_something_else,
finish_the_thing And invoking an override at build time: (BuildHelpers prefix is a stupid example, but simple enough to understand the concepts) |
I forgot to mention as it was implied, that EVERY tasks using $VariableNamePrefix = $(try {property VariableNamePrefix} catch {$PSBPreference.BuildHelpers.Prefix}), |
We may talk and think about this at IB issues, please post a question and thoughts. But it looks like you "work around" this using some overcomplicated constructs.
you can just use
It's the same but simpler and more effective/clean. |
The question (mainly for @devblackops) whether he'd accept written IB tasks instead of generated ones still stands. The complex construct is old code I haven't really reviewed yet. |
The original implementation manually created the IB tasks until #11. If the automatic converter is not sufficient or can not be relied upon 100% and requires manual touch, then perhaps it is better to manually convert them. I'm OK with this. I'm also open to improving the Pester tests that validate the conversion. Perhaps we can make that more robust to improve confidence. |
I've just come across this issue again so I thought I'd throw my 2p / 5 cents into the mix and feel that we should just go with the manually created tasks. As they are unlikely to change too much I don't think it would be too much maintanence overhead? |
If we go manual, probably the best way is to apply Pester tests to both
task types to ensure the same output result.
Short of someone helping, this is totally on me to fix and I totally
haven't been able to make it a priority on my current duties.
… |
I am happy to create the IB tasks if this is the way we want to go? |
@pauby @JustinGrote I'd say go manual for now. Bonus if we had a simple module to run through the tests with to validate as well. |
I'd say manual as well since I haven't had time to dedicate to fixing the
wrapper. If I do then it will detect if a task has been manually written
and "skip" it, only generating tasks that don't have a IB equivalent.
…On Tue, Aug 27, 2019, 9:00 PM Brandon Olin ***@***.***> wrote:
@pauby <https://github.com/pauby> @JustinGrote
<https://github.com/JustinGrote> I'd say go manual for now. Bonus if we
had a simple module to run through the tests with to validate as well.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#16?email_source=notifications&email_token=ADUNKUXEXLAHI2GM5WNEJA3QGXZ7RA5CNFSM4GLAQVWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5J2D5I#issuecomment-525574645>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADUNKUXVM365XSPY74OBAOTQGXZ7RANCNFSM4GLAQVWA>
.
|
I've submitted #35 for this to use standalone tasks for InvokeBuild for the time being. Note sure if this is a long term fix or a temporay fix until the wrapper is fixed. Either way it gives us something to work with just now. I am expecting I've missed something to disable the wrapper for the time being but I've changed what I could find. While the PR fixes this issue technically, going forward maybe it should be left open to discuss? |
See the PR. After fixing that or adding this to your invoke-build file header: if (-not (Get-Module PowershellBuild)) {Import-Module PowershellBuild}
. PowerShellBuild.IB.Tasks
$PSBPreference.Build.CompileModule = $true
task Build $psbpreference.build.dependencies
task . Build All the tasks as currently defined will work (at least for me) |
@JustinGrote Does that change fix https://github.com/psake/PowerShellBuild/blob/master/PowerShellBuild/psakeFile.ps1#L154 when converting? |
@devblackops doesn't generate an artifact as part of the appveryor build so
I can't check for sure, let me try compiling it locally. Is the problem
that the assert doesn't come over?
…On Wed, Oct 2, 2019 at 1:16 AM Paul Broadwith ***@***.***> wrote:
@JustinGrote <https://github.com/JustinGrote> Does that change fix
https://github.com/psake/PowerShellBuild/blob/master/PowerShellBuild/psakeFile.ps1#L154
when converting?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#16?email_source=notifications&email_token=ADUNKUUNVWMLGRDSSZK2O53QMRKEFA5CNFSM4GLAQVWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAD6EPQ#issuecomment-537387582>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADUNKUSPAYBSBCS74AHXHR3QMRKEFANCNFSM4GLAQVWA>
.
|
@JustinGrote No, it's that the Assert in InvokeBuild is different. See the PR I put in for the correct syntax. |
Ah I see. Since it's not part of the original psake task, it wouldn't
incorporate your change, because the file gets dynamically generated at
build time. It would need to be part of the psake task, which it "kind of"
is already and I confirmed this carries through to the IB task.
if ($settings.PSGalleryApiKey) {
Publish-Module -Path $settings.ModuleOutDir -NuGetApiKey
$settings.PSGalleryApiKey -Repository PSGallery
} else {
throw 'Did not find PSGallery API key!'
}
…On Wed, Oct 2, 2019 at 7:02 AM Paul Broadwith ***@***.***> wrote:
@JustinGrote <https://github.com/JustinGrote> No, it's that the Assert in
InvokeBuild is different. See the PR I put in
<https://github.com/psake/PowerShellBuild/pull/35/files#diff-a66a6537ef38b034878669b1ae569beeR156>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#16?email_source=notifications&email_token=ADUNKUT5XUXIHERJ2YGGMRLQMSSWDA5CNFSM4GLAQVWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAE3HJQ#issuecomment-537506726>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADUNKUWZXL2R7DXDWPOGHE3QMSSWDANCNFSM4GLAQVWA>
.
|
Also if you're interested in Native IB tasks, check out my PowerCD module,
though I'm working to abstract them into functions so they can be included
here because I believe in @devblackops goal of having a consistent standard
library of tasks to work with, and then opinionated templates from there.
https://github.com/justingrote/powercd
…On Wed, Oct 2, 2019 at 7:15 AM Justin Grote ***@***.***> wrote:
Ah I see. Since it's not part of the original psake task, it wouldn't
incorporate your change, because the file gets dynamically generated at
build time. It would need to be part of the psake task, which it "kind of"
is already and I confirmed this carries through to the IB task.
if ($settings.PSGalleryApiKey) {
Publish-Module -Path $settings.ModuleOutDir -NuGetApiKey
$settings.PSGalleryApiKey -Repository PSGallery
} else {
throw 'Did not find PSGallery API key!'
}
On Wed, Oct 2, 2019 at 7:02 AM Paul Broadwith ***@***.***>
wrote:
> @JustinGrote <https://github.com/JustinGrote> No, it's that the Assert
> in InvokeBuild is different. See the PR I put in
> <https://github.com/psake/PowerShellBuild/pull/35/files#diff-a66a6537ef38b034878669b1ae569beeR156>
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#16?email_source=notifications&email_token=ADUNKUT5XUXIHERJ2YGGMRLQMSSWDA5CNFSM4GLAQVWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAE3HJQ#issuecomment-537506726>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ADUNKUWZXL2R7DXDWPOGHE3QMSSWDANCNFSM4GLAQVWA>
> .
>
|
@JustinGrote @devblackops Can I clarify the current state on this? My understanding was that separate standalone psake / IB tasks were going to be used (and I submitted #35 for that) but I'm getting the impression that has changed? 😕 (Note I'm not asking 'why has my PR not been merged'!) |
It can always be both, we can modify the script to do automatic ones as a
separate file and then have the manual ones as another one, that way they
can proceed in parallel.
…On Sun, Oct 6, 2019, 7:58 AM Paul Broadwith ***@***.***> wrote:
@JustinGrote <https://github.com/JustinGrote> @devblackops
<https://github.com/devblackops> Can I clarify the current state on this?
My understanding *was* that separate standalone psake / IB tasks were
going to be used (and I submitted #35
<#35> for that) but I'm
getting the impression that has changed? 😕
(Note I'm not asking 'why has my PR not been merged'!)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#16?email_source=notifications&email_token=ADUNKUTMASJ3J5MOGSZXNKLQNH4IRA5CNFSM4GLAQVWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAOMA5I#issuecomment-538755189>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADUNKURVS3VLKBL36XMNPNDQNH4IRANCNFSM4GLAQVWA>
.
|
@pauby Plan is still to proceed with the manual ones still. I've just pushed a test module to
Haha. I've been a lazy bum and will merge this now. |
Preserve Dependency Variables (Fixes #16)
Is there more to do on this? |
Latest 0.3.0 Beta version. The
Build
task in PowerShell.IB.Tasks is emptytask Build
. As a consequence nothing happens when runninginvoke-build -File .\.build.ps1 -task build
Expected Behavior
In previous version 0.2.0 the Build task was
task Build StageFiles, BuildHelp
which built the module. I expect the same from the new version.Current Behavior
You get this:
Possible Solution
Change the PowerShell.IB.Tasks file to either use the same build tasks as previous version or use the tasks specified in
$PSBPreference.Build.Dependencies
which by default is 'StageFiles', 'BuildHelp' (this doesn't appear to be used anywhere but I could be missing it).The text was updated successfully, but these errors were encountered: