We assume that when someone adds a key for the configuration entry, but
does not provide a valid value, which causes entry to be `nil`, then
entry should be considered as the undefined one. We also assume this is
semantically correct, this is also backwards compatible with legacy CI
config processor.
See issue #18775 for more details.
This follows a standard `ActiveModel` pattern of creating a custom
validators. We use `ActiveModel::EachValidator` here that reuses methods
provided by `LegacyValidationHelpers`.
We will remove `LegacyValidationHelpers` on some point in the future, at
the later stages of CI configuration refactoring. It may be possible
to rewrite custom validators to use format like:
`validates :config, array_of: String`
* master: (285 commits)
Bump recaptcha gem to 3.0.0 to remove deprecated stoken support
Load knapsack in Rakefile only when is bundled
Add License Finder information to contribution acceptance criteria.
Add LGPLv2 to license whiltelist
Instrument `RepositoryCheck::SingleRepositoryWorker` manually
Bump nokogiri to 1.6.8
Fix alignment of wiki top area
Update charcoal theme colors
Update nav link font size and spacing; fix hamburger icon
Fix control btn position
Remove todos count tests in nav
Test impersonation using img data attribute instead of username
Implement compact side nav
Fix knapsack for master
Align links and tabs
Add scrolling tabs to code subnav
Finish styling sub nav
Updated colors
Fixed failing tests
CHANGELOG item
...
Conflicts:
lib/gitlab/ci/config.rb
spec/lib/gitlab/ci/config_spec.rb
As for now, we keep this class inside a oryginal config processor class.
We will move implementation to this class and delegate to it from
current config processor.
After original gitlab ci yaml processor not longer has relevant
impelemntation we will replace it with new configuration class.
This changes the format of metadata to handle paths, that may contain
whitespace characters, new line characters and non-UTF-8 characters.
Now those paths along with metadata in JSON format are stored as
length-prefixed strings (uint32 prefix).
Metadata file has a custom format:
1. First string field is metadata version field (string)
2. Second string field is metadata errors field (JSON strong)
3. All subsequent fields is pair of path (string) and path metadata
in JSON format.
Path's metadata contains all fields that where possible to extract from
ZIP archive like date of modification, CRC, compressed size,
uncompressed size and comment.
Grzegorz Bizon
Robert Speicher
Gabriel Mazetto
Kamil Trzcinski