Skip to content

Add qcom-preflight-checks #55

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.

Sign up for GitHub

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Add qcom-preflight-checks #55

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions .github/dependabots.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
# To get started with Dependabot version updates, you'll need to specify which
# package ecosystems to update and where the package manifests are located.
# Please see the documentation for all configuration options:
# https://docs.github.com/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file

version: 2
updates:
- package-ecosystem: "github-actions" # See documentation for possible values
directory: "/" # This points to .github/workflows
schedule:
interval: "daily"
24 changes: 24 additions & 0 deletions .github/workflows/qcom-preflight-checks.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
name: Qualcomm Preflight Checks
on:
pull_request_target:
branches: [ "main" ]
push:
branches: [ "main" ]
workflow_dispatch:

permissions:
contents: read
security-events: write

jobs:
qcom-preflight-checks:
uses: qualcomm/qcom-reusable-workflows/.github/workflows/[email protected]
with:
# ✅ Preflight Checkers
repolinter: true # default: true
semgrep: true # default: true
copyright-license-detector: true # default: true
pr-check-emails: true # default: true
dependency-review: true # default: true
secrets:
SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_APP_TOKEN }}
30 changes: 0 additions & 30 deletions .github/workflows/qualcomm-linux-organization-repolinter.yml
View file
Open in desktop

This file was deleted.

25 changes: 25 additions & 0 deletions .github/workflows/stale-issues.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
name: 'Close stale issues and pull requests with no recent activity'
on:
schedule:
- cron: "30 1 * * *"

permissions:
issues: write
pull-requests: write

jobs:
stale:
runs-on: ubuntu-latest
steps:
- uses: actions/stale@v9
Copy link
Contributor

Choose a reason for hiding this comment

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

why are we duplicating this job here instead of reusing https://github.com/qualcomm/qcom-reusable-workflows/blob/main/.github/workflows/stale-issues.yaml ? that would require updating the version in each repo. We could add input params for days-before-stale, .. so that the calling workflow can configure it?

Copy link
Author

Choose a reason for hiding this comment

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

Great suggestions! We'll review and incorporate them in the next release
FYI, @mynameistechno

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah potentially. The stale issues functionality is more of a recommendation/suggestion vs some of the other compliance/security checks in qcom preflight checks. When we added the stale issues workflow in the repo template, we didn't have the reusable workflow available to us as an option at the time ... so we could set it up similarly where folks can disable it and also pass inputs down to it etc.

When thinking about if this is something we'd generally like to have enabled across all our repos, I think the answer is yes. I think we can add it with some sane defaults that are not very aggressive. I do also kind of like the idea of having just one workflow file in the template repo :P

with:
stale-issue-message: 'This issue has been marked as stale due to 30 days of inactivity. To prevent automatic closure in 7 days, remove the stale label or add a comment. You can reopen a closed issue at any time.'
stale-pr-message: 'This pull request has been marked as stale due to 30 days of inactivity. To prevent automatic closure in 7 days, remove the stale label or add a comment. You can reopen a closed pull request at any time.'
exempt-issue-labels: bug,enhancement
exempt-pr-labels: bug,enhancement
days-before-stale: 30
days-before-close: 7
days-before-issue-close: -1
remove-stale-when-updated: true
remove-issue-stale-when-updated: true
remove-pr-stale-when-updated: true