api-playground VS observability

GitLab team member here.

Maybe you can re-use the script I shared in this comment [0] to query the GitLab REST API to generate an index. I'm a fan of using the API programmatically, and tend to avoid git checkout/grep/etc. inside CI/CD pipelines (works too, everyone is free to choose their way).

Yet again, I love API challenges, so I've created a new script which parses a defined markdown footer for Tags and Due date, and generates an ordered index by due date. I did not know which format you are using, so I made up my own, see the MR description [1] and docs [2].

The script lives in [3] and is a mix of fetching files, parsing content with regex, and generating the index + creating a commit to upload automatically.

A demo overview is shown in [4] with the generated index.md, ordered by due date and linking the files by parsed heading title, file paths, and tags.

Hope it helps, feel free to repurpose, or ping me for questions on the GitLab community forum [5]. My Python code is a little rusty, I am slowly adopting all the 3.x design patterns after many years with 2.x.

I might follow your idea with notes and custom footer parsing. That's a really nifty idea, and helps solve my own chaos :-)

[0] https://news.ycombinator.com/item?id=32155848

[1] https://gitlab.com/dnsmichi/api-playground/-/merge_requests/...

[2] https://gitlab.com/dnsmichi/api-playground/-/tree/main/pytho...

[3] https://gitlab.com/dnsmichi/api-playground/-/tree/main/pytho...

[4] https://gitlab.com/dnsmichi/api-playground/-/tree/main/demo/...

[5] https://forum.gitlab.com/u/dnsmichi/summary

GitLab team member here, putting my personal hat on - from my experience in using different Git workflows since 2009, a smaller clean unit of work can with debugging and troubleshooting. It also provides a way to new team members and contributors to understand the thought process and ideation to implement a new architecture, apply performance fixes, add documentation, work with tests, additional fixes, until its final release. Most of this can be tracked within a MR/PR and the history of code reviews, etc. - even after the merge and squash and Git branch delete, not trying to argue with this functionality. :)

From the Git CLI, without any reference to Git* platforms, it is not so obvious when searching for a commit that introduced a bug, e.g. using "git bisect" for binary search. Reading a 10,000 lines git diff can be harder than a smaller commit that also explains the reasoning in the commit message. Speaking from own experience and programming mistakes in a small team, focussing on clean commits and a good history tremendously helped in stressful debug situations. Until you hit a compiler regression bug, but that's a different story then ;)

I'm personally still very fast on the Git CLI, but I also know that there are a variety of CLI and UI tools out there that can help with analysing large Git commits. Potentially in the future also AI assisted that tell us which change a diff caused a performance regression in a release 5 months later. Or we don't need it at all because Observability driven development enabled to see these problems before merging and code reviews, e.g. the memory leak but only when DNS fails. True story from ~2016, more in my KubeCon EU talk at https://www.youtube.com/watch?v=BkREMg8adaI and project at https://gitlab.com/everyonecancontribute/observability/cpp-d...

GitLab team member here, thanks for sharing!

I'm using the Web IDE to take notes in most of my projects, work and personal, and publish the notes with MkDocs and GitLab Pages to a searchable frontend/domain when needed. Editing also happens in Gitpod with live preview in the browser.

You can find all resources for o11y.love [0] and opsindev.news [1] in the GitLab projects, including .gitpod.yml configuration, mkdocs.yml setup, .gitlab-ci.yml deployments.

I have been writing lots of documentation in my past OSS projects, so I am used to Markdown as markup language, taking notes very fast. Learning Markdown requires some practice, and can be helped within Gitpod and the VS Code extensions, if the default preview is not sufficient. [2] [3] You can also sync the notes repository offline into VS Code as desktop IDE for example.

Using Obsidian.md to take notes and publish with GitLab pages [4] looks promising too; I have not tried it yet.

[0] https://gitlab.com/everyonecancontribute/observability/o11y....

[1] https://gitlab.com/dnsmichi/opsindev.news

[2] https://www.gitpod.io/docs/ides-and-editors/vscode-extension...

[3] https://code.visualstudio.com/docs/languages/markdown

[4] https://about.gitlab.com/blog/2022/03/15/publishing-obsidian...