move JPEG reference test into separate CI job

[pmeier]

Addresses #5162 (comment). This is the newly added CI job.

cc @seemethere

[facebook-github-bot]

💊 CI failures summary and remediations

As of commit c070c6b (more details on the Dr. CI page):

---

💚 💚 Looks good so far! There are no failures yet. 💚 💚

---

This comment was automatically generated by Dr. CI (expand for details).

Please report bugs/suggestions to the (internal) Dr. CI Users group.

Click here to manually regenerate this comment.

[NicolasHug]

Thanks a lot for the PR @pmeier , I took a quick look, LMK what you think

[NicolasHug]

Any chance we could stick to conda instead of mamba, so as to stick to the current tools that we use in the rest of the job?

[pmeier]

We probably can (there is most likely a docker image that gives us conda), but I'm not sure we should. mamba is a re-implementation of the protocol, but faster. So we effectively waste CI resources by using conda.

[NicolasHug]

Shouldn't we rely on the same image as the other unittest jobs here, to avoid any risk of deviating from our "baseline" testing infra? I believe they all rely on conda as well so there must be a way to install conda, even if we don't choose condaforge/mambaforge as the image

[pmeier]

Besides our CPU workflows on Linux, none of the other workflows even use docker:

vision/.circleci/config.yml

Lines 719 to 722 in d675c0c

	unittest_linux_cpu:
	<<: *binary_common
	docker:
	- image: "pytorch/manylinux-cuda102"

vision/.circleci/config.yml

Lines 758 to 761 in d675c0c

	unittest_linux_gpu:
	<<: *binary_common
	machine:
	image: ubuntu-1604-cuda-10.2:202012-01

vision/.circleci/config.yml

Lines 808 to 811 in d675c0c

	unittest_windows_cpu:
	<<: *binary_common
	executor:
	name: windows-cpu

vision/.circleci/config.yml

Lines 846 to 849 in d675c0c

	unittest_windows_gpu:
	<<: *binary_common
	executor:
	name: windows-gpu

vision/.circleci/config.yml

Lines 893 to 896 in d675c0c

	unittest_macos_cpu:
	<<: *binary_common
	macos:
	xcode: "12.0"

Apart from that, they all download the miniconda installer:

vision/.circleci/unittest/linux/scripts/setup_env.sh

Line 25 in d675c0c

wget -O miniconda.sh "http://repo.continuum.io/miniconda/Miniconda3-latest-${os}-x86_64.sh"

vision/.circleci/unittest/windows/scripts/setup_env.sh

Line 22 in d675c0c

curl --output miniconda.exe https://repo.anaconda.com/miniconda/Miniconda3-latest-Windows-x86_64.exe -O

There is a container for that, but again, I see no point. It makes no difference if you install the environment with conda or mamba other than the latter is significantly faster.

[NicolasHug]

I'm happy to switch all of our jobs to mamba in another PR, but could we please stick to the same workflow that the other jobs are using? There is value in avoiding discrepancies with the rest of our CI jobs.

[pmeier]

What other workflow? Manually installing conda and setting things up or can I at least use a docker image with conda pre-installed?

[NicolasHug]

Sorry I'm a bit confused: what prevents us from staying as close as possible to unittest_linux_cpu: ?

[NicolasHug]

, it uses whatever jpeg library is already present instead of
packaging one.

I'm not sure I understand what this means. Should we just say "By installing Pillow from conda-forge, we make sure that pillow is built against libjpeg" ?

[NicolasHug]

Sorry I'm a bit confused: what prevents us from staying as close as possible to unittest_linux_cpu: ?