Skip to content

Conversation

@AlexNDRmac
Copy link
Contributor

@AlexNDRmac AlexNDRmac commented Oct 26, 2020

Prerequisites

  • I have written a descriptive pull-request title
  • I have verified that there are no overlapping pull-requests open
  • I have verified that I am following matches the existing coding patterns and practice as demonstrated in the repository. These follow strict Stylecop rules 👮.
  • I have provided test coverage for my change (where applicable)

Description

  • Fixed error with libgdiplus on macOS (Unable to load DLL 'libgdiplus')
  • Added cache action to CI workflow for all OS in build matrix

Related issue: #1387

@CLAassistant
Copy link

CLAassistant commented Oct 26, 2020

CLA assistant check
All committers have signed the CLA.

Copy link
Member

@JimBobSquarePants JimBobSquarePants left a comment

Choose a reason for hiding this comment

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

Some reference changes required here and a little cleanup. The unit test memory issues are known to us and only appear randomly. They relate to one of our test reference codecs.

git fetch --prune --unshallow
git submodule -q update --init --recursive
- name: Setup DotNet SDK
Copy link
Member

Choose a reason for hiding this comment

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

There's currently an issue with the setup-dotnet action which is preventing us from using it.

The macOs and Ubuntu images already have the required SDK installed.
https://github.com/actions/virtual-environments/blob/main/images/macos/macos-10.15-Readme.md#language-and-runtime

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not sure that is a bug. In my projects I'm also had such problems with netcore 2.x and netcore 3.x.
I can propose one solution for this:

  • Change build matrix
matrix:
  framework:
    - 'netcoreapp2.1'
    - 'netcoreapp3.1'
    - 'net472'
  • Configure matrix options:
matrix:
  options:
    - os: ubuntu-latest
      runtime: -x64
      codecov: true
   - os: macos-latest
      runtime: -x64
      codecov: true
  - os: windows-latest
      runtime: -x64
      codecov: true

  exclude:
   - os: ubuntu-latest
      framework: 'net472'
   - os: macOS-latest
      framework: 'net472'
  • Change runner:
jobs:
  Build:
    name: ${{ matrix.options.os }} ${{ matrix.framework }}
    runs-on: ${{ matrix.options.os }}

After that - you'll have next builds:

macOS-latest netcoreapp2.1
macOS-latest netcoreapp3.1
ubuntu-latest netcoreapp2.1
ubuntu-latest netcoreapp3.1
windows-latest netcoreapp2.1
windows-latest netcoreapp3.1
windows-latest net472

And little change for actions/setup-dotnet@v1

- name: Setup DotNet SDK 2.1.x
  if: (runner.os == 'macOS' || runner.os == 'Linux') && matrix.framework == 'netcoreapp2.1'
  uses: actions/setup-dotnet@v1
  with:
     dotnet-version: "2.1.x"

- name: Setup DotNet SDK 3.1.x
  if: (runner.os == 'macOS' || runner.os == 'Linux') && matrix.framework == 'netcoreapp3.1'
  uses: actions/setup-dotnet@v1
  with:
     dotnet-version: "3.1.x"

Copy link
Member

Choose a reason for hiding this comment

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

I'd consider it a bug since it used to work well enough until recent updates. I also chatted to the repo owner on Twitter and he encouraged me to raise the issue.

I don't understand the purpose of the exclude: additions here?

I'm not convinced your dotnet-setup filter will work. The application is multi targeted so if you setup 2.1.x then that will update the path and the build will likely fail. (Or does it work on unix for some bizarre reason?)

What I'm trying to get across here is that we want the absolute minimum of changes in order to make this work.

macos-latest on 3.1.x is the only target we need for now and we don't want to be running the tests with code coverage on multiple platforms.

Copy link
Contributor Author

@AlexNDRmac AlexNDRmac Oct 27, 2020

Choose a reason for hiding this comment

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

exclude - means, CI will skip some build matrix options which you'd like to do not run.

dotnet-setup filter will always work - it triggered by if condition. I agree that looks ugly, but it works explicitly.

I think, you can toying with all of these when you'll need. So, do you want to drop setup-dotnet action?
And... 6 tests on macOs failed, what I need to do with it? Because these fails not related to libgdiplus

Copy link
Member

Choose a reason for hiding this comment

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

Thanks for the updates. The tests are failing because the test environment is expecting a different reference codec. We need to update the tests and reference codec registration to cater for the new environment.

public void GetReferenceDecoder_ReturnsCorrectDecoders_Windows(string fileName, Type expectedDecoderType)
{
if (TestEnvironment.IsLinux)
{
return;
}
IImageDecoder decoder = TestEnvironment.GetReferenceDecoder(fileName);
Assert.IsType(expectedDecoderType, decoder);
}

private static Configuration CreateDefaultConfiguration()
{
var cfg = new Configuration(
new JpegConfigurationModule(),
new GifConfigurationModule(),
new TgaConfigurationModule());
// Magick codecs should work on all platforms
IImageEncoder pngEncoder = IsWindows ? (IImageEncoder)SystemDrawingReferenceEncoder.Png : new PngEncoder();
IImageEncoder bmpEncoder = IsWindows ? (IImageEncoder)SystemDrawingReferenceEncoder.Bmp : new BmpEncoder();
cfg.ConfigureCodecs(
PngFormat.Instance,
MagickReferenceDecoder.Instance,
pngEncoder,
new PngImageFormatDetector());
cfg.ConfigureCodecs(
BmpFormat.Instance,
IsWindows ? (IImageDecoder)SystemDrawingReferenceDecoder.Instance : MagickReferenceDecoder.Instance,
bmpEncoder,
new BmpImageFormatDetector());
return cfg;
}

@antonfirsov
Copy link
Member

antonfirsov commented Oct 29, 2020

I'm not sure whether the current state is acceptable (minimal workflows knowledge here), but it looks like there were only 6 failing tests ATM.
@AlexNDRmac can you decorate those with [PlatformSpecific(TestPlatforms.OSX)] to see if we can get a clean CI run?
EDIT: I meant [PlatformSpecific(~TestPlatforms.OSX)]

@AlexNDRmac
Copy link
Contributor Author

@antonfirsov pls look at CI. 503 code for myget when restoring packages. I can't restart CI jobs manually to check if all macOS test passed.

@antonfirsov
Copy link
Member

@AlexNDRmac re-runned, failed again. URI seems to have an extra dot at the end: https://www.myget.org/F/sixlabors/api/v3/index.json.

@JimBobSquarePants
Copy link
Member

Weird. That ref hasn't changed. I wonder if we should switch to a nuget.config file instead?

https://github.com/AlexNDRmac/ImageSharp/blob/af/macos-libgdiplus-fix/Directory.Build.props#L119

@JimBobSquarePants
Copy link
Member

Looks like they're having issues
http://status.myget.org/

@codecov
Copy link

codecov bot commented Oct 31, 2020

Codecov Report

Merging #1403 (9e27be8) into master (abc1573) will decrease coverage by 0.09%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1403      +/-   ##
==========================================
- Coverage   83.08%   82.99%   -0.10%     
==========================================
  Files         707      692      -15     
  Lines       31839    31189     -650     
  Branches     3590     3578      -12     
==========================================
- Hits        26454    25884     -570     
+ Misses       4668     4582      -86     
- Partials      717      723       +6     
Flag Coverage Δ
unittests 82.99% <ø> (-0.10%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
...mageSharp/Common/Helpers/SimdUtils.HwIntrinsics.cs 96.52% <0.00%> (-1.29%) ⬇️
src/ImageSharp/Common/Helpers/SimdUtils.cs 65.90% <0.00%> (-0.05%) ⬇️
...rc/ImageSharp/PixelFormats/Utils/PixelConverter.cs 100.00% <0.00%> (ø)
...tions/Generated/Bgr24.PixelOperations.Generated.cs 100.00% <0.00%> (ø)
...tions/Generated/Rgb24.PixelOperations.Generated.cs 100.00% <0.00%> (ø)
...ions/Generated/Argb32.PixelOperations.Generated.cs 100.00% <0.00%> (ø)
...ions/Generated/Bgra32.PixelOperations.Generated.cs 100.00% <0.00%> (ø)
...ions/Generated/Rgba32.PixelOperations.Generated.cs 100.00% <0.00%> (ø)
...on/GlobalHistogramEqualizationProcessor{TPixel}.cs 96.42% <0.00%> (ø)
...onverters/JpegColorConverter.FromGrayScaleBasic.cs
... and 31 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update abc1573...0b35db8. Read the comment docs.

@JimBobSquarePants
Copy link
Member

IT LIIIIVES! Well done @AlexNDRmac 🚀

Copy link
Member

@antonfirsov antonfirsov left a comment

Choose a reason for hiding this comment

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

Thank you very much for taking the time to work on this! 🥇 Almost done, just a few things.

When I was doing my experiments in #1302, I had 29 failing tests, now I see only 3 disabled ones. Majority was reporting a minor image difference, in stuff like AffineTransformTests or ProjectiveTransformTests:
https://pipelines.actions.githubusercontent.com/L8wwCFkW4FUCsGOMOcVKecb9uNpo8kI6vyU6NkDyYB5YnVAih3/_apis/pipelines/1/runs/689/signedlogcontent/3?urlExpires=2020-11-01T15%3A28%3A08.8086782Z&urlSigningMethod=HMACV1&urlSignature=nVb2mk%2FFsOwQSPIhd7lDVNYBnRxjNayA9q%2BcYI9Kqc4%3D

Any idea why are they gone now? Have you seen them locally?

Comment on lines 59 to 65
# - name: Setup nuget cache
# uses: actions/cache@v2
# id: nuget-cache
# with:
# path: ~/.nuget
# key: ${{ runner.os }}-nuget-${{ hashFiles('**/src/ImageSharp/*.csproj') }}
# restore-keys: ${{ runner.os }}-nuget-
Copy link
Member

Choose a reason for hiding this comment

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

Is this something we shall try to re-enable? If not then we should probably delete it.
Or if it might be useful in the future, let's document the purpose of the commented out code (and also the reason why is it commented out).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's disabled temporary. I'll enable it. If you don't mind, I recommend you to use cache for packages, it's seriously speedup build time.

}

[Theory]
[PlatformSpecific(~TestPlatforms.OSX)]
Copy link
Member

Choose a reason for hiding this comment

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

@JimBobSquarePants reminder to ourselves that we shall open an issue for the disabled tests when this gets merged.

@AlexNDRmac I suppose you work on Mac. Can you help us by posting the output images saved by these tests on your machine? (tests/Images/ActualOutput/ResizeTests/ResizeFromSourceRectangle_Rgba32_CalliphoraPartial.png). Same for the other 2 disabled tests.

Expected images are under tests/Images/External/ReferenceOutput/ResizeTests/ if interested.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I propose to use save-action and fail scenario. For example: tests on mac failed, then starts build step with condition 'on-fail' and save any details (pictures, logs... etc) as build artifacts. Next, you can download it for investigation :)
I can add this scenario to workflow, it's very simple and useful.

Copy link
Member

Choose a reason for hiding this comment

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

Sounds awesome, let's give it a try!
I wonder though what's simplest: here or in a separate PR?

Copy link
Member

Choose a reason for hiding this comment

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

Do the tests not fail locally or something?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think, better - is separate PR, because this improvement not related to libgdiplus.

On my Mac some tests failed, but on CI such tests - passed :) I use 10.14.16, but CI using 10.15.x.... and on my Mac some tests kills some dotnet sub-processes... It's very interesting case, maybe I can foud whick component have "magic" influence on tests, but experiments requires some time.

@AlexNDRmac
Copy link
Contributor Author

@antonfirsov pls restart CI... smh strange with builds :) macOS passed, but windows not.

@antonfirsov
Copy link
Member

@AlexNDRmac done, let's see ..

@AlexNDRmac
Copy link
Contributor Author

I see there is no progress with testing on CI... Why?

@antonfirsov
Copy link
Member

@AlexNDRmac in the last few days there were problems with GitHub, those seem to be fixed now, actions in other PR-s run nicely now, so there must be an issue with the current workflow setup.

image

I may remember it wrong but I think there was a point with a green CI run in this PR. Can we get back to the minimum set of changes that address the topic in the title and enable macOS runs? We can then try further improvements in follow-up PR-s.

@antonfirsov
Copy link
Member

@AlexNDRmac if you are still interested contributing the reference output exporter action to our builds, feel free to do it in a separate PR. (Providing an explanation how to use it!)

Otherwise ... I guess we should close this one, since the original goal has been completed in #1424. Or is there anything else?

@AlexNDRmac
Copy link
Contributor Author

@antonfirsov if you dont mind, I'd like to add cache to CI (it may speedup builds) and add step to store actual images for failed jobs (it can be useful for you to debug or investigate the reason of fail).

@antonfirsov
Copy link
Member

@AlexNDRmac cool, and thanks for the interest! I'm open for both, but prefer to see those as 2 separate (new) PR-s. Much easier to review them and reason about the changes.

@AlexNDRmac AlexNDRmac closed this Dec 2, 2020
@AlexNDRmac AlexNDRmac deleted the af/macos-libgdiplus-fix branch December 2, 2020 12:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants