Hugo can deploy a published website to a Google Cloud Storage (GCS) bucket, an AWS S3 bucket, and/or an Azure Storage container. To do so, it needs access to the relevant credentials.
Hi @jmooring,
hugo snap requires to access these files to perform mentioned operations, +1 from me to give personal-file interface on these cred files but since Hugo is no the owner of these dirs, I would suggest to grant the mentioned interface without auto-connect.
Thanks, but I am going to politely push back. The Hugo snap has already been granted classic confinement, indicating trust. We would prefer to auto-connect and remain under strict confinement as long as possible.
@jmooring whilst I tend to agree that the existing classic confinement granted to hugo makes this concept a bit redundant from a trust / permissions issue, I have one suggestion.
If this were manually connected, would it be possible to try and detect if this were connected (via snapctl is-connected dot-aws etc) at the time this access is needed - and if not prompt the user to manually connect the plug (through the use of zenity or similar)?
Think of Hugo as a compiler that is used in two modes: attended (i.e., human types the command) and unattended (i.e., part of a build chain in CI/CD environments).
@jmooring - indeed, I had thought this might be the case - thanks for the clarification. +1 from me for use of and auto-connect of personal-files instances dot-aws, dot-azure and dot-config-gcloud providing read access as specified above.
Hi @jmooring. Nothing else is required, thank you!
Given we’ve previously granted classic, and the reasons you’ve outlined above, +1 from me on the use of personal-fileswith auto-connect for dot-aws, dot-azure and dot-config-gcloud read access. Votes will be tallied and this will be completed at the end of the voting period.
+3 votes for granting read access to dot-aws, dot-azure and dot-config-gcloud, with 2 also in favour of auto-connect for those interfaces. This is now live.