A set of convention based Cake scripts for building Chocolatey projects
License: Apache License 2.0
See https://github.com/chocolatey/choco for further development
Apache 2.0 - see docs/legal (just LEGAL in the zip folder)
##Please see the wiki
See docs/legal/CREDITS (just LEGAL/Credits in the zip folder)
When running on TeamCity, the default SignToolResolver is not able to find the signtool.exe due to us using an earlier (maybe later) version of the Windows SDK on that server.
Let's help out the resolver by registering the known location of the exe when running on TeamCity.
When running XBuild, we should respect what is configured for the TreatWarningsAsErrors configuration parameter, rather than hardcoding this to true.
This will be similar to how test overage reports are sent to TeamCity.
It should be possible to use the TeamCity.ImportData method that ships with Cake.
When using version 1.1.0 of Cake.DotNetTool.Module, the following error message is seen:
Error: Could not resolve type with token 01000046 from typeref (expected class 'System.Environment' in assembly 'System.Runtime, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a')
We should revert to version 0.4.0.
When running a build, we need to find a way of ensuring that the CI build is happening on the source repository for the code, and not for example a fork of the repository. This is needed in order to make decisions about which tasks are executed on any given CI build.
This functionality previously existed in the Recipe, but it was removed in this issue due to the fact that things work differently in TeamCity, compared to say AppVeyor.
Once we up to the latest version of Cake, we should remove the usage of Figlet in the build script, since this is now provided natively within Cake itself.
This depends on #4
Currently, the signing tests are only attempted when the following two criteria are met:
.WithCriteria(() => !string.IsNullOrWhiteSpace(BuildParameters.CertificateFilePath) && FileExists(BuildParameters.CertificateFilePath), "Skipping because unable to find certificate")
.WithCriteria(() => BuildParameters.ShouldAuthenticodeSignOutputAssemblies, "Skipping since authenticode signing of output assemblies has been disabled")
This works fine on a local machine, when those things are physically in place on the file system, but when running on TeamCity, those files don't exist in this location.
We need to update this criteria to include a check to see it the build is running on TeamCity.
This criteria was introduced to the testing tasks recently in order to be consistent with how other tasks work, however, in hindsight, I don't think we want this criteria at all, and it should be removed.
During the generation of the SolutionVersion.cs file on a non Windows machine, the generated path uses backslashes, when it should be using forward slashes.
This causes the build to fail, since the file can't be found.
Due to the slight difference in casing of the default namespaces across projects, the filter applied to unit test coverage means that sometimes no reports are generated.
We should make this less restrictive and take into consideration for example uppercase and lowercase of project name, which is typically what is used as test filter.
There has been some confusion around the NUGETDEV_SOURCE and what it's intended usage is, so we need to make it clearer about what this default environment variable is used for.
The NUGETDEV_SOURCE is intended to be used for the pushing of packages, and not for the restoring of packages. Sometimes, the URL that is in this variable might be used for both purposes, but within the Recipe script itself, the contents of this variable is only used for pushing of packages.
As such, we should remain NUGETDEV_SOURCE to be NUGETDEVPUSH_SOURCE.
In addition, we will introduce another NUGETDEVRESTORE_SOURCE, which will be configured to be used by default, when set, as one of the sources to restore packages from.
Each build provider has the concept of a PrintVariables properties, a collection of strings that represent environment variables that contain useful information. The intention was that these would be printed out into the build log when the build executed, however, the task to perform this work was never copied over from the original Cake.Recipe into this Recipe.
We need to add that task in, so that these variables are correctly written out.
In open source products, such as chocolatey/choco, we use ILMerge to create a final assembly (choco.exe, and chocolatey.dll) that can be put into the respective packages.
Chocolatey.Cake.Recipe currently doesn't have any support for ILMerge, only Eazfuscator.Net (which does ILMerge'ing, in addition to obfuscation). Support should be added to make it possible to define within the recipe.cake file of a project what assemblies need to be ILMerge'd and where they should be output to.
This should look similar to how we select what files are signed, which files are obfuscated, etc.
When a build executes on TeamCity, GitVersion sends a service message which says what build version was just executed. This is typically fine, however, we use a slightly different PackageVersion number to identify our builds. As such, we need to additionally call another service message to set the build number to be what we want when running on TeamCity.
To allow the:
When building on a PR branch, it is possible that generated package version is the following
Calculated Package Version: 1.2.0-pull2706me-20220430-663
This continues to cause problems when running choco pack, since the special portion of the version is still longer than 20 characters.
I think for this, when it isn't an alpha or beta prerelease label, we should drop the date portion of the version, and leave on the build counter.
After executing GitVersion, a number of version numbers are asserted, including the value for a milestone, which is then later used for generating/exporting release notes.
Currently, this property is not set to anything (it is null) and as a result, the release notes that are exported contain everything, rather than only the release notes for the tagged build that is happening.
We need to correctly set this property, as well as ensuing that all the asserted version numbers are correct, and being written out to the log correctly so that they can be viewed, and validated.
When this was first introduced it was based off how AppVeyor does it in terms of project name, and it was a simple check to ensure that the CI build was happening on the intended project. This is not as simple in TeamCity, and we need to find a way to associate a TeamCity Build Configuration as being against the intended repository.
This will be done in a follow up issue, and this issue is simply about removing this check completely.
This results in a null reference exception happening.
This can happen when an incompatible version of git is used when trying to run --show-current, which shipped with version 2.22. To aid with this happening, let's try to make it clearer that something errored, and also report with version of git it currently being used.
When running on TeamCity, the certificate password isn't stored on disk.
There is currently still an explicit check for the password on disk, and an attempt read the contents of the file. This causes an exception when running on TeamCity.
We need to not check for the password when running on TeamCity, and also modify the PowerShell script to create the certificate object in a different way, based on what information is provided.
To provide consistency in the way that package are created, make sure to use the asserted PackageVersion number when calling dotnet pack. Currently, the asserted SemVersion number is used, which isn't the same as what is used when creating Chocolatey packages.
Currently, this assumes that this is located in the lib folder of the project that is being built. This shouldn't be hard-coded here, and ideally Eazfuscator would be sourced as a tool by Cake, and placed in the tools folder, rather than having to add these assemblies into the lib folder of the project.
This functionality is currently defined in the recipe.cake file for Chocolatey GUI, however, it makes sense to bring this into Chocolatey.Cake.Recipe, as it means that a lot of code doesn't need to be duplicated.
It will be possible to provide an input list of all the MSI's that need to be signed, in the same way that you can for PowerShell Scripts and Assemblies.
There is an assumption that the MSI's will be generated from a single solution file, with the configuration set to WIX, which is currently how Chocolatey GUI does it. This can be extended if/when required, but in the initial release, this is the assumption that we will run with.
When defining WithCriteria on tasks, a single (or at most two) conditions should be used. That way, a reason can easily be provided in the build output as to why a task was skipped.
Remove the usage of a method like ShouldPublishGitHub() that contains lots of conditions, as then it becomes hard to understand exactly why a task was skipped during the build execution.
While updating this, it makes sense to ensure consistency in the reasons provided for skipping a task.
This will include:
Projects that use coverlet.collector instead of coverlet.msbuild is not detected and ran with the correct arguments to use coverlet as the coverage collection to use. Instead, the application OpenCover are used in these cases, which may in many cases not be able to collect the coverage report necessary.
Add support for detecting coverlet.collector automatically, and pass along the correct arguments when running the dotnet test utility.
N/A
N/A
When the file NuGet.Config do not exist, and a explicit nuget config path is not set the Recipe overrides any globally set sources to only be nuget.org sources.
When the NuGet.Config file do not exist, and no explicit config path is used I expected the global nuget configuration to be used instead if it exists to set/load the sources to use when restoring packages during an MSBuild.
[System.Environment]::OSVersion.version.tostring()): Windows 10$PSVersionTable): N/Achoco --version): N/A
Target: Clean
Configuration: Release
IsLocalBuild: True
IsPullRequest: False
IsTagged: False
IsMainRepository: False
PrepareLocalRelease: False
ShouldDownloadMilestoneReleaseNotes: True
ShouldDownloadFullReleaseNotes: False
Repository Name: Local
Branch Type: Develop
Branch Name: develop
IsDotNetCoreBuild: False
Solution FilePath: C:/repos/orgs/chocolatey/ChocolateyGUI/Source/ChocolateyGui.sln
Solution DirectoryPath: C:/repos/orgs/chocolatey/ChocolateyGUI/Source/ChocolateyGui
Source DirectoryPath: C:/repos/orgs/chocolatey/ChocolateyGUI/Source
Build DirectoryPath: C:/repos/orgs/chocolatey/ChocolateyGUI/code_drop
TreatWarningsAsErrors: True
BuildAgentOperatingSystem: Windows
RepositoryOwner: chocolatey
RepositoryName: ChocolateyGUI
NugetConfig: C:/repos/orgs/chocolatey/ChocolateyGUI/NuGet.Config (False)
Build Counter: -1
RestorePackagesDirectory: [NULL]
ProductName: Chocolatey GUI
ProductDescription: Chocolatey GUI is a product of Chocolatey Software, Inc. - All Rights Reserved
ProductCopyright: Copyright 2014 - Present Open Source maintainers of Chocolatey GUI, and Chocolatey Software, Inc. - All Rights Reserved.
ProductComVisible: False
ProductClsCompliant: False
ProductCompany: Chocolatey Software, Inc.
ProductTrademark: Chocolatey - Chocolatey Software, Inc.
ObfuscateAssembly: False
ForceContinuousIntegration: False
NuGetSources: https://www.nuget.org/api/v2/, https://api.nuget.org/v3/index.json
StrongNameDependentAssembliesInputPath: Source\packages\Splat*
ShouldStrongNameChocolateyDependenciesWithCurrentPublicKeyToken: False
AssemblyNamesRegexPattern: chocolatey.lib|chocolatey-licensed.lib|ChocolateyGui.Common|ChocolateyGui.Common.Windows
UseChocolateyGuiStrongNameKey: True
AllowedAssemblyName: chocolatey.dll, chocolatey.licensed.dll, ChocolateyGui.Common.dll, ChocolateyGui.Common.Windows.dll
TransifexEnabled: True
CanPullTranslations: False
CanPushTranslations: False
TransifexPullMode: OnlyTranslated
TransifexPullPercentage: 60
No Product Custom Attributes being usedCurrently, the usage of the .NET Global Tool versions of tools is decided based on whether the project you are building is a full fat .NET Framework project, or whether you are building using dotnet CLI.
This is typically fine, but we also need to ability to force the usage of the .NET Global Tools. This is necessary for example when running on the GitHub Actions Ubuntu image, where the full fat framework version of GitVersion doesn't run at all, and we need to run using the .NET Global Tool.
During execution of builds on TeamCity, the following is used:
Where the Branch Type is Unknown. This is due to the fact that the Branch Name is refs/heads/develop rather than simply develop.
The TeamCity Build Provider needs to be updated to correctly find the branch name based on the potential values here, for example refs/heads/develop, refs/tags/1.0.0, refs/heads/master, etc.
Chocolatey CLI has an open issue (chocolatey/choco#2703) to add a run of PSScriptAnalyzer as part of the build.
As Chocolatey CLI is moving to using Chocolatey.Cake.Recipe, it would be appropriate to add code here so as to be able to run PSScriptAnalyzer as part of the build.
It probably would be appropriate to use a PSScriptAnalyzerSettings.psd1 to set the options for PSScriptAnalyzer. I'm not sure if that means putting one in this repository, and having the option to override it, or requiring a PSScriptAnalyzerSettings.psd1 file for each project. If it is the second, perhaps if the file exists, that could be a signal to run PSScriptAnalyzer?
Also, there may need to be extra code added to exclude specific folder(s) where pester tests live, as they may produce false positives. See: chocolatey/choco#2596 (comment)
In the same way that we can choose to use the .NET Global Tool version of GitReleaeseManager, or the full fat .NET Framework version, we should be able to do the same with GitVersion.
This is necessary due to the fact that running the pinned version of GitVersion, 5.0.1, on the GitHub Actions Ubuntu image causes as error due to the bundled version of the LibGit2Sharp assemblies.
It is not possible to simply update to the latest version of the full fat .NET Framework version of GitVersion as this doesn't run at all on the same image.
This should just be CI. The amount of times that I misspell the full version is reason enough to rename it.
To allow the generated release notes to more closely match what the standard release notes format should be.
This format is documented here:
https://chocolatey.atlassian.net/wiki/spaces/PROD/pages/1970634768/Release+Notes+Format
This will include:
When attempting to use the current version of Cake.Git (0.19.0) there is an error when running on the latest GitHub Actions Ubuntu image (and also locally when running on Debian based systems).
This is due to the bundled version of the LibGit2Sharp assemblies that are used in Cake.Git.
We need to bump to a newer version, 1.1.0 (note, this isn't the latest version of this assembly, since the latest version doesn't support running on full fat .Net framework, which we currently still are with this Recipe).
The Recipe has the concept of an Export-Release-Notes task, which is intended to export the published release notes for a release, to then embed them within the application that is being built.
This is done for example within the Chocolatey GUI application.
However, the step that perform the export is not currently set as a dependency of any other task, therefore it is not executing at all.
This task needs to be correctly hooked up to ensure that it is ran, when it needs to be.
One of the artifacts created by UppercuT was the _BuildInfo.xml file, which contains all of the asserted version numbers, used as part of the build.
This is useful information to have, and we should look to generate a similar file during the execution of the Chocolatey.Cake.Recipe build, which can then be uploaded as an artifact into the CI system being used.
When running NUnit Console Runner, the unit test results file is never created. The OpenCover report is generated, but the intermediate files are not. These files are needed in order to report unit test results to say TeamCity.
Similar to what is in place for TeamCity.
It is highly likely that we are going to want to run builds in GitHub Actions as well as TeamCity, so we should add support for this here. We should be able to borrow the provider that exists today in Cake.Recipe.
Due to the fact that the Certificate Subject Name can contain spaces, it is important to ensure that this property is quoted when passed into the PowerShell script, otherwise, it won't work correctly.
ILMerge only runs on Windows:
https://github.com/dotnet/ILMerge#ilmerge
Currently, ILMerge works only on Windows-based platforms. It does not yet support Rotor or Mono.
So we should only try to run it there.
We need the ability to pull transifex translations when required, as well as to upload new definitions when something has changed.
A lot of this work, if not all of it, can be pulled from Cake.Recipe, and made to work how we require it.
We need to take the Chocolatey.Cake.Recipe which has been used internally for building some projects and make it Open Source.
This will allow us to start using it on the Chocolatey OSS projects, such as chocolatey/choco, chocolatey/ChocolateyGUI, etc.
Chocolatey.Cake.Recipe has the concept of pushing to:
Since these sources can actually be the same destination, we don't want to push the same package version twice, as this will cause an error.
As such, since the release source is only intended to be used when we are running a tagged build, make sure to not push to the pre-release source when it is a tagged build. i.e. the sources should be mutually exclusive.
When the GitReleaseManager tasks were copied over from the Cake.Recipe project, the BuildVersion Setup Context was left in place however, there was no Setup Task created to define what this is. As a result, when attempting to run these tasks, they failed, due to the context not being configured.
This didn't cause a problem locally, since the BuildVersion class is defined, but the tasks were attempted to be executed but skipped, so verification of the setup context existing wasn't done.
It wasn't until the tasks were run on the TeamCity server, where these tasks are exercised, that this problem presented itself 😢
When running a Chocolatey.Cake.Recipe build on a feature branch, or pull request, it can fail when it gets to the Create-Chocolatey-Packages task. This is due to the prerelease label being too long, which as a result, generates a package version similar to the following:
1.2.0-replace-uppercut-20220429
This is too long, since the special version part, i.e. replace-uppercut-20220429 is longer than 20 characters.
In the cases when this happens, we should simply truncate the prerelease label to be 10 characters, which should make everything work.
To help with diagnosing this problem, it would be good to output the package version at the point that the packages are going to be created, so that it is clear what is happening, if something else goes wrong.
Currently, when running an "official" build, the unit test tasks are skipped. However, other related tasks are not skipped, which causes confusion about what is going on.
When skipping tasks, we should consistently skip all related tasks, or not skip them at all.
This will give us the ability to use the Scriban templates to control how the release notes are generated when executing GitReleaseManager.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.