Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[presubmit] Enforce language attribute in project.yaml to be always set. #3477

Merged
merged 9 commits into from
Mar 10, 2020

Conversation

Dor1s
Copy link
Contributor

@Dor1s Dor1s commented Mar 6, 2020

My original intent was to enforce this for non C/C++ projects, but I couldn't come up with a good way to do it only in such cases. Landing this change might somewhat annoy people who contribute more changes to OSS-Fuzz for already integrated C/C++ projects, but that's fine with me -- yet another reason to remind people of the ideal integration.

UPD: when landing this change, I'll update all existing project.yaml files and we'll enforce the attribute from now on.

@Dor1s Dor1s changed the title [presubmit] Enforce language attribute in projectt.yaml to be always set. [presubmit] Enforce language attribute in project.yaml to be always set. Mar 6, 2020
@TravisBuddy
Copy link

Hey @Dor1s,
Your changes look good to me!

View build log

TravisBuddy Request Identifier: 6d85baf0-5fed-11ea-bf9c-5be26ced5bf7

@@ -190,12 +190,10 @@ def check_valid_emails(self):
def check_valid_language(self):
"""Check that the language specified is valid."""
language = self.data.get('language')
if not language:
return

if language not in self.LANGUAGES_SUPPORTED:
Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe add a better message when language is None
like "Missing language attribute" ?
Also, does our documentation for C/C++ mention the language attribute in template ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Also, does our documentation for C/C++ mention the language attribute in template ?

Nope, and I also need to test this before landing, if we agree that's an acceptable solution.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done!

Copy link
Contributor

@jonathanmetzman jonathanmetzman left a comment

Choose a reason for hiding this comment

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

When i tested, it appears that language: c++ is interpreted by pyyaml to be {'language': 'c++'}, so we don't need cpp.

I wouldn't say im opposed to this, but it seems like a blunt solution for the issue of coverage builds happening for non-C++ projects (I don't know enough about the coverage infra to think of an alternative).
I wonder if people in ambiguous language cases (e.g. Python libraries written in C) would get confused.

@jonathanmetzman
Copy link
Contributor

I wouldn't say im opposed to this, but it seems like a blunt solution for the issue of coverage builds happening for non-C++ projects (I don't know enough about the coverage infra to think of an alternative).
Offline max clarified that there are other reasons to do this, srcmap support is different for example, so this looks like a better solution than I initially thought.

@Dor1s
Copy link
Contributor Author

Dor1s commented Mar 6, 2020

Yeah, there are more use cases mentioned in #3297:

  • different coverage logic
  • different srcmap implementation
  • default build configs for different languages
  • $LIB_FUZZING_ENGINE_DEPRECATED vs $LIB_FUZZING_ENGINE, e.g. for Rust we can provide the deprecated version as a non-deprecated one since that's the intended way to use it
  • (more speculative) bad build checks can differ for other languages

@Dor1s
Copy link
Contributor Author

Dor1s commented Mar 6, 2020

When i tested, it appears that language: c++ is interpreted by pyyaml to be {'language': 'c++'}, so we don't need cpp.

I'll change cpp to c++ and also update all existing projects so that the new presubmit check doesn't annoy users who will be making unrelated changes in OSS-Fuzz repo after we land this.

Copy link
Contributor

@jonathanmetzman jonathanmetzman left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor Author

@Dor1s Dor1s left a comment

Choose a reason for hiding this comment

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

I've updated the documentation, presubmit check, and the new project template used by helper.py.

Please take a look. If this looks good, I'll update all the projects with missing attribute and land the change.

@@ -190,12 +190,10 @@ def check_valid_emails(self):
def check_valid_language(self):
"""Check that the language specified is valid."""
language = self.data.get('language')
if not language:
return

if language not in self.LANGUAGES_SUPPORTED:
Copy link
Contributor Author

Choose a reason for hiding this comment

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

done!

@TravisBuddy
Copy link

Travis tests have failed

Hey @Dor1s,
Please read the following log in order to understand the failure reason.
It'll be awesome if you fix what's wrong and commit the changes.

TravisBuddy Request Identifier: 11123ad0-6229-11ea-ba95-012c7b325999

@TravisBuddy
Copy link

Hey @Dor1s,
Your changes look good to me!

View build log

TravisBuddy Request Identifier: ce24e630-624d-11ea-ba95-012c7b325999

@Dor1s
Copy link
Contributor Author

Dor1s commented Mar 9, 2020

@oliverchang PTAL too, maybe you have another idea or any concerns regarding this one.

Copy link
Collaborator

@oliverchang oliverchang left a comment

Choose a reason for hiding this comment

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

LGTM


PROJECT_YAML_TEMPLATE = """\
homepage: "<your_project_homepage>"
language: <programming_language>
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: give valid values as examples, as otherwise it's not clear what's expected (e.g. cpp or c++) ?

@TravisBuddy
Copy link

Travis tests have failed

Hey @Dor1s,
Please read the following log in order to understand the failure reason.
It'll be awesome if you fix what's wrong and commit the changes.

TravisBuddy Request Identifier: aa2f4450-62f7-11ea-b4e6-7500f47047b3

@Dor1s
Copy link
Contributor Author

Dor1s commented Mar 10, 2020

I've added labels and selective_unpack sections to presubmit script plus fixed a few files manually. There's still a dozen of presubmit errors (for missing primary_contact, non fuzzing engine (e.g. chakra), and some other custom value used only once), which I can't fix, so will land with them.

@Dor1s Dor1s merged commit 71f4914 into master Mar 10, 2020
@TravisBuddy
Copy link

Hey @Dor1s,
Something went wrong with the build.

TravisCI finished with status errored, which means the build failed because of something unrelated to the tests, such as a problem with a dependency or the build process itself.

View build log

TravisBuddy Request Identifier: 6c4f1900-6309-11ea-8dd1-c14dbc1d5bef

Dor1s added a commit that referenced this pull request Mar 12, 2020
… runner.

Should've done this in #3477. Good news is that nothing failed, the coverage job was just skipped for pretty much all projects.
Dor1s added a commit that referenced this pull request Mar 12, 2020
…s. (#3493)

* [infra] Change language attribute from "cpp" to "c++" in coverage job runner.

Should've done this in #3477. Good news is that nothing failed, the coverage job was just skipped for pretty much all projects.

* also remove default value from build_project script
@Dor1s Dor1s mentioned this pull request Mar 27, 2020
@jonathanmetzman jonathanmetzman deleted the language branch November 19, 2020 19:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants