runbot/forwardport/__manifest__.py

# -*- coding: utf-8 -*-
{
    'name': 'forward port bot',
    'version': '1.2',
    'summary': "A port which forward ports successful PRs.",
    'depends': ['runbot_merge'],
    'data': [
        'data/security.xml',
        'data/crons.xml',
        'data/views.xml',
        'data/queues.xml',
    ],
    'license': 'LGPL-3',
}
[ADD] forwardbot * Cherrypicking is handrolled because there seems to be no easy way to programmatically edit commit messages during the cherrypicking sequence: `-n` basically squashes all commits and `-e` invokes a subprocess. `-e` with `VISUAL=false` kinda sorta works (in that it interrupts the process before each commit), however there doesn't seem to be clean status codes so it's difficult to know if the cherrypick failed or if it's just waiting for a commit of this step. Instead, cherrypick commits individually then edit / rewrite their commit messages: * add a reference to the original commit * convert signed-off-by to something else as the original commit was signed off but not necessarily this one * Can't assign users when creating PRs: only repository collaborators or people who commented on the issue / PR (which we're in the process of creating) can be assigned. PR authors are as likely to be collaborators as not, and we can have non-collaborator reviewers. So pinging via a regular comment seems less fraught as a way to notify users. 2019-08-23 21:16:30 +07:00			`# -- coding: utf-8 --`
			`{`
			`'name': 'forward port bot',`
[IMP] forwardport: store and display detachment reason Currently, if a PR forward-port PR gets detached the reason for it is not always obvious, and may have to be hunted in the logs or in "sibling" PRs. By writing a forward port reason (hopefully) ever time we detach a PR, and displaying that reason in the form and dashboard, the justification should be a lot more obvious. Fixes #679 2023-01-19 20:23:41 +07:00			`'version': '1.2',`
[ADD] forwardbot * Cherrypicking is handrolled because there seems to be no easy way to programmatically edit commit messages during the cherrypicking sequence: `-n` basically squashes all commits and `-e` invokes a subprocess. `-e` with `VISUAL=false` kinda sorta works (in that it interrupts the process before each commit), however there doesn't seem to be clean status codes so it's difficult to know if the cherrypick failed or if it's just waiting for a commit of this step. Instead, cherrypick commits individually then edit / rewrite their commit messages: * add a reference to the original commit * convert signed-off-by to something else as the original commit was signed off but not necessarily this one * Can't assign users when creating PRs: only repository collaborators or people who commented on the issue / PR (which we're in the process of creating) can be assigned. PR authors are as likely to be collaborators as not, and we can have non-collaborator reviewers. So pinging via a regular comment seems less fraught as a way to notify users. 2019-08-23 21:16:30 +07:00			`'summary': "A port which forward ports successful PRs.",`
			`'depends': ['runbot_merge'],`
			`'data': [`
			`'data/security.xml',`
			`'data/crons.xml',`
			`'data/views.xml',`
[IMP] mergebot, forwardbot: various UI bits - code in the various menus added over time through the UI (queues, configuration, ...) - update / improve PR layout a tick - fix "outstanding forward ports" count on the dashboard - improve hover title / help on dashboard - add date of last modification (usually date of success / failure) - make casing more coherent (everything lowercase) - add explicit note that UTC date on staged at label is staged at datetime - rediscover yet again that the staging information is when hovering on the staging except the staged at label - improve `PullRequest.unstage` to always insert the PR at the start of the reason when cancelling the staging, for clarity / traceability Closes #560, closes #609 2022-06-07 20:49:52 +07:00			`'data/queues.xml',`
[ADD] forwardbot * Cherrypicking is handrolled because there seems to be no easy way to programmatically edit commit messages during the cherrypicking sequence: `-n` basically squashes all commits and `-e` invokes a subprocess. `-e` with `VISUAL=false` kinda sorta works (in that it interrupts the process before each commit), however there doesn't seem to be clean status codes so it's difficult to know if the cherrypick failed or if it's just waiting for a commit of this step. Instead, cherrypick commits individually then edit / rewrite their commit messages: * add a reference to the original commit * convert signed-off-by to something else as the original commit was signed off but not necessarily this one * Can't assign users when creating PRs: only repository collaborators or people who commented on the issue / PR (which we're in the process of creating) can be assigned. PR authors are as likely to be collaborators as not, and we can have non-collaborator reviewers. So pinging via a regular comment seems less fraught as a way to notify users. 2019-08-23 21:16:30 +07:00			`],`
[FIX] runbot: adapt routes and licenses 2021-07-27 20:53:31 +07:00			`'license': 'LGPL-3',`
[ADD] forwardbot * Cherrypicking is handrolled because there seems to be no easy way to programmatically edit commit messages during the cherrypicking sequence: `-n` basically squashes all commits and `-e` invokes a subprocess. `-e` with `VISUAL=false` kinda sorta works (in that it interrupts the process before each commit), however there doesn't seem to be clean status codes so it's difficult to know if the cherrypick failed or if it's just waiting for a commit of this step. Instead, cherrypick commits individually then edit / rewrite their commit messages: * add a reference to the original commit * convert signed-off-by to something else as the original commit was signed off but not necessarily this one * Can't assign users when creating PRs: only repository collaborators or people who commented on the issue / PR (which we're in the process of creating) can be assigned. PR authors are as likely to be collaborators as not, and we can have non-collaborator reviewers. So pinging via a regular comment seems less fraught as a way to notify users. 2019-08-23 21:16:30 +07:00			`}`