You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
If we have multiple metahook instances, let's not generate multiple temporary directories; instead just create one (and only dump the environment variables once). We also shard the vars file by the plugin configuration (calculating a hash using the standard cksum utility) so that you can have multiple metahook instances each with their own configuration (which is implicitly stored in the vars file).
I'm not sure why the vars file is created at all, as it seems it could be dynamically probed with [[ -v "BUILDKITE_PLUGIN_METAHOOK_${upperd}" ]] instead of using the grep on the vars file (since the variables should be live in the environment when the hook is actually executed), but I kept the current behavior.
Verification
This fixed an issue with multiple metahook instances in a pipeline of mine.
If we have multiple `metahook` instances, let's not generate multiple
temporary directories; instead just create one (and only dump the
environment variables once).
This fixed an issue with multiple `metahook` instances in a pipeline of
mine.
By hashing the `BUILDKITE_PLUGIN_CONFIGURATION` envvar, we can
effectively disambiguate multiple instances of the `metahook` plugin
within a single pipeline. This allows us to seprate the `vars` file, as
it otherwise can get confused if you have multiple invocations of the
plugin that each use different hooks.
staticfloat
changed the title
Don't overwrite BUILDKITE_METAHOOK_HOOKS_PATH
Don't overwrite BUILDKITE_METAHOOK_HOOKS_PATH, and shard vars by plugin configuration
Jun 14, 2021
If we have multiple metahook instances, let's not generate multiple temporary directories; instead just create one (and only dump the environment variables once). We also shard the vars file by the plugin configuration (calculating a hash using the standard cksum utility) so that you can have multiple metahook instances each with their own configuration (which is implicitly stored in the vars file).
I'm not sure why the vars file is created at all, as it seems it could be dynamically probed with [[ -v "BUILDKITE_PLUGIN_METAHOOK_${upperd}" ]] instead of using the grep on the vars file (since the variables should be live in the environment when the hook is actually executed), but I kept the current behavior.
Verification
This fixed an issue with multiple metahook instances in a pipeline of mine.
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.
staticfloat
force-pushed
the
sf/multimetahook
branch
from
Changes
If we have multiple
metahookinstances, let's not generate multiple temporary directories; instead just create one (and only dump the environment variables once). We also shard thevarsfile by the plugin configuration (calculating a hash using the standardcksumutility) so that you can have multiplemetahookinstances each with their own configuration (which is implicitly stored in thevarsfile).I'm not sure why the
varsfile is created at all, as it seems it could be dynamically probed with[[ -v "BUILDKITE_PLUGIN_METAHOOK_${upperd}" ]]instead of using thegrepon thevarsfile (since the variables should be live in the environment when the hook is actually executed), but I kept the current behavior.Verification
This fixed an issue with multiple
metahookinstances in a pipeline of mine.