[Test] downgrade nbgitpuller and jupyterhub in dev-r hub image

[balajialg]

@shaneknapp Let me know if you are okay with making changes to infra-req for dev-r? I will test this in staging and then revert the changes. Yet another data point that we can use to report upstream.

[shaneknapp]

this won't work as expected due to the hub image itself having a higher version of jupyterhub installed. you'll need to build and push a new image w/the lower deps installed.

i believe that you can specify this in staging.yml as hub.image.<etc>. @ryanlovett have you done this before?

[shaneknapp]

i'd also considering experimenting by also lowering the jupyterhub version to 4.0.x and keeping nbgitpuller at 1.2.1

[balajialg]

@shaneknapp Got it, thanks. If you can redirect me to a documentation then I will take a look at it. Or else we can probably do this during a short check-in if you are available.

[ryanlovett]

@shaneknapp I haven't done this exact thing before, but it should be possible to set a value in a deployment that masks any corresponding value in hub/values.yml. This would indeed be hub.image. To build a new hub image you'd modify images/hub/Dockerfile and build a new hub image with chartpress.

chartpress builds and pushes a new image, but it also changes the hub version in the top-level config automatically. So either you would let it do that, test a hub with hubploy, and not commit those changes until you want to deploy them for all hubs; or you would remove the top-level config changes to hub.image and manually insert them into the testing hub config, and commit that.

[shaneknapp]

@shaneknapp I haven't done this exact thing before, but it should be possible to set a value in a deployment that masks any corresponding value in hub/values.yml. This would indeed be hub.image. To build a new hub image you'd modify images/hub/Dockerfile and build a new hub image with chartpress.

chartpress builds and pushes a new image, but it also changes the hub version in the top-level config automatically. So either you would let it do that, test a hub with hubploy, and not commit those changes until you want to deploy them for all hubs; or you would remove the top-level config changes to hub.image and manually insert them into the testing hub config, and commit that.

ah i see. i created a PR to do that... could you take a look and we can carry that convo on over there? #5696

[shaneknapp]

@shaneknapp I haven't done this exact thing before, but it should be possible to set a value in a deployment that masks any corresponding value in hub/values.yml. This would indeed be hub.image. To build a new hub image you'd modify images/hub/Dockerfile and build a new hub image with chartpress.
chartpress builds and pushes a new image, but it also changes the hub version in the top-level config automatically. So either you would let it do that, test a hub with hubploy, and not commit those changes until you want to deploy them for all hubs; or you would remove the top-level config changes to hub.image and manually insert them into the testing hub config, and commit that.

ah i see. i created a PR to do that... could you take a look and we can carry that convo on over there? #5696

figured it out! #5696 (comment)

[shaneknapp]

i would suggest that after merging this and testing, to open another PR to bump nbgitpuller to 1.2.1 .

[balajialg]

@shaneknapp Sounds good. Will do