feat(http): optional query parameter to update only containers of a specified image

[Foxite]

Implements the second request from #1285: Added an optional query parameter that allows you to only update containers of the specified image. This works even if the image was built locally (ie the container no longer has the image label in docker ps).

Also includes an indentation fix that Goland went on strike over.

I will implement the first request later today, and probably add the ability to specify more than one image as well. This draft PR is so there can be a code review of what's already been done.

Don't hold back on roasting my Go skills. :P

[Foxite]

CI is saying url.Has is undefined, but this very much compiles (and works) on my end. Am I using the wrong Go version or something? I didn't tell my IDE what it should use, go.mod seems to set it to 1.12 which doesn't match what the CI seems to use (1.15).

[Foxite]

In any case, I think it's probably better to implement debouncing in the "glue proxy" that's needed if you use this to trigger updates by registry notifications, which is the only reason why debouncing is necessary in the first place.

[piksel]

CI is saying url.Has is undefined, but this very much compiles (and works) on my end. Am I using the wrong Go version or something? I didn't tell my IDE what it should use, go.mod seems to set it to 1.12 which doesn't match what the CI seems to use (1.15).

Yeah,

func (Values) Has, added in go1.17

But I added a suggestion for skipping it (and saving a few CPU cycles! :D)

[piksel]

In general, this looks good! The main blocker is the lock handling (and the URL.Values.Has call).

[codecov]

Codecov Report

Merging #1289 (a4ba473) into main (56368a7) will increase coverage by 0.68%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #1289      +/-   ##
==========================================
+ Coverage   63.13%   63.82%   +0.68%     
==========================================
  Files          23       23              
  Lines        1530     1534       +4     
==========================================
+ Hits          966      979      +13     
+ Misses        474      465       -9     
  Partials       90       90              

Impacted Files	Coverage Δ
pkg/filters/filters.go	83.63% <100.00%> (+2.38%)	⬆️
pkg/container/client.go	30.80% <0.00%> (+2.88%)	⬆️

---

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 56368a7...a4ba473. Read the comment docs.

[piksel]

@Foxite are you still working on this?

[Foxite]

I was confused by your earlier comment about the locking, I thought it was going to be complicated to make it do what I want (and postponed the task until I have time to learn about it). But upon re-reading it it seems simple; just to be clear, I understand that all that needs to be done is check if any images are specified, and only block on the lock if that's the case -- if not, then skip the request if the lock is not immediately acquired.

Or:

if len(images) > 0 {
  // old locking code
} else {
  // new locking code
}

Is that correct?

[Foxite]

I've gone ahead and done that, and it works. So if I've understood you correctly, this should be ready to merge.

[piksel]

Sorry about that. Yeah, that was what I meant. When there are filter arguments to the requests, it makes sense to queue them up (unless they are the same, but would be much more complex to implement), but if it's just a "do the update now" it's probably better to ignore them ("yes, I am currently doing the update"). And also for the aforementioned backwards compatibility.

[Foxite]

Looks like code coverage target is not met, I should probably write unit tests.

[Foxite]

@piksel I have added unit tests and all the checks are green, how does it look?

[piksel]

LGTM! Great job.

[piksel]

@all-contributors add @Foxite for code

[allcontributors]

@piksel

I've put up a pull request to add @Foxite! 🎉