RamblingCookieMonster / BuildHelpers

Helper functions for PowerShell CI/CD scenarios
MIT License
214 stars 47 forks source link

Get-ProjectName in Azure Pipelines #107

Closed FISHMANPET closed 5 years ago

FISHMANPET commented 5 years ago

It looks like in Appveyor (and i'm sure other pipeline systems) when code is checked out it ends up in a directory that is named in a way that's somehow related to your project (not sure if Appveyor is using the name of your gitrepo or the name of your appveyor project since in this case they're identical). And this means your failsafe of "grab the name of the current directory" is a decent option.

However in Azure Pipelines (or at least MS hosted agent builds) the directory you're in has no relation to your project, all of mine are built in D:\a\1\s and since my particular project doesn't meet any of the other criteria, it ends up with a projectname of s which is not super useful. Azure Pipelines does publish the name of Repo, the Pipelines Project, and the name of the specific pipeline as environment variables. So one of those could be added as another fallback option

rlvandaveer commented 5 years ago

How is your code organized? Did you look at https://github.com/RamblingCookieMonster/BuildHelpers#get-project-name? It sounds like your psd1 is in the root of your repo.

FISHMANPET commented 5 years ago

Not all powershell projects are modules! My case in particular where I noticed this is a repo of Azure Automation Runbooks, so there's no .psd1 file anywhere. Additionally, looking closely at the code, the first case is assuming that your project will have a folder matching the name of the project, and that it will get checked out into a folder with the same name as the project, which will never be the case in Azure Devops unless your project is for some reason called s.

rlvandaveer commented 5 years ago

Well certainly. This project seems like it's primarily focused on helping with building modules however.

I think in order to get it to work out of the box for your use case, you could create a folder using the project name within your repo and then put the source you wish to build there. Then when you kick off your process, kick it off within that subfolder, not the root i.e., agent working directory.

rlvandaveer commented 5 years ago

So I was reading through some YAML build related documentation and found this tidbit which may be of use to you. https://docs.microsoft.com/en-us/azure/devops/pipelines/repos/pipeline-options-for-git?view=azure-devops#checkout-path

Checkout path By default, your source code will be checked out into a directory called s. For YAML pipelines, you can change this by specifying checkout with a path. The specified path is relative to $(Agent.BuildDirectory). For example: if the checkout path value is mycustompath and $(Agent.BuildDirectory) is C:\agent_work\1, then the source code will be checked out into C:\agent_work\1\mycustompath. Please note that the checkout path value cannot be set to go up any directory levels above $(Agent.BuildDirectory), so path..\anotherpath will result in a valid checkout path (i.e. C:\agent_work\1\anotherpath), but a value like ..\invalidpath will not (i.e. C:\agent_work\invalidpath).

You could specify a subpath with you project name in it.

peppekerstens commented 5 years ago

@rlvandaveer the code in this module is not always strict on that; check out Get-BuildVariable which leans heavily on environment variables of each build system. If this was a 'pure' Git/PS module, it could have done without. I am sure @RamblingCookieMonster had his reasons.

@FISHMANPET just use $(System.TeamProject). I do agree with @rlvandaveer; this is made for PS modules...