Integrate cfbot pgarchives #1
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Built without the proposed Workflow changes since this patch set is intended to demonstrate the integration of CFBot into CFApp. This first commit simply sets up the endpoint for pgarchives to send a complete Thread with Patchset to CFApp and have a new patch created. This allows for real demos without having to setup dummy data - though the later will be part of it as well. The Patch screen thread display area has been reworked a bit, in particular to accomodate the added contextual data available such as is_patch and the specific thread message containing patches. The model now also handles multiple attachments per thread message by removing the too-constraining unique together specification. The patch itself tracks which message contains its most recent patch set and returns only those attachments upon request.
The premise of this patch is to incorporate and enhance the existing CFBot application in CFApp/PGCommitfest. This is definitely an intermediate state where the goal of the CFBot is brought over even though specific aspects of its implementation, in particular its integrataion with CirrusCI, haven't been fully considered. The existing CFBot implementation uses textual indirection and a largely function programming paradigm. I've choosen to structure things a bit differently while keeping the Template Pattern nature intact. Namely by defining abstract classes for the templates and, presently, implementing Local and a Test subclasses to handle live patches, sourced from pgarchives, and test patches, saved within the fixtures directory. The existing Attach Thread feature has been tweaked to use this. CfbotBranch and CfbotTask are modified to handle the processing flow. CfbotQueue (and Item) are implemented. A linked list backed ring queue that determines which patch should next be processed. BranchManager is where the logic of processing a patch is defined. Actions such as apply, compile, and test, are delegated to the contained PatchApplierTemplate, PatchCompilerTemplate, and PatchTesterTemplate abstract classes which themselves have the template methods of begin(), is_done(), and did_fail() (the names make more sense when viewed in the context of the process() method in BranchManager. Auxillary classes for TaskCommands and TaskArtifacts are added, and used to track applied patches at the momement. A BranchHistory is added to capture the branch and task related information that would otherwise be lost since branch is intended to be a "most recent activity per-patch" table. The bulk of the commit is implementing a rough control panel for the entire module, along with the apiv1 endpoints the control panel page uses. The control panel itself is html structure for tables and buttons, the javascript wiring up of the buttons and populating of the tables. The LocalPatchApplier is able to retrieve the patch content from the locally running pgarchives where the patch came from. The Local "Burner" uses a directory on the server, combined with the branch_id, to operate. It is required that the directory exist, and that a "template" subdirectory with a clone of the postgres git repo exist within the directory. The Notifier class is intended to be the integration point from branch manager process to Patch and Queue. It hasn't gotten that much attention as of yet. More will come with artifact processing and integration with CirrusCI. An initial attempt at re-implementing the patch application script is done here. The main difference is that it applies one named file at a time. My present dev environment cannot use --allow-empty so the related code is commented out for the time being.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.