feat: add ability to pin major, minor or patch version

[seowalex]

As referenced in #75 (comment), I have implemented version pinning for updates. Some examples:

No pinning (current behaviour):

╭─────────────────────────────────────────────────────────┬──────────────────────────────┬─────────╮
│Reference                                                │Status                        │Time (ms)│
├─────────────────────────────────────────────────────────┼──────────────────────────────┼─────────┤
│docker.io/library/mariadb:10.11                          │Major update (10.11 → 11.7)   │600      │
│docker.io/library/elasticsearch:8.13.0                   │Minor update (8.13.0 → 8.17.4)│732      │
│docker.io/library/memcached:1.6.18                       │Patch update (1.6.18 → 1.6.38)│268      │
│ghcr.io/sergi0g/cup:latest                               │Update available              │291      │
│docker.io/gitea/gitea:latest                             │Up to date                    │752      │
╰─────────────────────────────────────────────────────────┴──────────────────────────────┴─────────╯

Pin major updates:

╭─────────────────────────────────────────────────────────┬──────────────────────────────┬─────────╮
│Reference                                                │Status                        │Time (ms)│
├─────────────────────────────────────────────────────────┼──────────────────────────────┼─────────┤
│docker.io/library/elasticsearch:8.13.0                   │Minor update (8.13.0 → 8.17.4)│732      │
│docker.io/library/memcached:1.6.18                       │Patch update (1.6.18 → 1.6.38)│268      │
│ghcr.io/sergi0g/cup:latest                               │Update available              │291      │
│docker.io/gitea/gitea:latest                             │Up to date                    │752      │
╰─────────────────────────────────────────────────────────┴──────────────────────────────┴─────────╯

Pin minor updates:

╭─────────────────────────────────────────────────────────┬──────────────────────────────┬─────────╮
│Reference                                                │Status                        │Time (ms)│
├─────────────────────────────────────────────────────────┼──────────────────────────────┼─────────┤
│docker.io/library/elasticsearch:8.13.0                   │Patch update (8.13.0 → 8.13.4)│730      │
│docker.io/library/memcached:1.6.18                       │Patch update (1.6.18 → 1.6.38)│268      │
│ghcr.io/sergi0g/cup:latest                               │Update available              │291      │
│docker.io/gitea/gitea:latest                             │Up to date                    │752      │
╰─────────────────────────────────────────────────────────┴──────────────────────────────┴─────────╯

Pin patch updates:

╭─────────────────────────────────────────────────────────┬────────────────┬─────────╮
│Reference                                                │Status          │Time (ms)│
├─────────────────────────────────────────────────────────┼────────────────┼─────────┤
│ghcr.io/sergi0g/cup:latest                               │Update available│299      │
│docker.io/gitea/gitea:latest                             │Up to date      │726      │
╰─────────────────────────────────────────────────────────┴────────────────┴─────────╯

I am open to a different configuration name, as I'm not sure that pin is necessarily the most descriptive. Please also let me know if you prefer an alternative implementation; this was just what fit my use-case the best.

[sergi0g]

Awesome work @seowalex! This looks like the cleanest way to implement this. The only thing I don't really like is the name of the option. It probably isn't the most descriptive and I'd also rather avoid defining a struct with the same name as a standard library struct/type/whatever it is (I still don't know how to use it 🤣). Maybe it would be better if it were named something more descriptive, although I'll admit that I don't have very good ideas (keep_update_type? max_update_type? or maybe negate it and say ignore_update_type). I really hope you have better suggestions. 😂

Also, one more thing: if you're familiar with JSON schema, could you please update the config file schema (cup.schema.json in the root of the project)? If you don't want to, it's totally fine, I can do it myself after I merge as well.

Thanks for the PR! (and sorry for the lengthy response)

[seowalex]

Hi @sergi0g, apologies for the delayed reply. I agree that Pin is not a good name for an enum due to Rust's stdlib Pin, but I do like the word "pin" as I think it is commonly used in relation to versions to describe what is occuring here (for e.g., https://conda-forge.org/docs/maintainer/pinning_deps/).

Can I suggest:

• Let the setting be called version_pinning (and the enum called VersionPin or PinVersion) with the following options:
  • None
  • major
  • minor
  • patch

Let me know what you think!

[sergi0g]

Hey,
version_pinning does indeed sound better. I still think it's wrong, since the user is the one pinning an image to a version in their compose/whatever and Cup merely ignores updates, but let's continue. There are countless other things I hate in this codebase anyway. This is not worth fighting over (this may sound mean, we're not fighting and I can't find a better word to describe this). So we'll stick to version_pinning.

Another thing I was thinking about is that users would probably want to override this option on some images, so another option would have to be added.

I don't want to pressure you to do more work. You can leave this PR here if you want to and I'll merge and continue. It's up to you.
Thanks again!

[seowalex]

since the user is the one pinning an image to a version in their compose/whatever and Cup merely ignores updates

I think this is an excellent point, and I think you've changed my mind. Shall we settle on ignore_update_type, with options:

• none: Do not ignore updates.
• major: Ignore major updates
• minor: Ignore minor updates (which also implicitly ignores major updates).
• patch: Ignore patch updates (which also implicitly ignores major/minor updates).

As for overriding this option on images, I agree that would be useful. Do you think that these overrides should live under the "images" setting, or under this setting?

[sergi0g]

Sounds good!

Do you think that these overrides should live under the "images" setting, or under this setting?

images is probably a better choice. However, with the current config file format, it won't look clean. I'd suggest just keeping the PR as it is (just make the naming changes suggested). Per-image overrides can be added in version 4, where the config file scheme will be improved (again).

[seowalex]

As discussed, I have changed the setting to ignore_update_type, and have also added documentation. Please let me know if anything else remains.

(As a side note, contributing to Cup has been an extremely positive experience, keep up the good work!)

[sergi0g]

Awesome! I'm merging this!

[sergi0g]

Congratulations on your second contribution!

(As a side note, contributing to Cup has been an extremely positive experience, keep up the good work!)

Really? I wonder what I'm doing correctly. 😂

By the way, since I finally found someone knowing better Rust than me and willing to contribute, if you have any ideas on how to clean up and/or optimize the code, I'd love to hear them!

Thanks!