Skip to content

Conversation

@blackboxsw
Copy link
Collaborator

Process improvement moving some of our Tiobe TICS automation out of Jenkins and into GH actions.
Scheduling weekly reports from GH workflows will allow us to retire an internal cloud-init jenkins job.

Proposed Commit Message

test: add gh workflow for tiobe TICS static analysis reporting

Additional Context

Test Steps

Merge type

  • Squash merge using "Proposed Commit Message"
  • Rebase and merge unique commits. Requires commit messages per-commit each referencing the pull request number (#<PR_NUM>)

@blackboxsw blackboxsw requested a review from Copilot January 6, 2026 22:18
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull request overview

This PR adds a GitHub Actions workflow to automate weekly Tiobe TICS static analysis reporting, migrating this functionality from Jenkins to enable retirement of an internal Jenkins job.

Key changes:

  • Introduces a new weekly scheduled workflow for TICS static analysis
  • Configures the workflow to run on self-hosted runners with specific requirements
  • Sets up dependency installation, coverage generation, and TICS analysis execution

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@blackboxsw blackboxsw requested a review from holmanb January 6, 2026 22:20

- name: Coverage
run: |
make coverage
Copy link
Member

Choose a reason for hiding this comment

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

?

Copy link
Member

Choose a reason for hiding this comment

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

No such make target exists in this repo.

Copy link
Collaborator Author

@blackboxsw blackboxsw Jan 7, 2026

Choose a reason for hiding this comment

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

Thanks, I hadn't committed changes for this stage to create TICS coverage artifacts. I've adapted them now from our server-jenkins/cloud-init/other job Link corrected for server-jenkins-job

Copy link
Member

Choose a reason for hiding this comment

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

Thanks, I hadn't committed changes for this stage to create TICS coverage artifacts. I've adapted them now from our server-jenkins/cloud-init/other job

wrong link?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Link corrected for server-jenkins-job

@holmanb holmanb self-assigned this Jan 8, 2026
Copy link
Member

@holmanb holmanb left a comment

Choose a reason for hiding this comment

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

Thanks for the clarifications @blackboxsw. I just added more feedback.

Comment on lines +39 to +42
- name: Generate TICS artifacts
run: |
mkdir .cover
python3 -m pytest --cov=cloudinit --cov-report=xml:.cover/coverage.xml || true
Copy link
Member

Choose a reason for hiding this comment

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

This is the wrong file name.

Why are we installing tox but not using it? I suspect we might not need wireguard or ubuntu-dev-tools either. I'd say that we should use just tox or just the read-dependencies script, but not both. And I lean towards tox's simplicity over depending on a home-grown script but I'll leave it up to you.

on:
workflow_dispatch:
schedule:
- cron: '17 5 * * 6' # Run at 5:17a (arbitrary) on Saturday
Copy link
Member

Choose a reason for hiding this comment

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

In which timezone?

Comment on lines +14 to +15
# Best practices per https://library.canonical.com/corporate-policies/
# information-security-policies/ssdlc/ssdlc---static-code-analysis
Copy link
Member

Choose a reason for hiding this comment

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

Since the doc applies to the whole file the top of the file seems like a more appropriate location.

Can we please not break the link?

Including "Best practices per" is unnecessary: it doesn't add value over just the link.

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.

2 participants