[BuildStream] cache key changes



During Thursday's discussion about cache key generation it was agreed
that there should be a revised public specification for the cache key
dictionary. The current cache key dictionary is specified at
https://gitlab.com/BuildStream/buildstream/blob/master/src/buildstream/element.py#L2205-2222.
The current proposal is to alter and formalize that as the following:

```JSON
{
    core-version: <INT>,
    element-plugin-key: <*>,
    element-plugin-name: <STR>,
    element-plugin-version: <INT>,
    dependencies-strong: [<STR>],
    dependencies-weak: [<STR>],
    environment-variables: {[<STR>: <STR>]},
    sandbox: {[<STR>: <STR>], "tainted": <BOOL>},
    sources: [{"key": <*>, "name": <STR>, "version": <INT>}],
    public: {...},
    fatal-warnings: [<STR>]
}
```

This comprises the following changes:
* `artifact-version` is replaced by `core-version`
* `element` is replaced by:
    - `element-plugin-key`
* `element-plugin-name` is added
* `element-plugin-version` is added
* `dependencies` is replaced by:
    - `dependencies-strong` (containing the strong cache keys of
dependencies)
    - `dependencies-weak` (containing the weak keys of dependencies)
* `context` is removed
* `project` is removed
* `environment` is replaced `environment-variables`
* `execution-environment` is replaced by `sandbox`
* `sources` is now a list of dictionaries of name, version, and key.
This may be overwritten by the values of `workspaces` which is removed
* `fatal-warnings` is unchanged
* `public` is unchanged
* `cache` is removed

Some of these keys are renamed to better suggest the function which
generates their values.

It is proposed that any default values are not inserted into this
dictionary since they do not add value to the cache key generation. In
addition it is proposed to insert `public-nocache` into the dictionary.
Values which are publically defined but not affecting the build result
constitute the values of `public-nocache`.

There is an additional point to raise concerning the return of
`get_unique_key` in plugins: I think this should be standardized as some
sort of serializable type. A dictionary would probably be a good choice.

-- 
Best Regards,
Darius


For Codethink's privacy-policy please see
https://www.codethink.co.uk/privacy.html


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]