I moved this to the #snapd category because I think your issue speaks to a larger design question about the refresh-control/gating features.
If I’m understanding the request here, you want to be able to build an image with snaps that also follows the restrictions enforced by refresh-control/gating. I don’t think that the refresh-control features were designed with this use-case in mind, but that being said I think that you might be able to work around this issue by trying a workaround:
- on your build machine, login to snapd with
snap loginusing an account that has access to the brand store - confirm that your build machine follows the same refresh-control / gating logic as what you expect on the device
- install ubuntu-image and try to build your image
- check that the image has the right snap revisions
I don’t know if this will work, since what ubuntu-image uses to assemble the image + snaps is snap prepare-image, and it’s not totally obvious to me that the prepare-image uses the same codepath that the refresh logic does to determine which revisions to use. It very well might not use the same codepath and may not work.
All that being said, I think that snap cohorts may be a better fit to this, but I don’t think ubuntu-image or snap prepare-image have been updated to use cohorts the same way that snap download and snap refresh have (see Managing cohorts). It’s also unclear to me how cohorts interact with refresh-control. 