Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Add Deterministic DLLs for NuGet #80

Closed
SkyeHoefling opened this issue Jan 19, 2022 · 3 comments · Fixed by #89
Closed

Add Deterministic DLLs for NuGet #80

SkyeHoefling opened this issue Jan 19, 2022 · 3 comments · Fixed by #89

Comments

@SkyeHoefling
Copy link
Contributor

Description

The DLLs generated are not marked as deterministic when viewing in the NuGet Package Explorer. We need to update the build so they are deterministic.

https://nuget.info/packages/FileOnQ.Imaging.Heif/1.0.0

image

@SkyeHoefling
Copy link
Contributor Author

I spent a few hours looking into this and it doesn't make complete sense to me. As far as I can tell our builds are being compiled as deterministic builds. In both build.main.yml and build_pr.yml we use the compiler switch /p:ContinuousIntegrationBuild=true which is supposed to compile it as deterministic.

- name: Pack
run: dotnet pack -c Release -o ../../ /p:ContinuousIntegrationBuild=true /p:Version=${{ env.PACKAGE_VERSION }} /p:PackageVersion=${{ env.PACKAGE_VERSION }}
working-directory: ./src/FileOnQ.Imaging.Heif

I ran a clean build from my local environment and then performed the dotnet pack just as GitHub Actions are and I could get the build to be deterministic. Another weird thing I found was the -dev builds on NuGet are all deterministic, it appears just the final release one is not.

@mitchelsellers do you have any ideas what could be going on here?

@mitchelsellers
Copy link
Collaborator

I spent some time looking at this myself and I'm not 100% sure what the root of the issue might be, as you are correct, in theory it should be fine using the commands that are listed in the build, a few observations

  • I am doing things in my projects the more "old school" way as I outlined in this blog post
    • The upside to this, as it doesn't require the remembering of the proper flag, the downside is the need to configure
    • I also pack on build, so I don't have the second step involved in my builds. You can look at this project for one example
  • I'm not 100% sure how your source linking is working either, as we had to add the additional project as noted. (maybe a recent change in GitHub)
  • I noticed that the path as outlined in the -o parameter for the production path ends with a / it shouldn't matter, but I wonder if that isn't messing something up?

Not sure how much help this is at the moment but that's what I see different from other projects that I have working properly.

@SkyeHoefling
Copy link
Contributor Author

This is great feedback, I saw the technique of adding a special <PropertyGroup> to turn deterministic building on. I think that is going to be best for us to add something like this

<PropertyGroup Condition="'$(GITHUB_ACTIONS)' == 'true'">
    <ContinuousIntegrationBuild>true</ContinuousIntegrationBuild>
</PropertyGroup> 

With that added, we will be able to remove the manual switches in our dotnet cli commands

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants