-
Notifications
You must be signed in to change notification settings - Fork 280
Update Docs to point to a simple and more clear example #632
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
base: master
Are you sure you want to change the base?
Conversation
…ent-version Add TFS 2017 Update 3 agent version.
Deep Dive on Building Custom Build or Deploy Tasks
* Add task.json schema file * Allow any "connectedService:" type of input * Added the "id" field
…cefiles Allow multiple resource files
Properly escape property value to handle non string types
* Error on multiline secret * v2.3.0
Co-authored-by: Tommy Petty <jopetty@microsoft.comwq>
Adding execution options on the pre-job stage.
Shameless self plug -> Microsofts good examples are not clear enough because some parts will be substituted at build time.
added missing s
Build Erros look like something ran into a timeout or if some tests blocked each other while interacting with the file system. DISCLAIMER: I'm not a js expert. I could be totally off but I haven't touched anything but the one README.md so I'm pretty sure your tests are potentially a little flaky. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The useNode BuildTask is not a BuildTask that uses the VstsTaskSdk so it is
not a valid example for a simple build task using it. It is totally
understandable that you don't want to link to external sources. Perhaps you
could just fork my repo?
Danny McCormick <notifications@github.com> schrieb am Do., 7. Mai 2020,
17:30:
… ***@***.**** requested changes on this pull request.
Hey @Angr1st <https://github.com/Angr1st> - per internal policy, we try
to not link to external examples when possible. I'd prefer linking to an
existing example in the tasks repo.
If the MSBuild task is confusing, I'd be open to linking to a simpler task
though - maybe useNode
<https://github.com/microsoft/azure-pipelines-tasks/tree/master/Tasks/UseNodeV1>
?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#632 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEMNB7KQHFRAELBAHWHNXADRQLHYZANCNFSM4MZ67EWA>
.
|
Whoops, lost context on what part of the doc we were in - you're right. Maybe we can use the cmdLine task
I think I'd rather avoid adding another repo to accomplish this since we do have examples that exercise this. It might be helpful to understand what you found confusing about these examples as well. |
Your task all are always cluttered with .ts and .js and package.json files
that are not needed for a windows only build task. Also you use make.js to
copy data during build time of your task. That makes it hard to simply copy
them and be done with it. For me it was just intransparent how the build
task looks once all scrips have run and it is packed as .vsix.
Mine on the other hand does no build time creating/changing the folder at
all. That means you can clone my repo and follow the readme.md to have a
build task ready. Where as with yours I would need to find out how to build
them first. That takes more time.
I could also add a Template/skeleton Folder to this pr as an example how the structure needs to look like.
Danny McCormick <notifications@github.com> schrieb am Do., 7. Mai 2020,
18:03:
… The useNode BuildTask is not a BuildTask that uses the VstsTaskSdk
Whoops, lost context on what part of the doc we were in - you're right.
Maybe we can use the cmdLine task
<https://github.com/microsoft/azure-pipelines-tasks/blob/master/Tasks/CmdLineV2/cmdline.ps1>
Perhaps you could just fork my repo?
I think I'd rather avoid adding another repo to accomplish this since we
do have examples that exercise this. It might be helpful to understand what
you found confusing about these examples as well.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#632 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEMNB7IIREWHMRAO4W76EMTRQLLVVANCNFSM4MZ67EWA>
.
|
That's fair, however, these docs are specifically mean to demonstrate consuming the sdk, not setting up the larger task. That's why we link to the ps1 files, not the task folder. We have other docs that specifically talk about the setup and address that. I think if we're trying to solve that problem, I'd prefer linking to the tutorial over adding another repo to maintain |
You are right about that. I guess I thought you were just presenting examples of how a build task should look like in the end. The problem I have with just linking to the tutorial would be that this also does not showcase how to use the VstsTaskSdk. |
Instead of linking to another repo I just created an example folder structure inside of the Docs folder. The content of the task.json and task.ps1 should be changed to some microsofty default like Fabrikam or something or what do you think? |
I'm ok with this approach, but my main issue here is that we don't ever recommend checking powershell modules or binaries into a repo. The pattern we use (and what we'd recommend) is having a pipeline that builds the task, adding in executables as necessary (and that ultimately can publish the task). So I'd be worried about people just copying the repo. The reasoning behind that is that in any project that has multiple users, checking in binaries introduces a security risk - its extremely challenging to verify the contents of binaries are actually what they should be. In general, I'd be more in favor of simply making the docs about structure clearer over trying to provide an in-repo example (or even pointing to a stripped down example) |
In that case, why isn't there a pre-made script that stores the pipeline
sdk in the right way. I know of no custom task writer who doesn't check in
the binaries apart from Microsoft.
For GitHub Actions we also need to commit the SDK directly to the task repo
for it to load..
…On Mon, May 11, 2020, 19:01 Danny McCormick ***@***.***> wrote:
I'm ok with this approach, but my main issue here is that we don't ever
recommend checking powershell modules or binaries into a repo. The pattern
we use (and what we'd recommend) is having a pipeline that builds the task,
adding in executables as necessary (and that ultimately can publish the
task). So I'd be worried about people just copying the repo.
The reasoning behind that is that in any project that has multiple users,
checking in binaries introduces a security risk - its extremely challenging
to verify the contents of binaries are actually what they should be.
In general, I'd be more in favor of simply making the docs about structure
clearer over trying to provide an in-repo example (or even pointing to a
stripped down example)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#632 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA724SY4I5DD335H6FQNOETRRAVQDANCNFSM4MZ67EWA>
.
|
It doesn't exist because nobody's taken the time to do that :) Definitely not opposed to including something like that in the docs. I don't currently have the bandwidth to do that, but I'm happy to review a pr and/or feel free to open up an issue.
Can't totally speak to that since its a different product (admittedly with some shared stuff), but I believe this is actually not true anymore. They updated their publishing model to use GitHub releases (in large part because of this problem). For example, no node_modules are checked into this repo - https://github.com/actions/stale |
Is there a module manager for powershell? Could you use nuget/paket to ensure reproducable builds (e.g. lock the sdk module version) using a package.lock file? That would be the best way to get the modules at build time I think. |
I personally found the linked build task pretty hard to follow because some of the folder structure was replaced during build time/by some script. I updated my repo to contain a very simple and straightforward example of a build task using the powershell3 task executer. This could be helpful for people with a similar goal that I had. Which was to just package another executable on windows to be run as a build task.