Le 28/10/2018 à 09:47, Xavier a écrit : > Le 28/10/2018 à 08:43, Xavier a écrit : >> Le 27/10/2018 à 14:24, Xavier a écrit : >>> Le 25/10/2018 à 11:33, Raphael Hertzog a écrit : >>>> Hi, >>> >>> Hello, >>> >>>> On Fri, 19 Oct 2018, Xavier wrote: >>>>> first version of salsa script is ready to review. Documentation is here: >>>>> https://salsa.debian.org/yadd/devscripts/blob/devscripts-salsa-890594/scripts/salsa.pl >>>> >>>> Thanks for working on this! >>> >>> You're welcome ;-) >>> >>>> My first comment is that we should not have to work with numerical >>>> identifiers. I want to modify the group "pkg-security-team" and not >>>> the team-id 1234. The tool should do the lookup for me. I don't have to >>>> know internal identifiers. >>> >>> Fixed: you can use --group. If more than one group has this name, you'll >>> be invited to use --group-id (results are displayed on this error). >>> >>> I added a cache file to minimize Gitlab queries (with a purge_cache >>> command). Default to ~/.cache/salsa.json >>> >>>> Furthermore "team-id" is really not consistent with the the gitlab >>>> vocabulary. They use "group id". >>> >>> Fixed: team and group is now equivalent (commands and options) >>> >>>>> - manage repos >>>> >>>> The set of commands that you propose are really tailored to the current >>>> hooks that we are using. This is convenient to use but it is not >>>> future-proof. I would rather have a configuration file describing all >>>> parameters that we want to see configured and be able to pass that >>>> configuration file to the tool. >>> >>> I'm going to add a --conf-file for this >> >> Done >> >>>> I would love also if the tool could enforce things like: >>>> - rename "master" into "debian/master" (when debian/master doesn't exist) >> >> I don't understand this proposition. > > This is the last point to do but I need to understand it.
Mattia explained me dep14. I found a way to do it: create branch from master, update project to set default_branch to debian/master then remove master. It works as expected. $ salsa update_repo node-mongodb --group js-team --rename-head $ salsa update_repo --all --rename-head --no-fail # all user projects Manpage updated: https://salsa.debian.org/yadd/devscripts/blob/devscripts-salsa-890594/scripts/salsa.pl#L339 >>>> - define protected branches (including the possibility to disable all >>>> protections) >> >> This is my next step ;-) > > Done > >>>>> Of course, most of options can be set in ~/.devscripts. Example: >>>>> >>>>> SALSA_KGB=yes >>>>> SALSA_IRC_CHANNEL=debian-perl >>>>> SALSA_TEAM_ID=2665 >>>>> SALSA_DESC=yes >>>>> SALSA_DESC_PATTERN="Perl team package %p" >>>>> SALSA_TOKEN=abcdef >>>> >>>> This looks like a misfeature. It's too easy to forget about those and >>>> apply unwanted settings to other repositories. >>> >>> I'm going to add a --conf-file for this >> >> Done >> >>>> Only SALSA_TOKEN is fine (and even there, this is private data and it >>>> might be better handled through some other mechanism?). >>> >>> Fixed, you can choose SALSA_TOKEN or SALSA_TOKEN_FILE or --token or >>> --token-file >>> >>>>> QUESTION 1: is "salsa" a good name? >>>> >>>> Something more explicit would be better. I'm not good at names. Maybe >>>> "debsalsa" or "salsa-configure". But then it could be designed as a >>>> generic gitlab configuration tool and you could entirely avoid the salsa >>>> marker in the name... >>> >>> gitlab-cfg ? Is it a good idea to ask to debian-devel@l.d.o ? >>> >>>>> QUESTION 2: I think --all should fail unless current user is owner, >>>>> isn't it? >>>> >>>> You might want to have some interactive confirmation. "You are about to >>>> modify the configuration of 245 repositories. Do you want to continue ?". >>>> >>>> But otherwise I don't think that you need to handle any access control, >>>> let gitlab take care of this part. >>> >>> Fixed: question unless --yes >>> >>>> Cheers, >>> >>> Regards, >>> Xavier >
