mirror of
https://github.com/mfocko/blog.git
synced 2024-11-13 01:30:29 +01:00
fix(pb161): update the environment
* remove no longer relevant parts * reviews via MRs (not possible, they're randomly assigned) * using git as a backup to submitted sources (they are uploaded to IS) * mention VSCode on aisa * mention commit conventions * mention formatting git hook Signed-off-by: Matej Focko <mfocko@redhat.com>
This commit is contained in:
parent
ab6868fa45
commit
02f1c94754
1 changed files with 34 additions and 21 deletions
|
@ -11,6 +11,18 @@ description: |
|
|||
Most likely WSL, VM or VPS. If you consider setting up either of those PITA, then
|
||||
VSCode + SSH to _aisa_ might be the best option for you.
|
||||
|
||||
:::caution VSCode @ aisa
|
||||
|
||||
Be careful when using VSCode on aisa, most notably:
|
||||
|
||||
1. VSCode can leave lingering processes running in the background that can „eat
|
||||
up“ your quota for running processes.
|
||||
AFAIK UNIX team has implemented some periodic clean up of those.
|
||||
2. Disk quota can be also affected, because of the C/C++ extension toolkit that
|
||||
has a cache for IntelliSense.
|
||||
|
||||
:::
|
||||
|
||||
Either of those will be linux distros, so jump to [next section](#linux).
|
||||
|
||||
### Linux
|
||||
|
@ -72,12 +84,6 @@ to the JetBrains IDEs.
|
|||
I recommend you using some basic versioning for your code, even though you submit
|
||||
only the sources on _aisa_. There are specific reasons why I suggest it:
|
||||
|
||||
- once you submit the sources for evaluation, there is no way of getting previous
|
||||
submissions
|
||||
|
||||
i.e. if you introduce new bugs between submissions, you cannot compare two of
|
||||
them to pinpoint the bug, this can be easily resolved by _git tags_
|
||||
|
||||
- if you build a _commit, tag and submit_ habit, you might be able to address
|
||||
some of the smaller problems in your sources even before submission; more info
|
||||
in the [pre-commit section](#pre-commit)
|
||||
|
@ -88,23 +94,18 @@ skeletons on your default branch, since _frag_ on _aisa_ automatically downloads
|
|||
everything that is not present and by that can create conflicts when switching
|
||||
branches.
|
||||
|
||||
:::tip Commit conventions
|
||||
|
||||
When creating smaller and well defined commits, you can more easily argue about
|
||||
correctness of your implementation and also identify bugs, since they are better
|
||||
contained.
|
||||
|
||||
:::
|
||||
|
||||
Since frag creates a lot of support files (majority of them are dotfiles, i.e.
|
||||
hidden files), I recommend you to use following
|
||||
[gitignore](/files/pb161/environment/gitignore) configuration that should cover most of
|
||||
the scenarios.
|
||||
|
||||
### Reviews on merge requests
|
||||
|
||||
It might be harder to resolve, explain and/or address notes from the review if you
|
||||
get back your source code with notes all over the place, to help with this I offer
|
||||
you reviews on merge requests in GitLab.
|
||||
|
||||
It allows me to comment on your source code with an option for you to reply, so
|
||||
that we can clear any misunderstandings and vague comments if they arise.
|
||||
|
||||
Since I expect most of you to not require this, it might take some time for me
|
||||
to implement tool that would allow it, since the reviews shall be still submitted
|
||||
through _aisa_.
|
||||
[gitignore](pathname:///files/pb161/environment/gitignore) configuration that
|
||||
should cover most of the scenarios.
|
||||
|
||||
### pre-commit ([link](https://pre-commit.com/))
|
||||
|
||||
|
@ -125,6 +126,18 @@ list of supported ones on the page), but there is also an option for you setting
|
|||
it up yourself (it is just a matter of specifying command and files it should run
|
||||
on).
|
||||
|
||||
:::tip Formatting
|
||||
|
||||
For formatting you can the following [git hook](https://github.com/pre-commit/mirrors-clang-format#using-clang-format-with-pre-commit).
|
||||
|
||||
This hook follows the formatting conventions defined by the `.clang-format` file
|
||||
that is looked up recursively all the way to the root of the filesystem, therefore
|
||||
it is ideal to keep it in the root of the git repository.
|
||||
|
||||
You can look up the different codestyles [here](https://gitlab.fi.muni.cz/pb071/codestyles).
|
||||
|
||||
:::
|
||||
|
||||
## Testing
|
||||
|
||||
I have tried 2 frameworks for testing, one of them will be probably showcased in
|
||||
|
|
Loading…
Reference in a new issue