Add support for Forge workers #20
Merged
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.
This PR adds support for syncing Forge workers 🤖
Pulling down workers from Forge
I added a new
workersconfig key to store workers. Theconfig:pullcommand can now retrieve a list of workers and store them in the config file under this key.Values that are determined to be identical to the 'defaults' (see below) are not written to the config file, with two exceptions—the
queueandconnectionvariables are always written, even when they are the defaults (defaultandredis). This was just my opinion about what the bare minimum config values should be in order for the config file to make sense to look at, they aren't technically necessary and we could easily store more than that. Non-default values will always be written to the config file.Example:
Pushing workers up to Forge
I added a new
WorkerSyncclass that runs as part of theconfig:pushcommand. It behaves similarly to the other sync classes, diffing the resources found locally and on Forge and then creating/deleting Forge resources as necessary.Like the
config:pullcommand,WorkerSyncknows what the 'default' configuration values are for queue workers and will avoid creating/deleting workers with missing configuration values if those values are the defaults. For example, a locally configured worker with notimeoutkey will be considered identical to a worker found on Forge with atimeoutvalue of60, since60is the default. See below and the related testing PR (#21) for more details about how this works.Like the other sync classes,
WorkerSyncwon't actually delete Forge resources unless the--forceflag is passed.DefaultsTo avoid storing lots of huge arrays of mostly-redundant properties, this PR also adds the concept of 'default' properties for Forge resources.
In this case I added a 'default worker' containing the default values for the worker configuration options available in the Forge UI. These defaults are not perfect—it doesn't appear to be possible to get or set the 'Maximum memory' and 'Directory' options through the Forge API at all, so I left these out, and the PHP version is returned in a format that isn't great for storing in the Yaml config file. Additionally, some of the UI and API defaults are different—leaving the
timeoutblank, for example, will default to 60 seconds in the Forge UI but 0 (no timeout) using the API. I tried to choose behaviour that would be intuitive and as similar to the Forge UI as possible.My other goal with this class is to prevent having to repeat these default values in multiple places. Including the code in my related testing PR, these values are needed in 4 or 5 places, so I wanted to keep them in one place so they don't drift and become inconsistent.