[Feature request] Add option to use a checkout path of any repository in a multi-checkout scenario as the default working directory (System.DefaultWorkingDirectory)

[echalone]

This is a feature request for a new option in the checkout build step which would allow to set the default working directory of a build pipeline with multiple checkouts to the checkout path of the desired repository.

Important notice: I would have already implemented this feature in the agent as described below and have already created a pull request to the master branch of this repository: https://github.com/microsoft/azure-pipelines-agent/pull/3479 The pull request needs to be reviewed and accepted. Even if the feature is implemented in the agent, the Yaml checkout build step syntax of the Azure DevOps Server also needs to be expanded to allow for this option being used.

Currently the working directory of a build pipeline will always be wherever the build variable Build.SourcesDirectory is pointing to. The build variable System.DefaultWorkingDirectory is just a synonym that will so far always have the same value as Build.SourcesDirectory. However, in a multiple checkout scenario the Build.SourcesDirectory (and thus the default working directory) will always point to the default path "$(Pipeline.Workspace)/s" (e.g. "C:\agent_work\1\s") even if all the repositories get checked out to a custom path (e.g. "$(Pipeline.Workspace)/Repositories/*") and thus no repository actually got checked out below the default path where the working directory is pointing to. While this default behaviour should be kept for backwards compability alone, it is clearly not desirable if you're working with multiple repositories which get checked out to custom paths different from the default path. In the current case you would have to prefix all scripts, commands and files with the relative path (from /s) to your repository or use build variables like Pipeline.Workspace or Build.Repository.LocalPath to build your path to the repository. Instead, it would be better to define one repository as your default working directory and all scripts, commands and files without an absolute or relative path prefix will be resolved to this default working directory.

The variable System.DefaultWorkingDirectory would be the perfect choice to store the so changed default working directory in (if one has been chosen), while Build.SourcesDirectory would continue to point to the default path /s. If no repository would be chosen as the default working directory, the variable System.DefaultWorkingDirectory would just continue to have the same value as Build.SourcesDirectory. Therefore, all build pipelines would be backwards compatible, as the value for Build.SourcesDirectory would never change and the value for System.DefaultWorkingDirectory would only change if somebody makes use of this new functionality.

After this functionality has been added to the agent, the Yaml checkout build step syntax needs to be expanded on the Azure DevOps Server to allow for this additional option to be provided. Otherwise this feature cannot be used, even if implemented in the agent. The documentation for the Yaml checkout build step would of course also need adaption. While I was able to prepare the implementation of this feature on the agent, the Azure DevOps Server code is not open source, therefore I am sadly not able to support you on extending the Yaml checkout build step syntax.

[github-actions[bot]]

This issue has had no activity in 180 days. Please comment if it is not actually stale

[echalone]

Commenting so feature request doesn't go stale, PR is still active too

[copdips]

This is definitely a big issue for backwark compatibility, the source code is no more in the /s folder in case of multiple checkouts. For e.g. /home/vsts/work/1/s in case of the default Microsoft hosted ubuntu agent.

My workaround before the merge of this PR is to:

1. add path: expectedRepoName to each checkout, it will checkout the repositories to $PIPELINE_WORKSPACE, which is at /home/vsts/work/1, be careful don't use repo name like a, b, s, TestResults, they're reserved by Microsoft.
2. add script: cp "$PIPELINE_WORKSPACE/expectedRepoName/." "$PIPELINE_WORKSPACE/s" -r

From now on, the expected repository source code is under /s folder, and no need to change the working directory anymore.

[echalone]

The default behavior of the agent is not changed by this PR (if that was what you meant). There's currently also a bug in the behavior of the agent finding out which is the default directory which is fixed in another PR currently under review. This feature will only allow you to change the default working directory from the default behavior, it won't change the default behavior (so backwards compatibility should be alright).

[github-actions[bot]]

This issue has had no activity in 180 days. Please comment if it is not actually stale

[echalone]

not really stale

[github-actions[bot]]

This issue has had no activity in 180 days. Please comment if it is not actually stale

[echalone]

nope, not really stale dear bot, I'm still waiting and hoping for responses by Microsoft

[github-actions[bot]]

This issue has had no activity in 180 days. Please comment if it is not actually stale

[echalone]

Day 909 of Issue 3484. The fight against stale-bot in the bustling realm of GitHub continues. In this digital haven, developers from all corners of the world united to create, innovate, and collaborate on groundbreaking projects. Among them was issue 3484, a seemingly ordinary piece of feature request with already implemented code that found itself at the center of an epic battle against the nefarious stale-bot.

The stale-bot, a silent and relentless enforcer, patrolled the virtual corridors of GitHub. Every 180 days, it marked issues and pull requests as stale if the eerie silence of inactivity lingered around them. It cared not for the dreams and aspirations encoded into the tickets by the developers. It had a mission – to prune any repository of stagnation.

However, the inhabitants of GitHub were not about to let their hard work be cast into the digital abyss. Led by a fearless developer named echalone, a group of rebels gathered to wage war against the merciless stale-bot.

Echalone, with fiery determination in his eyes, rallied the troops. "We shall not let our creations be labeled as 'stale' without a fight! Together, we stand strong against the ticking clock of inactivity."

The rebels dove into the battlefield that was issue 3484. Lines of code clashed like swords, and comments echoed in the virtual air. They poured their hearts into the issue, breathing life into the once-silent conversation.

Days turned into nights as the rebels tirelessly fought against the impending doom of staleness. They brainstormed ideas, exchanged witty banter, and celebrated small victories. The camaraderie among the rebels grew stronger with each passing moment.

As the 180-day mark approached, the stale-bot loomed, ready to cast its judgment. But the rebels were prepared. They flooded issue 3484 with comments, discussions, and updates. The silence that once threatened to consume the ticket was replaced with a symphony of collaboration.

In the final hours, echalone typed the triumphant words, "We've conquered the stale-bot! Our feature request shall remain vibrant and alive!" The rebels cheered, their victory echoing through the virtual halls of GitHub.

And so, the tale of issue 3484 became a legend in the digital realm, a testament to the resilience of developers against the relentless forces of stagnation. The rebels continued their journey, knowing that their fight against the stale-bot was just one chapter in the ongoing saga of GitHub – a realm where creativity and collaboration triumphed over the silence of inactivity.

[sekoch]

@echalone Thanks for your endurance. I am running in the same "problem" and I would appreciate such a solution you mentioned.

After 2,5 years microsoft should answer here..

[github-actions[bot]]

This issue has had no activity in 180 days. Please comment if it is not actually stale