Add continuous integration for the English Wikipedia
This issue contains content from the English Wikipedia, which is licensed under the Creative Commons BY-SA 3.0 Unported License.
Background
As of now, updates to the RedWarn script on the English Wikipedia require the presence of the lead developer, @ed_e. This, however, has proven to be a roadblock in important updates that cause catastrophic failure to RedWarn's processes, be it in loading or warning users (see #74 (closed)). As a result, RedWarn is rendered unusable for hours on end, forcing users to use other tools and also preventing us from reaching a good uptime. Because of this, a need for a system which allows for immediate updates whenever the tool maintainers see fit is required.
There exists one restriction to such a feature: Wikipedia policy.
In terms of Wikipedia policy, there are requirements to triggering edits at the request of a user. They can be found at WP:BOTMULTIOP:
- Disclosure: The identity of the Wikipedia user directing the edit/action must be publicly disclosed, typically by linking the username in the edit summary.
- Verification: The identity of the Wikipedia user must be reliably verified to the bot in a manner not easily faked, bypassed or avoided. Suitable methods include a non-trivial password, IP restrictions, wiki login or IRC hostname. If the bot is used to make sensitive actions stronger methods of verification may be required.
- Competence: All users directing a bot must have the required skill and knowledge to ensure their actions are within community consensus.
Process
With this in mind, I'm proposing the following workflow for facilitating updates to the RedWarn script.
- When a commit is pushed to master, the GitLab CI will immediately create the build artifacts (
redwarn.js
, as of now). - Manual confirmation is required on the side of GitLab (through CI features) to confirm an update to Wikipedia.
- Manual confirmation on Wikipedia (Wikipedia:RedWarn/Commit Approval) will be done in order to log the executing user. If the user is not part of the core team developers (Owner-level group members, hardcoded into CI), their edit will not be accepted. A confirming edit must be made by the team member, signed with their signature, and must contain the commit hash of the latest commit on the branch. This process times out in 5 minutes. An example of approval may appear like the following:
- The CI will detect the change and give another 1-hour grace period for cancelling the operation. At this juncture, any user from the team (even maintainers) may intervene and stop the pipeline immediately in case something is off.
- The CI will use the credentials stored in the project variables in order to make the edit on Wikipedia.
- An additional edit will be made on an on-wiki log documenting the exact git hash of the pushed commit and the user who ordered the change. The approval page will also be automatically blanked. This sets the maximum amount of edits made by the CI at three.
This satisfies all three of the WP:BOTMULTIOP requirements, and also ensures security and verifiability of the member triggering the update. All CI-related scripts will be kept open-source and on-repo. Additional output regarding confirmation may be found in the pipeline logs.
For a malicious commit to make it into production, both a team member's GitLab and Wikipedia account must be compromised. Preventing this is the responsibility of the member, not the system. Fabrication is nearly impossible as part of the process runs on Wikipedia. Man-in-the-middle fabrication between GitLab and Wikipedia is a near impossibility given modern HTTPS techniques.
Comments and suggestions are appreciated. Pinging @All project members.