Version upgrade bot failures

[h-vetinari]

Happening on a bunch of feedstocks, judging from the status page:

• numpy (disappeared now after manually doing https://github.com/conda-forge/numpy-feedstock/pull/285)

  - could not hash URL template 'https://github.com/numpy/numpy/releases/download/v{{ version }}/numpy-{{ version }}.tar.gz'

• grpc_java_plugin

  The recipe did not change in the version migration, a URL did not hash, or there is jinja2 syntax the bot cannot handle!
  
  Please check the URLs in your recipe with version '1.51.1' to make sure they exist!
  
  We also found the following errors:
  
  - missing jinja2 variable 'bazel_sha' for selector 'None'
  - could not hash URL template 'https://github.com/bazelbuild/bazel/releases/download/{{ bazel_version }}/bazel_nojdk-{{ bazel_version }}-{{ bazel_arch }}'

• gymnasium

  - could not hash URL template 'https://pypi.io/packages/source/g/gym/gym-{{ version }}.tar.gz'

• icu

  - could not hash URL template 'https://github.com/unicode-org/icu/releases/download/release-{{ version_hyphen }}/icu4c-{{ version_under }}-src.tgz'
  - could not hash URL template 'https://github.com/unicode-org/icu/releases/download/release-{{ version_hyphen }}/icu4c-{{ version_under }}-data.zip'

• openjdk

  - could not hash URL template 'https://github.com/adoptium/temurin17-binaries/releases/download/jdk-{{ version }}+{{ openjdk_revision }}/OpenJDK17U-jdk_aarch64_linux_hotspot_{{ version }}_{{ openjdk_revision }}.tar.gz'
  - could not hash URL template 'https://github.com/adoptium/temurin17-binaries/releases/download/jdk-{{ version }}+{{ openjdk_revision }}/OpenJDK17U-jdk_x64_linux_hotspot_{{ version }}_{{ openjdk_revision }}.tar.gz'
  - could not hash URL template 'https://github.com/adoptium/temurin17-binaries/releases/download/jdk-{{ version }}+{{ openjdk_revision }}/OpenJDK17U-jdk_ppc64le_linux_hotspot_{{ version }}_{{ openjdk_revision }}.tar.gz'
  - could not hash URL template 'https://cdn.azul.com/zulu/bin/zulu{{ zulu_build }}-jdk{{ version }}-win_x64.zip'
  - could not hash URL template 'https://cdn.azul.com/zulu/bin/zulu{{ zulu_build_arm64 }}-jdk{{ version }}-macosx_aarch64.zip'
  - could not hash URL template 'https://cdn.azul.com/zulu/bin/zulu{{ zulu_build }}-jdk{{ version }}-macosx_x64.zip'

• pypy3.6

  - missing jinja2 variable 'name' for selector 'name_suffix == "3.8"'
  - missing jinja2 variable 'name' for selector 'name_suffix == "3.9"'
  - could not hash URL template 'https://downloads.python.org/pypy/{{ name }}-v{{ version }}-src.tar.bz2'

• qt-main (qt 6.4.1 has been released already)

  - could not hash URL template 'https://download.qt.io/official_releases/qt/{{ version.rpartition('.')[0] }}/{{ version }}/single/qt-everywhere-opensource-src-{{ version }}.tar.xz'

• etc...

Other errors in feedstocks that used to work (and rerender fine)

• allennlp

  We found a problem parsing the recipe for version '2.10.1': 
  
  AssertionError('\n')

• docker-py

  No error information available for version '6.0.1'.

• faiss-split

  We found a problem parsing the recipe for version '1.7.3': 
  
  ParserError('while parsing a block mapping',   in "", line 130, column 7:
          string__###conda-selector###__cu ... 
          ^ (line: 130), "expected , but found ''",   in "", line 131, column 109:
     ...  cuda_compiler_version|replace(".", "") }}h<{ PKG_HASH }}_<{ PKG ... 
                                         ^ (line: 131))

• torchvision (note v=5996! perhaps upstream pushed a broken tag?)

  Please check the URLs in your recipe with version '5996' to make sure they exist!
  
  We also found the following errors:
  
  - could not hash URL template 'https://github.com/pytorch/vision/archive/v{{ version }}.tar.gz'

[beckermr]

Thanks. The easiest way to debug is to add unit tests for these updates. I don't have time but feel free if you have the energy.

[mariusvniekerk]

Seeing the same for the opentelemetry stack

[mariusvniekerk]

1.15.0:  |
   The recipe did not change in the version migration, a URL did not hash, or there is jinja2 syntax the bot cannot handle!

   Please check the URLs in your recipe with version '1.15.0' to make sure they exist!
   We also found the following errors:
    - could not hash URL template 'https://pypi.io/packages/source/{{ name[0] }}/{{ name }}/{{ name }}-{{ version }}.tar.gz'

[beckermr]

Did you check pypi itself? It has an open bug where it is not making urls like that.

[beckermr]

So some of these are bad version tags I suspect. For example, for icu, the version found was "2022-09-12" which is not a version. This happens for github URLs when people add in tags/releases which are not actually part of the main release series.

[beckermr]

@mariusvniekerk At least one of the opentelemetry errors is a pypi bug.

$ wget https://pypi.io/packages/source/o/opentelemetry_exporter_jaeger/opentelemetry-exporter-jaeger-1.15.0.tar.gz
--2022-12-25 08:24:14--  https://pypi.io/packages/source/o/opentelemetry_exporter_jaeger/opentelemetry-exporter-jaeger-1.15.0.tar.gz
Resolving pypi.io (pypi.io)... 151.101.64.223, 151.101.128.223, 151.101.192.223, ...
Connecting to pypi.io (pypi.io)|151.101.64.223|:443... connected.
HTTP request sent, awaiting response... 301 Redirect to Primary Domain
Location: https://pypi.org/packages/source/o/opentelemetry_exporter_jaeger/opentelemetry-exporter-jaeger-1.15.0.tar.gz [following]
--2022-12-25 08:24:15--  https://pypi.org/packages/source/o/opentelemetry_exporter_jaeger/opentelemetry-exporter-jaeger-1.15.0.tar.gz
Resolving pypi.org (pypi.org)... 151.101.64.223, 151.101.128.223, 151.101.192.223, ...
Connecting to pypi.org (pypi.org)|151.101.64.223|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://files.pythonhosted.org/packages/source/o/opentelemetry_exporter_jaeger/opentelemetry-exporter-jaeger-1.15.0.tar.gz [following]
--2022-12-25 08:24:15--  https://files.pythonhosted.org/packages/source/o/opentelemetry_exporter_jaeger/opentelemetry-exporter-jaeger-1.15.0.tar.gz
Resolving files.pythonhosted.org (files.pythonhosted.org)... 146.75.81.63
Connecting to files.pythonhosted.org (files.pythonhosted.org)|146.75.81.63|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2022-12-25 08:24:15 ERROR 404: Not Found.

This same download works fine for 1.10.0

$ wget https://pypi.io/packages/source/o/opentelemetry-exporter-jaeger/opentelemetry-exporter-jaeger-1.10.0.tar.gz
--2022-12-25 08:24:09--  https://pypi.io/packages/source/o/opentelemetry-exporter-jaeger/opentelemetry-exporter-jaeger-1.10.0.tar.gz
Resolving pypi.io (pypi.io)... 151.101.64.223, 151.101.128.223, 151.101.192.223, ...
Connecting to pypi.io (pypi.io)|151.101.64.223|:443... connected.
HTTP request sent, awaiting response... 301 Redirect to Primary Domain
Location: https://pypi.org/packages/source/o/opentelemetry-exporter-jaeger/opentelemetry-exporter-jaeger-1.10.0.tar.gz [following]
--2022-12-25 08:24:09--  https://pypi.org/packages/source/o/opentelemetry-exporter-jaeger/opentelemetry-exporter-jaeger-1.10.0.tar.gz
Resolving pypi.org (pypi.org)... 151.101.64.223, 151.101.128.223, 151.101.192.223, ...
Connecting to pypi.org (pypi.org)|151.101.64.223|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://files.pythonhosted.org/packages/source/o/opentelemetry-exporter-jaeger/opentelemetry-exporter-jaeger-1.10.0.tar.gz [following]
--2022-12-25 08:24:09--  https://files.pythonhosted.org/packages/source/o/opentelemetry-exporter-jaeger/opentelemetry-exporter-jaeger-1.10.0.tar.gz
Resolving files.pythonhosted.org (files.pythonhosted.org)... 146.75.81.63
Connecting to files.pythonhosted.org (files.pythonhosted.org)|146.75.81.63|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://files.pythonhosted.org/packages/d0/b1/a212763cc68211ba98d55d1141f2a7a2e03fe26a562462f0c4e227896f6f/opentelemetry-exporter-jaeger-1.10.0.tar.gz [following]
--2022-12-25 08:24:10--  https://files.pythonhosted.org/packages/d0/b1/a212763cc68211ba98d55d1141f2a7a2e03fe26a562462f0c4e227896f6f/opentelemetry-exporter-jaeger-1.10.0.tar.gz
Reusing existing connection to files.pythonhosted.org:443.
HTTP request sent, awaiting response... 200 OK
Length: 6370 (6.2K) [application/x-tar]
Saving to: ‘opentelemetry-exporter-jaeger-1.10.0.tar.gz’

opentelemetry-exporter-jaeger-1.10.0.tar.g 100%[======================================================================================>]   6.22K  --.-KB/s    in 0.001s  

2022-12-25 08:24:10 (5.17 MB/s) - ‘opentelemetry-exporter-jaeger-1.10.0.tar.gz’ saved [6370/6370]

[beckermr]

In general, if the bot says it cannot hash a url, then either

1. Upstream pushed a bad tag
2. The url has changed (e.g., pypi bug)
3. There was an intermittent error and the bot will retry

The issues above related to missing jinja keys, recipe parsing, etc. are worth looking into more.

[beckermr]

For grpc_java_plugin it looks like on the variables is in the conda_build_config and not defined for the no selector case. This is an assumption made by the bot. Usually in these cases we have to rework the recipe a bit though maybe there might be a way to edit the bot source to make it work.

[beckermr]

Let's all agree to not worry about pypy3.6. It doesn't get many updates and requires humans in general.

[beckermr]

@h-vetinari This line and similar in faiss-split are not properly formatted for the jinja2+yaml parser we use

https://github.com/conda-forge/faiss-split-feedstock/blob/main/recipe/meta.yaml#L131

[beckermr]

docker-py and numpy must be intermittent errors since they both work in the new one

[h-vetinari]

docker-py and numpy must be intermittent errors since they both work in the new one

Numpy failed again on the just released 1.24.1:

The recipe did not change in the version migration, a URL did not hash, or there is jinja2 syntax the bot cannot handle!

Please check the URLs in your recipe with version '1.24.1' to make sure they exist!

We also found the following errors:

 - could not hash URL template 'https://github.com/numpy/numpy/releases/download/v{{ version }}/numpy-{{ version }}.tar.gz'

[beckermr]

Can you check that url by hand?

[h-vetinari]

Can you check that url by hand?

Yeah, works fine:

>curl -L https://github.com/numpy/numpy/releases/download/v1.24.1/numpy-1.24.1.tar.gz | sha256sum
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0
100 10.3M  100 10.3M    0     0  1322k      0  0:00:08  0:00:08 --:--:-- 2167k
2386da9a471cc00a1f47845e27d916d5ec5346ae9696e01a8a34760858fe9dd2 *-

I'm not sure how big of a time gap there is between publishing the tag and the bot picking that up, versus the release actually being uploaded to the release page. But even if that URL didn't work for the first run, the bot should retry in any case?

[beckermr]

The bot will retry but it takes a day or so.

[beckermr]

This is rather odd. The tests pass with this version.

[beckermr]

The hashing failed three times over ~6-9 hours: https://github.com/regro/cf-graph-countyfair/blob/master/node_attrs/numpy.json#L4963

So I don't think it is a delay in the posting of the data after the tag but I can't reproduce the hash failure.

[h-vetinari]

Not sure what changed, but the bot finally ended up opening https://github.com/conda-forge/numpy-feedstock/pull/286

[beckermr]

Geeze ok. Well IDK what is going on but at least it can work...