"Emergency" lanes?

[mauroservienti]

Our very simple process states:

• no one can commit directly to master or develop
• changes can come through via PRs only (a fork or a branch)
• no one can merge their own PR, a review is required

So far so good, lovely.

Now, the issue (or at least potential issue) of the 4-eyes merge process in our scenario depends on the fact that we are not full time committed to the project, obviously. For the sake of the sample take into account the following scenario:

• A user raises a bug
• the triage process identifies the bug in the Presentation-something package
• in order to fix the bug, though, a change in an upstream package is required, say Radical

So:

1. create a PR in Radical
2. wait for the PR to be merged, at least in develop, so to publish the package to the MyGet feed
3. update packages in the downstream repo
4. create a PR in the downstream repo to fix the bug
5. wait for the PR to be merged, at least in develop, so to publish the package to the MyGet feed
6. Ask the user to test the fix in their environment using the MyGet feed
7. if OK repeat for master branch

Any way to improve the above scenario?

• we could publish, to MyGet only, the package even if the PR is not merged yet adding to the package name the source branch name as well, pollutes the MyGet feed but solves the above scenario very easily
• AppVeyor publishes for each project a NuGet feed with the artifacts of the build process, we could add that to our Visual Studio environment, but not for PRs
• each time a PR is built the resulting artifacts, thus the NuGet package as well, are stored by AppVeyor on the build server, the developer could manually download them and host them on a local/offline NuGet server
• the local build process could be tweaked to create packages as well so that everything can be tested locally before any push/PR

The latest one is my preferred approach.

[mauroservienti]

@micdenny thoughts?

[mauroservienti]

the following simple PS script should do the trick:

$root = (split-path -parent $MyInvocation.MyCommand.Definition) + '\..'
$version = [System.Reflection.Assembly]::LoadFile("$root\< assembly path >").GetName().Version
$versionStr = "{0}.{1}.{2}" -f ($version.Major, $version.Minor, $version.Build)

Write-Host "Setting .nuspec version tag to $versionStr"

$content = (Get-Content $root\< Nuget spec file >.nuspec) 
$content = $content -replace '\$version\$',$versionStr

$content | Out-File $root\< compiled output >.compiled.nuspec

& $root\NuGet\NuGet.exe pack $root\< compiled output >.compiled.nuspec

As far as I have understood the assembly version is set by the AppVeyor build, thus the following line will always output 1.0.0:

$version = [System.Reflection.Assembly]::LoadFile("$root\< assembly path >").GetName().Version
$versionStr = "{0}.{1}.{2}" -f ($version.Major, $version.Minor, $version.Build)

That is only downside that can be easily overcome manually setting the version at the command line given that this proposal is to reduce the pain in some corner case scenarios.

[mauroservienti]

The PS script could also use the AppVeyor local config file as the source for the version values, given that the process will be used only when working locally we have no interest at all in setting the correct version values in the AssemblyInfo file, the aim is to create the NuGet package.

Given the aim the script is also not interested at all in debug or release build, it will be debug only.

[micdenny]

each time a PR is built the resulting artifacts, thus the NuGet package as well, are stored by AppVeyor on the build server, the developer could manually download them and host them on a local/offline NuGet server

artifacts for PR are already pushed on AppVeyor and they are free to be downloaded by everyone:

I think this is the easiest way, to avoid adding to much complex on the build process, and leave an easy way to instantly test a PR, just download the nuget package and use it.

And listen this, appveyor has also got its own nuget feed for this use-cases! :smile:

for instance Radical project has this appveyor public nuget feed: https://ci.appveyor.com/nuget/radical-beci3al3osa3

and every build package will go there, even the PR that does not create a new build number, but in those cases the last build will overwrite the previous package, but it's just a matter of correctly dump the version on the PR and you're good to go, or of course just manually download the package or binaries.

[mauroservienti]

I just tested this and everything worked like a charm. Closing.