<div dir="ltr">I'm a big fan of #3 :-)<div><br></div><div>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).</div><div><br></div><div>I also had to comment out lines 85-92 of astyle.sh, as they made the script not find astyle.</div><div><br></div><div>About improving tools, I've never tried it, but heard positively of <a href="https://pre-commit.com/">https://pre-commit.com/</a> 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).</div><div><br></div><div>Cheers,</div><div><br></div><div>Olivier</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 20 Nov 2020 at 14:58, DelazJ <<a href="mailto:delazj@gmail.com">delazj@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>While looking for some scripts to automate processes in the doc repo, I came across this github action (<a href="https://github.com/marketplace/actions/git-auto-commit" target="_blank">https://github.com/marketplace/actions/git-auto-commit</a>) that basically updates a branch based on modifications done in that branch or in another one. <br></div><div> 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).</div><div>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.</div><div><br></div><div>Just wanted to share</div><div><br></div><div>Regards,</div><div>Harrissou<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 29 oct. 2020 à 23:52, Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 30 Oct 2020 at 08:48, Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>> wrote:<br>
><br>
> On Wed, 28 Oct 2020 at 23:34, C Hamilton <<a href="mailto:adenaculture@gmail.com" target="_blank">adenaculture@gmail.com</a>> wrote:<br>
> ><br>
> > I tried submitting my first QGIS core code submission. See<br>
> ><br>
> > <a href="https://github.com/qgis/QGIS/pull/39655" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/pull/39655</a><br>
> ><br>
> > 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.<br>
> ><br>
> > 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.<br>
> ><br>
> > 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?<br>
><br>
> Yes -- there's two options:<br>
><br>
> 1. (more hassle in the long run) Use cygwin and run the scripts<br>
> through that. Make sure that you have the "with_astyle" cmake option<br>
> enabled in your build too! Cygwin is easy to install, but it will be a<br>
> pain to find all the required dependancies for the prepare commit<br>
> script (e..g you'll need to get the perl packages)<br>
><br>
> 2. (harder initially, less hassle in the long run) Install WSL and a<br>
> Ubuntu release through that. Run the prepare commit script inside the<br>
> Ubuntu shell. WSL takes a through hoops to install, but there's good<br>
> guides out there. After you have the Ubuntu shell available it's easy<br>
> to install all the required pacakges for the QGIS prepare commit<br>
> scripts.<br>
<br>
Oh, there's also shitty option #3:<br>
<br>
3. Push your branch to github and find out what you need to change<br>
through the failing tests. Manually make these changes to files.<br>
Repeat.<br>
<br>
Don't do 3. It's painful for you, painful for all the other devs (who<br>
have to wait while your string of commits are run through the ci<br>
before other PRs will get a chance), and it's **incredibly**<br>
environmentally insensitive. Think of all the wasted CPU cycles and<br>
the carbon cost of this approach!<br>
<br>
Push through the hurdles and you'll find 1 or 2 works, and then you'll<br>
never have to deal with the frustration of a development process based<br>
on the third approach ;)<br>
<br>
Nyall<br>
<br>
<br>
<br>
><br>
> Personally when I'm doing dev on windows I always use the WSL ubuntu<br>
> shell now, as it makes git/etc easier to use anyway!<br>
><br>
> Nyall<br>
><br>
><br>
><br>
> ><br>
> > How have you set up your QGIS development environment?<br>
> ><br>
> > 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.<br>
> ><br>
> > Thanks,<br>
> ><br>
> > Calvin<br>
> > _______________________________________________<br>
> > QGIS-Developer mailing list<br>
> > <a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
> > List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
> > Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div>