Auto connect / alias request for mob-sh

Hi,

mob-sh is git wrapper for remote mob programming.

It requires connections for gitconfig and ssh-keys to be able to use git properly.
Its users are used to run ‘mob’ instead of ‘mob-sh’ when using it. Sadly, our request to register the snap-name ‘mob’ was denied, as it seems to be to short.

I would therefore request

  1. auto-connection for gitconfig (personal-files)
  2. auto-connection for ssh-keys
  3. automatic alias creation from mob-sh to mob

Thanks and best regards
Nikolas

@review-team Is there any additional Info I need to provide?

@nikolas-hermann hey, apologize for the delay. The information provided is fine.

+1 for me for auto-connect personal-files with read access to $HOME/.gitconfig and $HOME/.config/git/config as defined in mob-sh snapcraft.yaml:

plugs:
  gitconfig:
    interface: personal-files
    read:
    - $HOME/.gitconfig
    - $HOME/.config/git/config

I was about to suggest we could rework a bit this interface reference to meet the usual requirements for this to be e.g dot-gitconfig as specified in the iface doc but I found we have granted other snaps the auto-connection for this exact same declaration, @alexmurray could you please comment?

I am +1 as well for auto-connect ssh-keys to mob-sh since this (as well as the above) are both clearly required for an app which is a git wrapper.

Finally I am +1 for granting the mob alias to mob-sh.

Can other @reviewers please vote?

Regarding the interface name, if this were just for the single .gitconfig file then the best name would be dot-gitconfig but since we are also granting for .config/git/config then the more generic name of gitconfig is better (plus there is a lot of precedent for this for other snaps too).

+1 for me to auto-connect this personal-files instance and for the mobalias for mob-sh

-1 for auto-connect of ssh-keys - this is a very privileged interface and I think the user’s voice is important to be aware of connecting this as it provides access to private keys etc. As such I think this should be manually connected (I realise this is a very common use-case for git to sign commits and hence need access to private keys but this can probably be done tastefully by trying to detect whether this is connected via snapctl is-connected ssh-keys and then prompting the user to perform the connection if desired).

+2 votes for, 0 votes against, granting auto-connect of personal-files with read access to $HOME/.gitconfig and $HOME/.config/git/config using the interface reference gitconfig. This is now live. @nikolas-hermann could you please either request a new review or upload a new revision so the changes take effect?

+2 votes for, 0 votes against, granting the requested auto-alias mob to mob-sh

+1 votes for, +1 votes against, not grating auto-connect of ssh-keys to mob-sh this time.

I’ll also chime in and say -1 for ssh-keys for the reasons Alex gave.

The manual connection for ssh-keys works fine for us.
Thank you all the review!

@review-team We need to request another auto-connection for personal-files.
dot-gitignore is requested to allow access to $HOME/.gitignore and $HOME/.gitignore_global, which are common paths to store global .gitignore-files and expected to work by git-users.
Could you please review revision 8 of https://snapcraft.io/mob-sh ?

+1 from me for auto-connect of personal-files with read access to $HOME/.gitignore using the interface reference dot-gitignore since this is also a common git related configuration. Can other @reviewers please vote?

+1 from me for auto-connect of personal-files with read access to $HOME/.gitignore.

+2 votes for, 0 votes against, granted auto-connect of personal-files with read access to $HOME/.gitignore using the interface reference dot-gitignore. This is now live.

I upload a new revision (9) with a personal-files plug for to $HOME/.gitignore and $HOME/.gitignore_global, as requested above:

  dot-gitignore:
    interface: personal-files
    read:
      - $HOME/.gitignore
      - $HOME/.gitignore_global

The automatic review got rejected again.
How should I proceed?

Ahh that was rejected because we only granted access to ~/.gitignore - so by including ~/.gitignore_global as well this doesn’t match and hence gets rejected. I notice no-one voted on this but I assume that is an oversight - I have just updated the snap declaration to include ~/.gitignore_global as well and this now passes automated review.

Thank you :slight_smile: