Skip to content
This repository was archived by the owner on Jan 23, 2023. It is now read-only.

[release/1.1.0] Add UpdateDependencies.ps1 to fix auto-PR submission #16868

Merged
merged 2 commits into from
Mar 12, 2018
Merged

[release/1.1.0] Add UpdateDependencies.ps1 to fix auto-PR submission #16868

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
09d4df5
Add UpdateDependencies.ps1
dagood Mar 9, 2018
d8a823b
Include auto-update project and target
dagood Mar 10, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 21 additions & 0 deletions UpdateDependencies.ps1
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
#
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason to not just call it run.ps1?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little concerned someone would expect it to work like run.cmd, like using the config.json settings. Making a more general name sounds reasonable, but ideally I'd like something that somehow gets across that it's "only" msbuild, and that it runs on .NET Core rather than full framework.

There's also a kind of symmetry that exists if we use this name, since both release/1.0.0 and release/1.1.0 will have both UpdatePublishedVersions.ps1 and UpdateDependencies.ps1, where release/1.0.0's are plain old powershell scripts and release/1.1.0's both use MSBuild.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm find with with not making it attractive to use but the name is definitely miss-leading. Should we at least have it have the correct project to build or do you plan to use it as a wrapper for other dotnet cli msbuild invocations.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, good point--since we have to make subscriptions.json changes anyway, I should move the project and target here. I don't plan on using this script for anything general.

# Copyright (c) .NET Foundation and contributors. All rights reserved.
# Licensed under the MIT license. See LICENSE file in the project root for full license information.
#

# This script initializes tools if necessary, then calls MSBuild using the
# dotnet CLI. This allows Maestro to run auto-update targets without
# encountering errors when contacting GitHub: .NET Core CLI supports TLS 1.2
# by default, but full framework doesn't.

$toolsLocalPath = Join-Path $PSScriptRoot "Tools"

$initTools = Join-Path $PSScriptRoot "init-tools.cmd"
& $initTools

# Execute MSBuild using the dotnet.exe host
$dotNetExe = Join-Path $toolsLocalPath "dotnetcli\dotnet.exe"
$msbuildExe = Join-Path $toolsLocalPath "msbuild.exe"
$testsBuildProj = Join-Path $PSScriptRoot "tests\build.proj"
& $dotNetExe $msbuildExe $testsBuildProj /t:UpdateDependenciesAndSubmitPullRequest $args
exit $LastExitCode