Properly condition onelocbuild template #6561
Conversation
.vsts-dotnet.yml
Outdated
| CreatePr: false | ||
| LclSource: lclFilesfromPackage | ||
| LclPackageId: 'LCL-JUNO-PROD-MSBUILD' | ||
| - {{ if eq(variables['Build.SourceBranch'], 'refs/heads/main') }}: |
There was a problem hiding this comment.
Don't we almost always want this in our release branches? The loc handback is almost always after we've branched for release.
There was a problem hiding this comment.
Loc handback occurs continuously now. When you branch for release, you can change this to continue receiving loc handback from those branches.
There was a problem hiding this comment.
Right, I wasn't considering future release branches. We can modify this to include an or(XXX, startsWith(refs/heads/vs))
There was a problem hiding this comment.
Yeah, would love to filter on the pattern. Don't love the idea of adding a step to branching for release, which is currently git-only.
There was a problem hiding this comment.
Don't love the idea of adding a step to branching for release
I also prefer just adding the or instead of having us manually push stuff each release. Will add the condition
There was a problem hiding this comment.
I don't recommend this as it will cause problems with OneLocBuild, which expects to receive artifacts from only one branch. There's a whole official process for branching for release which you can read here.
If you want to run two branches at once, you'll need two separate package repositories on the loc side (the LCL-JUNO bit). You'll need to file a ticket with the loc team about doing that.
There was a problem hiding this comment.
Wait, but how would this fix that? You're saying that we need to change the build definition in both the release branch and the main branch for every release?
There was a problem hiding this comment.
Talked offline. The answer is evidently "yes, this is what we must do".
benvillalobos
force-pushed
the
onelocbuild-update
branch
3 times, most recently
from
5bfd681 to
20aa42b
Compare
|
Official build test here: https://dev.azure.com/devdiv/DevDiv/_build/results?buildId=4869878&view=results |
|
Is it possible to test the release-branch condition as well? |
|
Oh, and: this is going to |
https://dev.azure.com/devdiv/DevDiv/_build/results?buildId=4870284&view=results
Yeah I believe so. I was wondering if we should target 16.10 but it isn't LTS so I assume we pass on that even though it has the template import. Looks like there's a onelocbuild failure with our internal repo (/cc: @jonfortescue): https://dev.azure.com/devdiv/DevDiv/_build/results?buildId=4870284&view=logs&j=6aa31087-d1b8-5ee1-af29-f0fe63353381&t=f5f0ecb8-e09a-5b29-99cb-311e048f2c1c
|
…ecause we have an internal mirror. Note that MirrorRepo is somewhat confusing. The GH repo is set as MirrorRepo because, in the context of an official build, the build runs FROM the internal mirror and GH is the mirror.
benvillalobos
force-pushed
the
onelocbuild-update
branch
from
20aa42b to
ff1b14d
Compare
|
Rebased onto vs16.11. This is currently blocked on the linked failing official build (see above). |
|
@benvillalobos investigating. |
|
@benvillalobos looks like msbuild hasn't taken arcade latest which is where these changes to the template were introduced. This PR will need to be merged and put onto this branch before these changes work. |
|
We don't plan to ever take that into this branch. It's a 5.x servicing branch. Is there an equivalent Arcade 5 update? |
|
@rainersigwald ah, right, I forgot about that. There will be one soon! |
|
@rainersigwald @benvillalobos next release/5.0 update from arcade will contain the necessary changes! |
rainersigwald
force-pushed
the
onelocbuild-update
branch
from
7c6c8a5 to
263e8db
Compare
|
I merged the Arcade update and changed the condition to be current-release-branch only. A build on not-that-branch shows the OneLocBuild step missing: https://dev.azure.com/devdiv/DevDiv/_build/results?buildId=4878158 @jonfortescue can you give this a once-over again please? |
rainersigwald
added
Area: Our Own Build
|
@rainersigwald @benvillalobos this all looks good to me! |
|
Build passed, bypassing policy due to reporting outage. https://dev.azure.com/dnceng/public/_build/results?buildId=1190370&view=results |
|
Ok, so the loc portion of the build passed: https://dev.azure.com/devdiv/DevDiv/_build/results?buildId=4878749&view=logs&j=6aa31087-d1b8-5ee1-af29-f0fe63353381&t=f5f0ecb8-e09a-5b29-99cb-311e048f2c1c But the PR generated #6571 went to |
|
shoot. I should have caught that, I'm sorry. Yes, you'll need to specify |
Context
Migrates us "fully" onto the OneLocBuild.yml template. We were missing a condition and parameter in the template import.
Thought: This doesn't need to be backported to <=
vs16.11right? Those builds should be having the onelocbuild template imported regardless. On second thought, they may need theMirrorRepoparameter.Changes Made
Add
MirrorRepoparameterAdd condition on importing the template.
Testing
Will create
exp/branch to test this.Notes