{"id":19236411,"url":"https://github.com/infobyte/gorrabot","last_synced_at":"2025-04-21T05:32:22.652Z","repository":{"id":69537947,"uuid":"422679183","full_name":"infobyte/gorrabot","owner":"infobyte","description":"Gorrabot is a bot made to automate checks and processes in the development process.","archived":false,"fork":false,"pushed_at":"2024-06-18T19:04:30.000Z","size":1330,"stargazers_count":9,"open_issues_count":0,"forks_count":5,"subscribers_count":13,"default_branch":"master","last_synced_at":"2025-04-01T10:11:10.875Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/infobyte.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2021-10-29T18:38:49.000Z","updated_at":"2025-03-31T01:55:37.000Z","dependencies_parsed_at":null,"dependency_job_id":"58e4850f-8db9-47ac-9ec5-0bf34bfb90cb","html_url":"https://github.com/infobyte/gorrabot","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/infobyte%2Fgorrabot","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/infobyte%2Fgorrabot/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/infobyte%2Fgorrabot/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/infobyte%2Fgorrabot/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/infobyte","download_url":"https://codeload.github.com/infobyte/gorrabot/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":250002290,"owners_count":21359086,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-09T16:20:29.183Z","updated_at":"2025-04-21T05:32:22.374Z","avatar_url":"https://github.com/infobyte.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"Gorrabot is a Gitlab bot made to automate checks and processes in the Faraday\ndevelopment.\n\n# Features\n\n## \u003ca name=\"changelog-check\"\u003e\u003c/a\u003eCheck that the CHANGELOG is modified\n\nBy default, merge requests MUST create a `.md` file inside the\n`CHANGELOG/\u003ccurrent_version\u003e` folder. We do this because it is easier to write\nchangelog messages after finishing working on the change than before releasing\na new version. In the latter, we could easily forget what we did and write a\nlower quality changelog message.\n\nWhen somebody publishes a ready to merge MR that didn't touch the changelog,\ngorrabot automaticaly sets it to WIP (work in process). Then the MR's author\nis required to touch the changelog, push a new commit and resolve the WIP\nstatus from the gitlab web.\n\nAlternatively, if the MR's author doesn't consider useful to add a changelog\nentry for that change (e.g. when fixing typos or doing small refactors), he/she\ncan add the `no-changelog` label to the merge request and this check won't be\nperformed to it.\n\n## Issue state changing based on MR status\n\nGet the issue related to a merge request by inspecting its source branch name\n(e.g `tkt_community_1234_some_description`). Then, when the status of the MR is\nupdated, also update the labels and status of the related issue.\n\nGorrabot also adds a `Closes #1234` text in the description, so GitLab closes\nthe related issue when the MR is merged. Also, when a user sees the issue\ndetails he/she will have a link to its corresponding merge request.\n\nExample actions (see the code of `sync_related_issue` `app.py` for the exact\nlist):\n\n* Created WIP MR -\u003e Label issue as accepted\n* Pending merge/approbal MR -\u003e Label issue as test\n* Merged MR -\u003e Close issue and delete status labels (accepted, test)\n* Closed MR -\u003e Delete status labels (set to new)\n\n\u003ca name=\"multiple-merge-requests\"\u003e\u003c/a\u003e\nSometimes this actions aren't desired, like for example when an issue requires\nmultiple merge requests to be considered as fixed.  In this case, you can add\nthe `multiple-merge-requests` label to the issue and its status and labels\nwon't be modified by gorrabot.\n\n## Merge request field completion based on its issue\n\nIf a merge request doesn't have an assigned user, derive it from the assigned\nuser of its related issue. Do the same with the MR's milestone.\n\n## \u003ca name=\"branch-nomenclature-check\"\u003e\u003c/a\u003eBranch naming nomenclature check\n\nIf the source branch of a merge request doesn't match our nomenclature,\nnote that in a comment. The merge request won't be set to WIP because\nof this, it is just a warning to avoid doing this the next time.\n\n## Merge request title check\n\nWhen creating a merge request from the gitlab web, by default it derives its\ntitle from the source branch name. This is useful in many projects, but in\nFaraday it can be annoying because of our branch naming conventions.\n\nFor example, it wouldn't be useful to have a merge request titled `Tkt community\n1234 some description`. A more concise title would be more helpful. If we\nwanted, we could know the related issue and target version just by looking at\nthe source and target branches of the MR.\n\nLike with the previous feature, this check will just leave a comment in the\nmerge request if doesn't pass, so the user could avoid this the next time.\nThere is no need to set it to WIP.\n\n## Automatic creation of upper versions MRs\n\nWhen a community feature MR also needs changes in professional, the suggested way to\nproceed is to create a branch of professional/dev with both the changes of the community MR\nand the specific changes to professional. Then, open another merge request with target\nbranch professional/dev.\n\nCreating another merge request for the professional feature is tedious, so when the\nuser pushes the professional branch, Gorrabot will detect this is an \"upper version\nMR\". Then, it will create a new MR with the same content as the community MR, but\nwith a `(professional edition)` added in the title to properly differentiate both MRs.\n\nThe same thing happens when a professional branch conflicts with upper branches (if exists).\n\nGorrabot will also notify the user the MR was created. And when the community MR is\nmerged, it will notify the user who merged it so they don't forget about\nmerging the upper version MR too.\n\n## Check and report by slack \n\nGorrabot checks the status of the projects, and give a summary of: \n\n * Staled MR (both WIP and non-WIP) not update in a given amount of time\n * The accepted issues are less than a boundary\n * There is no issue waiting for a decision.\n \nAnd gives each developer a summary of undesirable behaviour. Moreover, it gives\na summary of the team to the REPORT users.\n\n### Staled MR and accepted issues\n\nBased on the default concept of gitlab, this value is obtained by the gitlab \nAPI.\n\n### Waiting for decision issues\n\nWhen the `waiting-decision` label is set in a issue, gorrabot will parse its \ndescription and look for a line starting with the prefix `WFD: `. After that \nprefix, there should be a comma-separated list of gitlab or slack users, whom\ndecision is expected to resolve the issue. \n\nIn the case of gitlab users, you should reference them with an @, as the common\ngitlab behaviour. In the case of slack users, based on slack API, you should \nuse the email username. E.g. for `uname@company.com` the id is `uname` not \nUser Name, or any other display name.\n\n# Summary of special labels\n\n* `no-changelog`: Use this when the merge request consists of a really\n  small check that shouldn't be reflected on the `RELEASE.md` file\n  See [this](#changelog-check) for more documentation about this\n* `multiple-merge-requests`: The only label that must be applied to issues\n  instead of merge requests. Avoid gorrabot changing the status and labels of\n  issues labeled with this. See [this](#multiple-merge-requests) for more\n  information\n* `sacate-la-gorra`: A wildcard label that totally disables gorrabot on\n  that merge request. **THIS ISN'T RECOMMENDED, SO THINK TWICE WHEN USING THIS**\n* `waiting-decision`: This issue needs a decision be taken before be resolved. \n  See [this](#waiting-for-decision-issues) for more information.\n\n\n# Design goals\n\n## Avoid state\n\nTo simplify deployment and avoid having to do data migrations, it makes sense\nto not use a database in this project. Most things can be achieved this way.\n\nFor example, lets take the [Branch nomenclature\ncheck](#branch-nomenclature-check) feature. I don't want gorrabot to make a\ncomment each time the merge request is modified, so I need a way to avoid\nduplicating this kind of comment.\n\nThe traditional way to solve this would be to store in a database the merge\nrequests where this comment has already been made. I instead check for the\ncomments of the MR. If there exists a comment similar to what gorrabot\nwants to comment, return without commenting. When done this way, I don't\nneed to store anything in a database, just use the Gitlab information.\n\nThis has some small drawbacks also. For example, if I want to change the text\nof the comment to something new and a merge request has already a comment with\nthe old version text, there will be two similar comments with different text.\n\nI think this behavior is acceptable for what we're doing, and doing big\narchitecture changes just to fix this kind of things doesn't bring much\nbenefits. Sacrificing simplicity is bad.\n\n## Don't replace a CI\n\nThe goal of this project is to help us with some things related to our\ndevelopment process, not to our code base itself. For this things,\nhaving a continuous integration seems to be a better choice.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Finfobyte%2Fgorrabot","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Finfobyte%2Fgorrabot","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Finfobyte%2Fgorrabot/lists"}