<div dir="ltr"><div class="gmail_default" style="font-family:arial,sans-serif">Hi,<br><br>might have some additional questions and remarks regarding the git workflow that you want us to use:<br><br>1. One of the ways to develop is to have so-called feature branches - the problem with those is commits can add up and to keep master clean after merging the pull request (or merge request on GitLab) you should squash the commits but that is messing with the history if multiple people committed to the feature branch (I don't think it does on GitHub but on GitLab, I think I saw it happening). How should we deal with that? Should we use squash or does it impact the grading script? (Depending on the answer I might need to contact you separately and solve some issues with points).<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-family:Arial,Helvetica,sans-serif">It is a good practice to always commit code that compiles. For</span><br style="font-family:Arial,Helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">master/main branch, the rule is usually to commit code that compiles and</span><br style="font-family:Arial,Helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">passes the tests.</span>  <br></blockquote><div class="gmail_default" style="font-family:arial,sans-serif">In this case, this means completing the task - which doesn't go hand in hand with the fact that you are trying to get us to collaborate and "work as a team in a real company" (or at least that's what I felt like) - I wouldn't be able to reasonably share code with my colleagues - there are ways to get around this by having let's say a02-master and we all branch from there but that might be problematic again when it comes to what I mentioned above - squash on merge and the change of author when used.<br></div><div class="gmail_default" style="font-family:arial,sans-serif"><br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-family:Arial,Helvetica,sans-serif">As a matter of fact, if you commit/push every minute to debug your</span><br style="font-family:Arial,Helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">knowledge of C syntax and/or for every word in one code comment, two</span><br style="font-family:Arial,Helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">things may happen. We may consider this as a gaming of the activity</span><br style="font-family:Arial,Helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">points. And we might be forced to setup some type of accounting for the</span><br style="font-family:Arial,Helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">use of CI to ensure fairness (I already received a complaint from GitLab</span><br style="font-family:Arial,Helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">administrator about overloading the CI machines).</span>  <br></blockquote><div>Is there a way to set up the CI so that doesn't build before opening a PR or that it cancels the previous pipeline if a new commit is made? That is the approach that is used in the company I work for to prevent what we are encountering here. At least on the feature branches - master should always run with each commit/merge given the small team size - there is also the option to make the build periodical if there were changes in the last X amount of time.<br><br>Mostly my comments come from a place of<br>a) interest and previous experience with some GitHub workflows - from what I see the unit of work in your opinion should be a commit which in my opinion is not easily accessible given the nature of the task and the need to collaborate - I am used to using a PR as a unit of work which would probably require some changes in the CI pipeline.<br>And also b) slight frustration because I am one of the ones that were probably overloading the GitLab machines (although I tried to minimize it once I had a look at the queue, saw what was happening, and was canceling some runs manually) - but the reason for it was that the instructions on how to reproduce the dev environment on a local Linux VM were not enough for me to successfully do it so I develop on a feature branch in the mentioned VM which gives me more freedom when it comes to reasonable IDE etc, push whenever I want to because I will open a PR and squash anyway, and then pull the branch on a Rotunda machine and debug and test there. The CI run results are not really what interests me at that point but they run every time (hence my comments about automatic cancellation on a new commit) and when I included some printing the logs were getting out of hand (which is probably where most of the pressure on the GitLab CI machine comes from - the amount of logs generated).<br><br></div></div>Looking forward to your reply hoping it will bring more clarity so I can adjust and prevent future problems of this nature.<br><br>Regards</div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div><span style="font-size:12.8px"><font face="monospace, monospace">Lukáš Bastián</font></span><br></div></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 9, 2020 at 7:07 AM Vojtech Horky <<a href="mailto:horky@d3s.mff.cuni.cz">horky@d3s.mff.cuni.cz</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">Hello,<br>
<br>
just few notes in no particular ordering.<br>
<br>
It is possible to setup your Git commit identity (e-mail) in GitLab <br>
instead of the default one.<br>
<br>
When you are using Git for the first time on a given machine (e.g. <br>
<a href="http://lab.d3s.mff.cuni.cz" rel="noreferrer" target="_blank">lab.d3s.mff.cuni.cz</a> or Rotunda servers), you should set your Git name <br>
and e-mail via "git config" command (probably with the --global switch). <br>
Note that Git will warn you during every commit that you have not done so.<br>
<br>
It is a good practice to always commit code that compiles. For <br>
master/main branch, the rule is usually to commit code that compiles and <br>
passes the tests.<br>
<br>
GitLab CI is not your development environment. You are supposed to <br>
develop, debug and test on your machine and push to GitLab only <br>
reasonable commits. There is no reason to push every single commit to <br>
GitLab to see whether it compiles.<br>
<br>
As a matter of fact, if you commit/push every minute to debug your <br>
knowledge of C syntax and/or for every word in one code comment, two <br>
things may happen. We may consider this as a gaming of the activity <br>
points. And we might be forced to setup some type of accounting for the <br>
use of CI to ensure fairness (I already received a complaint from GitLab <br>
administrator about overloading the CI machines).<br>
<br>
Note that it is completely fine and highly recommended to create very <br>
small, focused commits but each commit should represent a <br>
compact/logical/atomic change of your project. Think always about a <br>
reviewer that clicks on your commit - are there only changes related to <br>
the topic and are there all the changes related to the topic?<br>
<br>
Note that "git add -p" allows you to split big change into multiple <br>
commits quite easily.<br>
<br>
As a further reading, I would recommend [1] about good commit messages <br>
and perhaps [2] as well as it reiterates some notes about committing in <br>
general.<br>
<br>
[1] <a href="https://chris.beams.io/posts/git-commit/" rel="noreferrer" target="_blank">https://chris.beams.io/posts/git-commit/</a><br>
[2] <br>
<a href="https://koukia.ca/git-some-commit-best-practices-and-how-to-undo-your-recent-commits-d13c9dc3144f" rel="noreferrer" target="_blank">https://koukia.ca/git-some-commit-best-practices-and-how-to-undo-your-recent-commits-d13c9dc3144f</a><br>
<br>
Hope this helps,<br>
- VH<br>
_______________________________________________<br>
NSWI004 mailing list<br>
<a href="mailto:NSWI004@d3s.mff.cuni.cz" target="_blank">NSWI004@d3s.mff.cuni.cz</a><br>
<a href="https://d3s.mff.cuni.cz/mailman/listinfo/nswi004" rel="noreferrer" target="_blank">https://d3s.mff.cuni.cz/mailman/listinfo/nswi004</a><br>
</blockquote></div>