⬆️ Upgrade and pin portainer/minio/registry versions

[mrnicegyu11]

What do these changes do?

⬆️ Upgrade and pin portainer/minio/registry versions

Sister-PR to ITISFoundation/osparc-ops-environments#738

Related PRs

ITISFoundation/osparc-ops-environments#738

Dev-ops checklist

• No ENV changes or I properly updated ENV (read the instruction)

[sanderegg]

Why do you fix this? These are not used in ops are they? They are dev only compose files

[mrnicegyu11]

Why do you fix this? These are not used in ops are they? They are dev only compose files

Only reason: Pedro has explicitly suggested it... I probably understood wrongly what was meant with "pinning everywhere". I personally saw some benefit if simcore-devs run the same things that are in the ops stack as well.

no problem I can revert.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 78.5%. Comparing base (cafbf96) to head (3929b2d).
Report is 461 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##           master   #6185      +/-   ##
=========================================
- Coverage    84.5%   78.5%    -6.0%     
=========================================
  Files          10    1103    +1093     
  Lines         214   45339   +45125     
  Branches       25     768     +743     
=========================================
+ Hits          181   35632   +35451     
- Misses         23    9552    +9529     
- Partials       10     155     +145     

Flag	Coverage Δ
unittests	78.5% <ø> (-6.0%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

see 1059 files with indirect coverage changes

[pcrespov]

As @sanderegg mentioned, these are not used in the ops stack directly, but they represent what the simcore stack will encounter when deployed alongside the ops stack.

Suggestions:

1. Version/Tag Management:

   • Pin down specific versions or tags, and if possible, include the SHA for better traceability.
   • Ensure that the versions/tags in the ops and simcore stacks are synchronized. This can be achieved by:
     • Implementing a test in a location with access to both repositories, or (preferred approach)
     • Adding a prominent reminder note in both repositories to maintain synchronization.

2. Considerations for Un-pinned Versions:

   • There are valid reasons to leave versions un-pinned, such as testing whether the latest versions work as expected before deploying to production. This is a strategy we already use with Python dependencies in our libraries (e.g., the packages folder).

[mrnicegyu11]

@sanderegg

Pedro commented and approved, not sure what to do now. Please let me know whether I should pin or unpin, and if you prefer pinning let me know if it is ok to add the SHAs as asked by Pedro. I am actually completely agnostic to this and do not want to debate it :D I am pretty much doing this as it was requested from us to do it. Just let me know how you guys prefer it, thanks.

What I would not want to do is introduce tests to assure that everything between the 2 repos, simcore and ops, is tightly coupled w.r.t. versioning. It is a lot of work to make these tests robust and I feel like the resulting advantages do not warrant the developers' time. These tests would be easier to implement in a monorepo, there I would see the point, but not for separated repositories.

[sanderegg]

@sanderegg

Pedro commented and approved, not sure what to do now. Please let me know whether I should pin or unpin, and if you prefer pinning let me know if it is ok to add the SHAs as asked by Pedro. I am actually completely agnostic to this and do not want to debate it :D I am pretty much doing this as it was requested from us to do it. Just let me know how you guys prefer it, thanks.

What I would not want to do is introduce tests to assure that everything between the 2 repos, simcore and ops, is tightly coupled w.r.t. versioning. It is a lot of work to make these tests robust and I feel like the resulting advantages do not warrant the developers' time. These tests would be easier to implement in a monorepo, there I would see the point, but not for separated repositories.

@mrnicegyu11 @pcrespov let's discuss that off line if this is a problem.

• we do not use minio in deployments, so that point does not apply
• if we pin the versions then we lose the information when new version will break the system before these are applied in ops
• I agree with @mrnicegyu11 that adding tests for this is a big hassle and will create a linking between ops and simcore that I don't see as beneficial and with little return of investment
• until now this never created any issue.
  --> these are my points, now I don't have a strong opinion for this stuff. go with what you have.

[mrnicegyu11]

it is absolutely fine for me to close this PR and leave the dependencies always on the latest upstream version.

Please indicate if this is fine for you as well @pcrespov