[MISC] Stop tracking channel for held snaps

[dragomirp]

Remove tracking of snap channel for the charmed-postgresql snap

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 74.50%. Comparing base (d973b19) to head (6884459).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #384   +/-   ##
=======================================
  Coverage   74.50%   74.50%           
=======================================
  Files           9        9           
  Lines        1322     1322           
  Branches      228      228           
=======================================
  Hits          985      985           
  Misses        262      262           
  Partials       75       75           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[lucasgameiroborges]

Huh, just realized this is going to break the automation for pinning snap revs in bundles :(

Question: Will the channel be specified anywhere else in the charm code? Will there be any other "source of truth" for the channel of the snap? Wondering if I can avoid hard-coding it in the workflow.

[dragomirp]

Question: Will the channel be specified anywhere else in the charm code? Will there be any other "source of truth" for the channel of the snap? Wondering if I can avoid hard-coding it in the workflow.

Technically the channel stated is wrong, there's no revisions in it ATM. We can set the correct risk (14/edge and 1/edge), but then we can't change it when releasing a charm revision to stable. Is the revision itself not enough for store pinning to work?

[taurus-forever]

Huh, just realized this is going to break the automation for pinning snap revs in bundles :(

Follow MySQL approach for now: https://github.com/canonical/data-platform-workflows/blob/main/python/cli/data_platform_workflows_cli/update_bundle.py#L121