Azure-pipelines-tasks: Get Source Build Step Does Not Allow for Wildcards Under “Default branch for manual and scheduled builds”

[cwoodland]

Environment

Environment: VSTS
Account Name: connectionseducation.visualstudio.com
Team Project Name: EnterpriseSoftwarePortfolio
Definition: Test - Webmail - E2E and Test - Webmail
Agent Queue: TestBP

Issue Description

We have a need for the “Default branch for manual and scheduled builds” option under the
“Get Sources” build step to allow for wildcard entries similarly to the “Trigger Branch” filter options.
We trigger our E2E builds based on the completion of our SPA builds.
Our SPA builds are run on a release branch or a hotfix branch.
Consequently our “Trigger Branch” filter options for our E2E test builds are set to wildcard
as release/*, or hotfix/*
When the “Get Sources” step within the E2E build runs it does not pull the needed branch from the previous triggering SPA build.
For example, I could have a SPA release branch called release/test_branch.
Upon completion of the SPA build, the E2E build will start, however, the E2E build will not pull the needed sources from release/test_branch, but rather from the repository specified under “Default branch for manual and scheduled builds”. (In our case develop branch)
Is it possible to alter the “Default branch for manual and scheduled builds” to allow for wildcard entry, or are there any known solutions for this problem??

Thanks
[Include task name(s), screenshots and any other relevant details]

[bryanmacfarlane]

That's correct . The triggers support filters (because it's matching to trigger) but when it's scheduled or manually queued, there's no commit to filter against. In those scenarios you need to define the branch to use. There's nothing to filter (wildcard) against because the clock or the manual queue is the trigger.

That's by design.

[cwoodland]

Thanks for this info.
Any workarounds? Maybe via a Powershell script method that runs after the Get Sources and points to our desired release??

[cwoodland]

Also we are talking about a build being released based on a release branch or hotfix branch not a manual trigger.

[simonua]

@bryanmacfarlane, I'm on the same team as @cwoodland. I'm not sure I understand your response. The subsequent build is triggered by completion of our SPA build, say release/test_branch, but when this _automatic_ (not _manual_ or _scheduled_) build occurs, it still sources from the default branch. In other words, when would the branch filters ever become effective?

[bryanmacfarlane]

I see. It’s the triggering build.

Not a task issue ( svc not passing on trigger? ) but I’ll get to those folks

[simonua]

@bryanmacfarlane, thank you very much for reopening this!

Also, suppose there are multiple branches that would be applicable in the wildcards in both the primary SPA build and the subsequently-triggered End-to-End build. Humor us on having multiple concurrent release branches in this example, please:

• /release/A
• /release/B

Wildcards for both are release/*. release/B was just pushed to origin. The primary SPA build already successfully knows which sources to pull (B), but when the E2E build is triggered upon completion, would that build have awareness to also pull sources for **B? Does that context convey as part of the trigger?

Aside from the questions at hand, for context, we have completely separated builds for a SPA and the E2E tests that are executed against that. We had reasons to disassociate E2E tasks from the SPA build and ended up with two builds, one being triggered by the other.

[vijayma]

We have some work on our backlog soon so support an option on the build completion trigger - "Use the same branch as that of triggering build". That will be a better solution for your problem than changing the semantics of "default branch". This option makes complete sense if the same repository is used both in the triggering build and in the triggered build (as is the case in your example). We are debating if we need to do anything smarter (other than falling back to default branch) when the two repos are different. Thanks for the feedback.

[simonua]

@vijayma, yes, that's exactly what we are looking for! Is there a public timeline/backlog or another issue ID we can link to and subscribe to, please?

[cwoodland]

Thank you. Please let us know if we can help in anyway.
This item is important to us, so if we can act as testers etc. please let us know.

[simonua]

Hi @vijayma and @bryanmacfarlane, do you have any update regarding a timeline for this, please? Thank you!

[matkei]

Hi @vijayma and @bryanmacfarlane, is this still work in progress? Do you have a timeline on this? Thank you!

[moswald]

Hi @matkei, @simonua. We have this as a feature to implement on our backlog, but it is not scheduled to be implemented in the next couple of sprints.

As this is not a Tasks issue, I'm going to close this, but I have created this Developer Community thread to track it publicly. Please vote on it if it still interests you, as the "popularity" of posts is something we rely on when scheduling future features.