I'm a big fan of #3 :-) One gotcha with #2 is if you're working in the Windows filesystem, but run prepare_commit.sh with WSL, you need to make sure the prepare_commit runs with git.exe, and not WSL's git, as otherwise it can be extremely slow (so much that the hook is unusable). In my case I had to change prepare_commit.sh lines ~54-56 for that (replace git by git.exe).
I also had to comment out lines 85-92 of astyle.sh, as they made the script not find astyle. About improving tools, I've never tried it, but heard positively of https://pre-commit.com/ which could be worth investigating for a potentially nicer and more cross-platform pre-commit ? I feel it's still a better approach to run those locally than on github (we'd start to have PR on PRs, which is a bit hard to follow). Cheers, Olivier On Fri, 20 Nov 2020 at 14:58, DelazJ <[email protected]> wrote: > Hi, > > While looking for some scripts to automate processes in the doc repo, I > came across this github action ( > https://github.com/marketplace/actions/git-auto-commit) that basically > updates a branch based on modifications done in that branch or in another > one. > We currently have github actions that check and report wrong styling, > wrong indentation, missing sip doc, spell checks... And I was wondering > whether it would make sense to go one step further and at the end of the > check either open a PR in the fork repo or push the expected changes in the > branch opening the PR. Maybe this could also be actions people would run in > their own repo before opening the PR (I don't know how possible it's). > This will probably help people that fail to have the ideal development > environment locally (never succeeded on Windows) or that use the github > editor to have these "secondary" but really annoying issues covered easily. > > Just wanted to share > > Regards, > Harrissou > > Le jeu. 29 oct. 2020 à 23:52, Nyall Dawson <[email protected]> a > écrit : > >> On Fri, 30 Oct 2020 at 08:48, Nyall Dawson <[email protected]> >> wrote: >> > >> > On Wed, 28 Oct 2020 at 23:34, C Hamilton <[email protected]> >> wrote: >> > > >> > > I tried submitting my first QGIS core code submission. See >> > > >> > > https://github.com/qgis/QGIS/pull/39655 >> > > >> > > As I was doing the pull request I found out that there were some >> scripts that should have been run to check the coding style. Unfortunately, >> those scripts are .sh scripts and I chose to develop on Windows using >> Visual Studio and as far as I know there isn't a way to run the scripts. >> > > >> > > I am on windows, but would I be better off to use something like >> virtualbox and create a virtual linux development environment? I'm not as >> good with linux because I haven't used it for over 10 years. >> > > >> > > Is there still a way for me to use the Windows development >> environment, yet make sure I'm able to run all the required scripts to do >> the checks? >> > >> > Yes -- there's two options: >> > >> > 1. (more hassle in the long run) Use cygwin and run the scripts >> > through that. Make sure that you have the "with_astyle" cmake option >> > enabled in your build too! Cygwin is easy to install, but it will be a >> > pain to find all the required dependancies for the prepare commit >> > script (e..g you'll need to get the perl packages) >> > >> > 2. (harder initially, less hassle in the long run) Install WSL and a >> > Ubuntu release through that. Run the prepare commit script inside the >> > Ubuntu shell. WSL takes a through hoops to install, but there's good >> > guides out there. After you have the Ubuntu shell available it's easy >> > to install all the required pacakges for the QGIS prepare commit >> > scripts. >> >> Oh, there's also shitty option #3: >> >> 3. Push your branch to github and find out what you need to change >> through the failing tests. Manually make these changes to files. >> Repeat. >> >> Don't do 3. It's painful for you, painful for all the other devs (who >> have to wait while your string of commits are run through the ci >> before other PRs will get a chance), and it's **incredibly** >> environmentally insensitive. Think of all the wasted CPU cycles and >> the carbon cost of this approach! >> >> Push through the hurdles and you'll find 1 or 2 works, and then you'll >> never have to deal with the frustration of a development process based >> on the third approach ;) >> >> Nyall >> >> >> >> > >> > Personally when I'm doing dev on windows I always use the WSL ubuntu >> > shell now, as it makes git/etc easier to use anyway! >> > >> > Nyall >> > >> > >> > >> > > >> > > How have you set up your QGIS development environment? >> > > >> > > My code submission got a red flag with indentation so before I do >> anything more I really need to figure out the best workflow for doing >> development. >> > > >> > > Thanks, >> > > >> > > Calvin >> > > _______________________________________________ >> > > QGIS-Developer mailing list >> > > [email protected] >> > > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> > > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> _______________________________________________ >> QGIS-Developer mailing list >> [email protected] >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > > _______________________________________________ > QGIS-Developer mailing list > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
