Add handling for bad data in ci_build options
What does this MR do?
There’s a scenario by which a stringified ruby hash is making it into
options values, which can’t be serialized/deserialized properly but
is currently not being handled. This fix resolves the scenarios we’re
seeing where the data is invalid, but we should take steps to not allow
that bad data into the system at all.
#34860 (closed) gitlab-com/gl-infra/production#1275 (closed)
Does this MR meet the acceptance criteria?
Conformity
- [-] Changelog entry
- [-] Documentation created/updated or follow-up review issue created
-
Code review guidelines -
Merge request performance guidelines -
Style guides - [-] Database guides
- [-] Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. - [-] Tested in all supported browsers
~backstage ~bug
Merge request reports
Activity
changed milestone to %12.4
@sabrams, in case you want to monitor this.
mentioned in issue #34860 (closed)
3695 3695 3696 3696 it { is_expected.to be_falsey } 3697 3697 end 3698 3699 context 'when options is a string' do 3700 let(:options) { nil } 3701 3702 before do 3703 build.write_attribute(:options, %{{"artifacts"=>{"reports"=>{"junit"=>"junit.xml"}}}}) -
interestingly, when we try to set options directly there's a setter method in https://gitlab.com/gitlab-org/gitlab/blob/master/app%2Fmodels%2Fconcerns%2Fci%2Fmetadatable.rb#L47 that bombs out.
We have to write the attribute directly to be able to simulate what we're seeing on production.
Edited by Jeremy Jackson
-
@stanhu, would you like to provide your thoughts on this? I think we can merge it and open an issue to revert this code once a fix / data cleanup process has been run.
Reviewer roulette
Changes that require review have been detected! A merge request is normally reviewed by both a reviewer and a maintainer in its primary category (e.g. frontend or backend), and by a maintainer in all other categories.
To spread load more evenly across eligible reviewers, Danger has randomly picked a candidate for each review slot. Feel free to override this selection if you think someone else would be better-suited, or the chosen person is unavailable.
Once you've decided who will review this merge request, mention them as you normally would! Danger does not (yet?) automatically notify them for you.
Category Reviewer Maintainer backend Felipe Artur ( @felipe_artur)Sean McGivern ( @smcgivern)Generated by
Edited by 🤖 GitLab Bot 🤖added backstage [DEPRECATED] typebug labels
767 767 true 768 768 end 769 769 770 def options 771 @options ||= begin 772 return self[:options] if self[:options].is_a?(HashWithIndifferentAccess) 773 # for really bad data handling scenarios, barely production ready 774 HashWithIndifferentAccess.new(JSON.parse(self[:options].gsub('=>', ':'))) rescue { } changed this line in version 2 of the diff
-
I moved this out of here and into the https://gitlab.com/gitlab-org/gitlab/blob/master/app%2Fmodels%2Fconcerns%2Fci%2Fmetadatable.rb class since it needs to be there. This should probably fix a couple other issues where we might be seeing the same thing.
added 1 commit
- fa73f65d - Add handling for bad data in ci_build options
37 37 end 38 38 39 39 def options 40 read_metadata_attribute(:options, :config_options, {}) 40 ret = read_metadata_attribute(:options, :config_options, {}) This seems to be a problem also of
DiffNote. I would propose to use @stanhu fix: !19124 (merged).
mentioned in issue gitlab-com/gl-infra/production#1275 (closed)
