Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 08:54
    batzen opened #464
  • 01:05
    lock[bot] locked #433
  • 01:05
    lock[bot] commented #433
  • 01:05
    lock[bot] locked #442
  • 01:05
    lock[bot] commented #442
  • 01:05
    lock[bot] locked #437
  • 01:05
    lock[bot] commented #437
  • Apr 04 10:46
    tunger commented #461
  • Apr 04 10:43
    tunger synchronize #461
  • Apr 04 10:39
    tunger commented #461
  • Apr 04 10:38
    tunger commented #461
  • Apr 04 10:36
    unfurl-links[bot] commented #461
  • Apr 04 10:36
    tunger commented #461
  • Apr 04 10:32
    tunger synchronize #461
  • Apr 04 08:18
    unfurl-links[bot] commented #463
  • Apr 04 08:18
    jussimattila commented #463
  • Apr 04 08:17
    jussimattila assigned #463
  • Apr 04 08:17
    jussimattila opened #463
  • Apr 04 07:58
    lock[bot] locked #438
  • Apr 04 07:58
    lock[bot] commented #438
Eric Sondergard
@esond

Hi there, I'm having trouble figuring out how to get the auto-generated Azure Pipelines config to properly set the trigger branches for regular branch builds, as well as PRs. Here is the attribute decorating my Build class:

[AzurePipelines(null,
    AzurePipelinesImage.WindowsLatest,
    InvokedTargets = new[] {nameof(Compile)},
    NonEntryTargets = new []{nameof(Restore)},
    TriggerBranchesInclude = new[] {"master", "develop"},
    PullRequestsBranchesInclude = new[] {"master", "develop"})]

I would like to generate a .yml file that triggers builds only when either master or develop change, or when there is a pull request targeting either. I don't want to trigger a build on pushes to any other branch (right now). The "manual" config that I would have used before looked like:

trigger:
  - master
  - develop

pr:
  - master
  - develop

What am I missing here?

@esond The above attribute generates this yaml, by the way
stages:
  - stage: windows_latest
    displayName: 'windows-latest'
    dependsOn: [  ]
    pool:
      vmImage: 'windows-latest'
    jobs:
      - job: Compile
        displayName: 'Compile'
        dependsOn: [  ]
        steps:
          - task: CmdLine@2
            inputs:
              script: './build.cmd Restore Compile --skip'
Matthias Koch
@matkoch
@esond that’s just not implemented yet, you can create a PR if you like
Eric Sondergard
@esond
@matkoch Thanks for letting me know for sure. I will see if I can get some time to do just that.
Eric Sondergard
@esond
What's the advisory on the copyright headers? Should any headers for new files be dated 2020, and is it mandatory for all files (I see that most have them, but some don't)? If so I will add any missing headers to any files I have modifications on.
nawfalhasan
@nawfalhasan
We were using Cake until now but looking to move to something else. FlubuCore and Nuke look most promising to us. Can the tech lead here give a small briefing as to how they differ? They both seem to target the same main USP.
Matthias Koch
@matkoch
nawfalhasan
@nawfalhasan
@matkoch thanks, will go through and drop my thoughts here later.
nawfalhasan
@nawfalhasan

@matkoch

What is the idiomatic way of writing/organizing two totally different build scripts in Nuke?

Let's say I have one script which updates a DB schema on development machines, and another script which deploys production build. These two are completely independent scripts.

  1. How do I organize these? Write them in two different NukeBuild classes with two different target names? Or in one class?

  2. If they are in two different classes, can they have same target name?

Matthias Koch
@matkoch
@/all :mega::shipit: NUKE 0.24.5 IS OUT!!!
  • Fixed TeamCity configuration to use Bash script on Unix
Matthias Koch
@matkoch
@nawfalhasan I usually use the same build class but with partial files. you can check the build project of nuke itself
the general advantage being that you have one entry point for all tasks relevant to your solution
nawfalhasan
@nawfalhasan
I see..
Matthias Koch
@matkoch
@/all :mega::shipit: NUKE 0.24.6 IS OUT!!!
  • Fixed NuGet package resolution performance
  • Fixed MSBuild integration
  • Fixed TeamCity trace output to be dark gray
  • Fixed missing using statement for Nuke.Common.IO
Matthias Koch
@matkoch
@/all :mega::shipit: NUKE 0.24.7 IS OUT!!!
  • Fixed MSBuild targets for .NET Core
  • Fixed GitRepository.GetGitHubMilestone to retrieve milestone independent of state
Michael Tsai
@huanlin
After update to latest version, I get this error related to GitVersion:
image.png
"Package 'GitVersion.Tool' is referenced with multiple versions. Use NuGetPackageResolver and SetToolPath."
Matthias Koch
@matkoch
yes
Michael Tsai
@huanlin
How do I use NuGetPackageResolver and SetToolPath? Is there any example?
Matthias Koch
@matkoch
you should rather only reference one version
Michael Tsai
@huanlin
I'm not sure what you mean. But I only reference v5.2.4 in the build project:
image.png
Michael Tsai
@huanlin
I noticed that, the error message is about GitVersion.Tool package, but I'm using GitVersion.CommandLine package.
So I tried this: remove GitVersion.CommandLine package from my build project, and install GitVersion.Tool package.
However, it failed to install GitVersion.Tool package. Error message as below:
NU1202: Package GitVersion.Tool 5.2.4 is not compatible with netcoreapp3.0 (.NETCoreApp,Version=v3.0). Package GitVersion.Tool 5.2.4 supports:
  • netcoreapp2.1 (.NETCoreApp,Version=v2.1) / any
  • netcoreapp3.1 (.NETCoreApp,Version=v3.1) / any
    NU1212: Invalid project-package combination for GitVersion.Tool 5.2.4. DotnetToolReference project style can only contain references of the DotnetTool type
    Package 'GitVersion.Tool 5.2.4' has a package type 'DotnetTool' that is not supported by project '_build'.
Matthias Koch
@matkoch
Can you create a repro?
Michael Tsai
@huanlin
OK, the project in question is a bit complex. Let me create a simple project to see if I can reproduce it.
Matthias Koch
@matkoch
@all we also have a slack workspace which is way more active: https://slofile.com/slack/nukebuildnet
Michael Tsai
@huanlin
I'm also in slack channel. Should I move to slack for later discussion?
Matthias Koch
@matkoch
yes, but I definitely need a repro :) preferably on github
Michael Tsai
@huanlin
ok, on it :)
Michael Tsai
@huanlin
That's weired... a brand new project works perfect!
Michael Tsai
@huanlin
@matkoch I fixed it without knowing why.
I added the following line to _build.csproj:
<PackageDownload Include="GitVersion.Tool" Version="[5.1.1]" />
Then this error is gone: "Package 'GitVersion.Tool' is referenced with multiple versions...."
It seems the error message should be:
"Package 'GitVersion.Tool' is not found, please add <PackageDownload ...>not found, please add <PackageDownload ...> to your build.csproj file."
Matthias Koch
@matkoch
@/all :mega::shipit: NUKE 0.24.7 IS OUT!!!
  • Fixed MSBuild targets for .NET Core
  • Fixed GitRepository.GetGitHubMilestone to retrieve milestone independent of state
Eamon Hetherton
@EamonHetherton
any plans to target netcoreapp3.1 for globaltool?
Matthias Koch
@matkoch
yes
Eamon Hetherton
@EamonHetherton
my shiny new dev environment only has 3.1.3 :)
testing migrating some projects from cake to nuke and ran into:
It was not possible to find any compatible framework version
The framework 'Microsoft.NETCore.App', version '2.1.0' was not found.
  • The following frameworks were found:
    3.1.3 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Matthias Koch
@matkoch
:)) someone mentioned it today on our slack workspace
if you can, i recommend joining there.. it’s way more active
Eamon Hetherton
@EamonHetherton
sure...
Brendan-ABC
@Brendan-ABC
image.png
Using Nuke to generate my pipeline.yml file but running into issues when i tries to use Octopack in azure pipelines. When running on linux build agent i get the following error. Has anyone had this error or able to provide with a fix :)
Matthias Koch
@matkoch
check on slack