search

jupyterhub / configurable-http-proxy

node-http-proxy plus a REST API
BSD 3-Clause "New" or "Revised" License
242 stars 130 forks source link

Add changelog for 4.5.4 #451

Closed consideRatio closed 1 year ago

consideRatio commented 1 year ago
consideRatio commented 1 year ago

Thanks @minrk, comically dependabot opened a security bump PR just a minute after pushing a tag... If someone requests it I'll cut another release and ignore this for now.

minrk commented 1 year ago

it's in a test dependency, so doesn't affect the release. The bumped package isn't in the image or any install of CHP.

I wish node made it easier to distinguish dev dependencies from real ones.

I don't think we should need to bump the package version just to trigger image rebuilds, but the workflow may be the easiest way to do it. We should be able to rebuild/republish image tags, since the image tag is the version of the package, not the version of the image, and can be safely republished.

consideRatio commented 1 year ago

Oh hmmm, what about having package-lock.json only include non dev dependencies if that is possible? Does that sound reasonable to consider further to you?

"npm install" doesnt respect the lock file, if i recall correctly, only "npm ci" does.

consideRatio commented 1 year ago

To republish already tagged images is a controversial topic for us i recall. I'm undecided about it overall, but would rather for now keep adding a patch release to not need to reach agreement on a change in this case. I know its been discussed for z2jh images and the chp images in the past somewhere.

minrk commented 1 year ago

Yes, I think it's a fine compromise for the workflow. It just irks me a bit to make a versioned release of a package that says: "no changes, just triggering image rebuild by publishing a new tag".

I don't think we need to put any time into this right now, what we have is fine. Just rubs the "versions mean things" part of my brain the wrong way.

manics commented 1 year ago

I'm also against overwriting the most specific tag, if we want to rebuild a release tag I'd prefer it if we added a -N suffix.

We had a lot of discussion about the ideal way to build them in https://github.com/jupyterhub/team-compass/issues/474 but maybe we just go for something that works and refine the process later?

minrk commented 1 year ago

I think it's reasonable to expect security rebuilds of tagged images where the tag does not refer to the image, but something inside it. Docker image tags are not like git tags, they are more analogous to git branches and have reasonable expectations of updates unless the tag refers to the image itself (it does in our helm chart, it does not here or jupyterhub/jupyterhub or python:3.11.5, etc.).

I think the -N suffix is a good way to version the docker tag separately from the package. But I think what we have now is probably the best compromise of developer time vs sensible versions. The cost of publishing meaningless versions is pretty low (wasteful dependabot/conda-forge PRs, etc.) compared to the maintenance savings of having 1 package version == 1 docker image tag.