Zizmor integration

[jakob-keller]

Description of Change

Integrate zizmor via GitHub Actions

• https://woodruffw.github.io/zizmor/usage/#use-in-github-actions

Assumptions

None

Checklist for All Submissions

• I have added change info to CHANGES.rst
• If this is resolving an issue (needed so future developers can determine if change is still necessary and under what conditions) (can be provided via link to issue with these details): closes Add zizmor GitHub workflow #1334
  • Detailed description of issue
  • Alternative methods considered (if any)
  • How issue is being resolved
  • How issue can be reproduced
• If this is providing a new feature (can be provided via link to issue with these details):
  • Detailed description of new feature
  • Why needed
  • Alternatives methods considered (if any)

Checklist when updating botocore and/or aiohttp versions

• I have read and followed CONTRIBUTING.rst
• I have updated test_patches.py where/if appropriate (also check if no changes necessary)
• I have ensured that the awscli/boto3 versions match the updated botocore version
• I have added URL to diff: boto/botocore@[CURRENT_BOTO_VERSION_TAG]...[NEW_BOTO_VERSION_TAG]

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.83%. Comparing base (41645a1) to head (bad8f50).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1344   +/-   ##
=======================================
  Coverage   90.83%   90.83%           
=======================================
  Files          67       67           
  Lines        6559     6559           
=======================================
  Hits         5958     5958           
  Misses        601      601           

Flag	Coverage Δ
unittests	90.83% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[webknjaz]

@webknjaz: Should we make this part of the allsgreen check? If so, fold the workflow into the existing ci-cd workflow?

Didn't think about it. But perhaps, it's a good idea. Though, there's merge queue and I don't know if we should be running the check with those. I guess, we'll find out.

Regarding adding more jobs, while integrating alls-green into CPython, I had to deal with multiple workflows. And I ended up coming up with a modularization idea — different jobs (but not matrixes) can go into in-repo reusable workflows. Their names are prefixed with reusable- and they are only allowed to have the workflow_call trigger setup. Then, the main workflow has all the real triggers + defines relationships between the jobs and matrixes on the high level. This top-level definition also contains alls-green and pypi-publish (due to trusted publishing limitations, it's not in a reusable workflow).

Having been using this approach for almost 2 years now, I find it a really good structure as it allows separating the abstraction layers which is good for the organization.

[jakob-keller]

@webknjaz: Should we make this part of the allsgreen check? If so, fold the workflow into the existing ci-cd workflow?

Didn't think about it. But perhaps, it's a good idea. Though, there's merge queue and I don't know if we should be running the check with those. I guess, we'll find out.

Regarding adding more jobs, while integrating alls-green into CPython, I had to deal with multiple workflows. And I ended up coming up with a modularization idea — different jobs (but not matrixes) can go into in-repo reusable workflows. Their names are prefixed with reusable- and they are only allowed to have the workflow_call trigger setup. Then, the main workflow has all the real triggers + defines relationships between the jobs and matrixes on the high level. This top-level definition also contains alls-green and pypi-publish (due to trusted publishing limitations, it's not in a reusable workflow).

Having been using this approach for almost 2 years now, I find it a really good structure as it allows separating the abstraction layers which is good for the organization.

I like the modular design and applied it to the best of my knowledge. That should have been a separate PR, but ¯_(ツ)_/¯

[webknjaz]

Yeah, I thought you'd just add the new workflow that way and separate the rest...

I think you should resubmit this PR from a fork (actually, I think any topic branches should live outside upstream but that's a separate topic).

I'm concerned about most of the jobs not having their permissions settings. And I think they might have higher privileges within upstream but when a contributor comes in, they'd break. So I'd rather test that right away.

[jakob-keller]

Yeah, I thought you'd just add the new workflow that way and separate the rest...

Reverted all but the new workflow.

I think you should resubmit this PR from a fork (actually, I think any topic branches should live outside upstream but that's a separate topic).

I thought, I was doing that all along. Not sure what you mean?

I'm concerned about most of the jobs not having their permissions settings. And I think they might have higher privileges within upstream but when a contributor comes in, they'd break. So I'd rather test that right away.

I'm afraid, I don't follow you. But that relates to the other jobs, right?

[webknjaz]

Oh, I got confused reviewing from mobile. You're right. No need to resubmit.

[webknjaz]

I'm concerned about most of the jobs not having their permissions settings. And I think they might have higher privileges within upstream but when a contributor comes in, they'd break. So I'd rather test that right away.\n\nI'm afraid, I don't follow you. But that relates to the other jobs, right?

I thought that maybe that build job might have a difficulty uploading artifacts. But if the CI doesn't fail, than it's fine.

[webknjaz]

@jakob-keller I did something experimental, and you can now stop hosting an in-tree reusable workflow:

---

name: GitHub Actions Security Analysis with zizmor 🌈

on:  # yamllint disable-line rule:truthy
  push:
  pull_request:

jobs:
  zizmor:
    name: 🌈 zizmor

    permissions:
      security-events: write

    # yamllint disable-line rule:line-length
    uses: zizmorcore/workflow/.github/workflows/reusable-zizmor.yml@1ae473d8672fe7613e809d86d202a35063736e16

...

[jakob-keller]

@jakob-keller I did something experimental, and you can now stop hosting an in-tree reusable workflow:

---

name: GitHub Actions Security Analysis with zizmor 🌈

on:  # yamllint disable-line rule:truthy
  push:
  pull_request:

jobs:
  zizmor:
    name: 🌈 zizmor

    permissions:
      security-events: write

    # yamllint disable-line rule:line-length
    uses: zizmorcore/workflow/.github/workflows/reusable-zizmor.yml@1ae473d8672fe7613e809d86d202a35063736e16

...

Picked this up in #1355