Skip to content
This repository has been archived by the owner on Aug 8, 2023. It is now read-only.

Add nitpicking CI integration #10937

Merged
merged 6 commits into from
Jan 24, 2018
Merged

Add nitpicking CI integration #10937

merged 6 commits into from
Jan 24, 2018

Conversation

kkaefer
Copy link
Contributor

@kkaefer kkaefer commented Jan 16, 2018

  • Verifies that code generator has been run
  • Verifies that mapbox-gl-js submodule pin was merged into master

The idea of this build is to be optional and to fail when these requirements haven't been met as a reminder to run this code.

@kkaefer
Copy link
Contributor Author

kkaefer commented Jan 18, 2018

If you forget to run code generators, or have an incorrect submodule pin, the nitpick build will fail. It is non-required (so you can merge with it failing), but is supposed to serve as a reminder before merging.

A failing build looks like this:

circleci 2018-01-18 15-17-53

@@ -3364,6 +3364,7 @@
return new LayoutPropertyValue<>("text-optional", value);
}


Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What introduced this extra newline?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unsure, but that's what the code generator produces. Might be some change in the template, or someone forgot to commit this newline from the generator, e.g. in 757cc0f

Copy link
Contributor

@ChrisLoer ChrisLoer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great. I didn't get too far into looking at whether the code was correct, but it looks about right!

Would it make sense to include instructions on temporary modification (e.g. in style-spec.js and generate-shaders.js, as well as the file lists) in the failure message? I imagine over time a lot of people's first introduction to these scripts will be via an unexpected failure on CI.

@@ -0,0 +1,36 @@
platform/android/src/style/light.hpp
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we move all generated files to /generated folders or rename them <filename>.gen.<ext>.

It would remove the need for the generate-style-code-list files, and (in addition to the comments at the top of the file) make it obvious when generated files are being viewed/modified.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For iOS and macOS, it wouldn’t be practical to rename the files, since the header file names are exposed as-is to developers and the Markdown file names show up in URLs in the API reference. However, moving generated files to several /generated folders would be straightforward, since Xcode’s project structure is an abstraction of the file system anyways. Note that the generated guides to have to live more or less where they do now.

Copy link
Contributor

@1ec5 1ec5 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The iOS contributing guide and its macOS counterpart probably need a new section about generating runtime styling code, since the new .list files aren’t particularly discoverable.

@@ -0,0 +1,6 @@
var spec = module.exports = require('../mapbox-gl-js/src/style-spec/reference/v8');

// Make temporary modifications here when Native doesn't have all features that JS has.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Centralizing these modifications is a great idea. 👍

@kkaefer
Copy link
Contributor Author

kkaefer commented Jan 19, 2018

@asheemmamoowala @1ec5 The .list files are automatically generated too from the code gen scripts and don't have to managed by the user. Instead of checking them in, we can also add them to .gitignore, since they'll just serve as a way for the nitpick script to know what files are auto-generated, and the nitpick script runs the code generator beforehand anyway.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants