Azure-pipelines-tasks: Increase the size of inline powershell script

[tomap]

Hi,

Could you increase the maxlength of the inline powershell script?
Current value is 500
Better value would be at least 2000

Code:
https://github.com/Microsoft/vsts-tasks/blob/master/Tasks/powerShell/task.json#L83

Thank you

[ericsciple]

@chrisrpatterson @bryanmacfarlane to consider the request

Closing the issue 500 max length is intentional. Beyond that, pointing to a script is the alternative. The problem is that the UI offers a small text box. The 500 length is because inline script is OK for a line or two. Beyond that, the editor experience is lacking. If the max length limitation is removed, then the glaring limitation is the editor experience is bad. The task UI isn't designed to be a code editor.

[tomap]

Well, in our scenario, we wanted to tag the build conditionally.
Not only when the build was a success or not but also when the build was on a specific branch name

So our alternative was to have two job definition, to share the tasks (with build group), but there are still plenty of options that would not be shared, like the repository tab & general tab options.

So to do that our script was simple (in pseudo code):

if(branch="master") {
set git token (set origin to include token http://user@token:vsts.com/)
git tag "Vx.y.z"
git push --tags
}

But all this ends up being a bit long in Powershell and can benefit from having a bit of comments
So what we might end up doing is:

• shrink code: remove all comments & reduce variable names
• do it in two steps (two tasks)
• create a VSTS task that does specificaly that, or
• clone your default PS task and create a new one without 500 char limit :(

Regards

[bryanmacfarlane]

You missed one obvious option which is the mainline supported option. You can check in the powershell script into your repo and use the powershell task to run it.

[tomap]

Hi, I did not missed that, but this felt like something that should be done by the CI/Build part, it is not the concern of the source code.
But I agree, I could commit a .ps1 in my repo

[yuriydk]

@tomap You can trick it using browser dev tools ;) Just increase maxlength with whatever you need, paste script in textarea and save :)

[brphelps]

If the only block is really a browser dev tools trick, I'm a little sad that the power of the inline script is being limited purely for "opinionated" reasons.

[bryanmacfarlane]

There are some real limits that aren't a function of the single task. The current compressed size of the message in work, max size of envvars on diff OSes etc ... Inputs weren't meant to be unbounded code files but there was a short term desire to allow - hey I just want to run a few lines - don't make me check in a file or string multiple tasks

The right solution is to embed our Monaco code editor and on save externalize the persistence and save a reference as the input. Sort of like a gist. We have a file container and secure file storage feature. That's what we need to make this right

[ChristophB125]

I would like to re-open this issue as well. It is important that scripts containing certain information (e.g. knowledge about build machines/infrastructure) is not stored in the source code because this means that a change in infrastructure would break builds of old versions/branches.

[Blackbaud-JonathanBell]

I am trying to easily share a build behavior into a TaskGroup so that it can be shared across all builds. I don't think anyone wants to develop in your textbox, but increasing the text length can allow us to easily produce shared steps across our builds. Yes, you could write a true custom step, but this would be a lower barrier to entry in some cases.

Per @bryanmacfarlane 's comment, maybe the issue is more deep-seated than just a GUI issue. You mentioned the "right" solution - is that viable? Should the issue be reopened?

[icnocop]

For reference: see https://github.com/Microsoft/vsts-tasks/pull/1676 and https://github.com/XpiritBV/Vsts-Build-Task-InlinePowershell/pull/1

[SteveSims2]

I have to agree with the OP, many times I just barely need 550 characters, or 600, and suddenly I have to go the whole route of checking in a file. 2000 would be a more sensible limit. The UI text box experience is fine for a 2000 limitation. Remember we are talking _characters_, not _lines_.

[MohAllan]

so the UI isn't good for big text the solution is limiting the text length =) .. are you convinced?

[sibbl]

Closing the issue 500 max length is intentional. Beyond that, pointing to a script is the alternative.

Now that we have the .vsts-ci.yml approach and even your own official projects are using more than 500 chars in these files (i.e. the vsts-agent), isn't it time to also remove the limit from the GUI as well?

For us, the limitation leads to removing helpful comments and renaming variables to stay in the 500 chars limit. Personally, this leads to even worse code and this just because you think the editor experience might feel bad? A yml file is just as bad as this editor is, when it comes to code highlighting etc...

[Blackbaud-JonathanBell]

@sibbl v2 (preview) of the task has up'd the limit to 5000 anyhow.

[UREURE]

"The task UI isn't designed to be a code editor"...
I don't want a "code editor", I want to paste my code.
Big difference.

[bryanmacfarlane]

@UREURE - as noted above the V2 version of the task upped the limit even in the UI.
@sibbl - yml ends up resolving to the V2 version of the task for inline.

[raffaeu]

Come'n guys what kind of Product Management are you having at MS? It shouldn't be you that decided the length size of an input box but the stakeholder and we are the stakeholders here whom need a text size greater than 500 characters.
I really do not understand when you take these product's design decisions without consulting the final user.

[bryanmacfarlane]

See my previous comment. We removed the 500 limit in the v2 version of the task.

[rdev5]

Any chance we can also get the Arguments field added back in V2?

[rdev5]

Not sure if this is expected or if anything can be done about it, but I'm also seeing parts (i.e. truncated) of variables marked as _secret_ in the console output when errors occur using a V2 PowerShell task.

2018-04-18T15:04:53.8645819Z At C:\agent\_work\_temp\... :10 char:65 SomeFunction("SENSITIV

[bergmeister]

@rdev5 I already opened #5914 for getting arguments back (which are needed to pass in secrets @bryanmacfarlane ) but it got closed(!)

[dombarnes]

I realise this issue is closed but to add my comments, for the deployment step for a ruby based project, the default entry here (as added by the Azure platform) uses 494 of the available characters, leaving no room for adjustment.

BUNDLE_INSTALL_LOCATION="/tmp/bundle"
SITE_CONFIG_DIR="/home/site/config"
RBENV_VERSION = $(ls /usr/local/.rbenv/versions | grep 2.3 | tail -n 1)
eval "$(rbenv init -)"
rbenv global $RBENV_VERSION
bundle clean --force
mkdir -p $BUNDLE_INSTALL_LOCATION
bundle config --global path $BUNDLE_INSTALL_LOCATION
bundle install --no-deployment
tar -zcf /tmp/gems.tgz -C $BUNDLE_INSTALL_LOCATION .
mkdir -p $SITE_CONFIG_DIR
mv -f /tmp/gems.tgz $SITE_CONFIG_DIR
bundle exec rake --trace assets:precompile

[StevenLiekens]

See my previous comment. We removed the 500 limit in the v2 version of the task.

@bryanmacfarlane it was raised to 5000, not removed.
https://github.com/Microsoft/azure-pipelines-tasks/blob/0d9896c58bbb9711a78fc117a5f05c3888aca62f/Tasks/PowerShellV2/task.json#L74

5000 is quite generous but still not enough for what I'm trying to do (=piping large chunks of XML conf to appcmd set config /in).

[bergmeister]

@StevenLiekens This sounds like you should rather store that XML in a file and read from an xml file in the PowerShell task. It will make the code much more readable

[StevenLiekens]

There is no obvious place to store files besides source control. But my XML is configuration for IIS that has very little to do with my code, so I'm trying to keep it out of source control.

The right solution is to embed our Monaco code editor and on save externalize the persistence and save a reference as the input. Sort of like a gist.

This would be lovely.

[bergmeister]

@StevenLiekens You could use Artifacts to store and download the xml file if you do not want it in source control

[StevenLiekens]

@bergmeister where? I don't see anything in Artifacts that lets me upload a script file.

[bergmeister]

@StevenLiekens You could use e.g. universal packages in Azure Artifacts. See here for further examples of using them within Azure pipelines