Add CodeQL workflow for GitHub code scanning

[lgtm-com]

Hi sbabic/swupdate!

This is a one-off automatically generated pull request from LGTM.com 🤖. You might have heard that we’ve integrated LGTM’s underlying CodeQL analysis engine natively into GitHub. The result is GitHub code scanning!

With LGTM fully integrated into code scanning, we are focused on improving CodeQL within the native GitHub code scanning experience. In order to take advantage of current and future improvements to our analysis capabilities, we suggest you enable code scanning on your repository. Please take a look at our blog post for more information.

This pull request enables code scanning by adding an auto-generated codeql.yml workflow file for GitHub Actions to your repository — take a look! We tested it before opening this pull request, so all should be working ✔️. In fact, you might already have seen some alerts appear on this pull request!

Where needed and if possible, we’ve adjusted the configuration to the needs of your particular repository. But of course, you should feel free to tweak it further! Check this page for detailed documentation.

Questions? Check out the FAQ below!

FAQ

Click here to expand the FAQ section

How often will the code scanning analysis run?

By default, code scanning will trigger a scan with the CodeQL engine on the following events:

• On every pull request — to flag up potential security problems for you to investigate before merging a PR.
• On every push to your default branch and other protected branches — this keeps the analysis results on your repository’s Security tab up to date.
• Once a week at a fixed time — to make sure you benefit from the latest updated security analysis even when no code was committed or PRs were opened.

What will this cost?

Nothing! The CodeQL engine will run inside GitHub Actions, making use of your unlimited free compute minutes for public repositories.

What types of problems does CodeQL find?

The CodeQL engine that powers GitHub code scanning is the exact same engine that powers LGTM.com. The exact set of rules has been tweaked slightly, but you should see almost exactly the same types of alerts as you were used to on LGTM.com: we’ve enabled the security-and-quality query suite for you.

How do I upgrade my CodeQL engine?

No need! New versions of the CodeQL analysis are constantly deployed on GitHub.com; your repository will automatically benefit from the most recently released version.

The analysis doesn’t seem to be working

If you get an error in GitHub Actions that indicates that CodeQL wasn’t able to analyze your code, please follow the instructions here to debug the analysis.

How do I disable LGTM.com?

If you have LGTM’s automatic pull request analysis enabled, then you can follow these steps to disable the LGTM pull request analysis. You don’t actually need to remove your repository from LGTM.com; it will automatically be removed in the next few months as part of the deprecation of LGTM.com (more info here).

Which source code hosting platforms does code scanning support?

GitHub code scanning is deeply integrated within GitHub itself. If you’d like to scan source code that is hosted elsewhere, we suggest that you create a mirror of that code on GitHub.

How do I know this PR is legitimate?

This PR is filed by the official LGTM.com GitHub App, in line with the deprecation timeline that was announced on the official GitHub Blog. The proposed GitHub Action workflow uses the official open source GitHub CodeQL Action. If you have any other questions or concerns, please join the discussion here in the official GitHub community!

I have another question / how do I get in touch?

Please join the discussion here to ask further questions and send us suggestions!

[github-actions]

Contributing to SWUpdate

Contributions are welcome ! Please follow the following guideline for
contributions.

Contribution Checklist

These are mostly general recommendations and are common practice in a
lot of FOSS projects.

• use git to manage your changes [recomended]

• follow as much as possible kernel codestyle [recomended]
  Nevertheless, some rules are not so strict as in kernel. The maximum
  line length can be extended over 80 chars if this increase code
  readability.

• add the required copyright header to each new file introduced
  [required]

• • add signed-off to all patches [required]

    • to certify the "Developer's Certificate of Origin", see
      below
    • check with your employer when not working on your own!

• • add version number for your patches if follow-up versions are
    requested [recomended]

    • Add a "Change from Vx" description under the commit message
      to take track of the history of the patch.
    • It is suggested to use excellent "patman" tool to manage
      patches series. This is part of U-Boot's project
      (tools/patman), but it can be used in other projects, too.

• check that your patches do not break build [required]

  • There is a set of configuration files in the
    configs/ directory. Please run a
    build for all files in the directory to ensure that SWUpdate is
    still buildable from configurations different as yours.

• • post patches to mailing list [required]

    • use git format-patch to
      generate your patches.
    • use git send-email if
      possible. This avoid corruptions due to the mailers
    • add a prefix [meta-swupdate] if patches are intended to
      the Yocto's meta layer.
    • send patches inline, do not append them
    • no HTML emails!

• do not use github Pull Request. github facilities are not used for
  this project. The review is done in a single place : the Mailing
  List. PR from github are ignored.

Patches are tracked by patchwork (see
http://jk.ozlabs.org/projects/patchwork/). You can see the status of
your patches at http://patchwork.ozlabs.org/project/swupdate/list.

Developer's Certificate of Origin 1.1

When signing-off a patch for this project like this

Signed-off-by: Random J Developer <random@developer.example.org>

using your real name (no pseudonyms or anonymous contributions), you
declare the following:

By making a contribution to this project, I certify that:

1. The contribution was created in whole or in part by me and I
   have the right to submit it under the open source license
   indicated in the file; or
2. The contribution is based upon previous work that, to the best
   of my knowledge, is covered under an appropriate open source
   license and I have the right under that license to submit that
   work with modifications, whether created in whole or in part by
   me, under the same open source license (unless I am permitted to
   submit under a different license), as indicated in the file; or
3. The contribution was provided directly to me by some other
   person who certified (a), (b) or (c) and I have not modified it.
4. I understand and agree that this project and the contribution
   are public and that a record of the contribution (including all
   personal information I submit with it, including my sign-off) is
   maintained indefinitely and may be redistributed consistent with
   this project or the open source license(s) involved.