Skip to content
Open
Changes from all commits
Commits
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
25 changes: 25 additions & 0 deletions .github/workflows/update-fls.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
name: Update FLS
on:
schedule:
- cron: "05 0 * * *"
workflow_dispatch:
jobs:
update-fls:
runs-on: ubuntu-latest
steps:
- name: Check out the repo
uses: actions/checkout@v4
- name: Install uv
uses: astral-sh/setup-uv@v6
- name: Update FLS
run: "./make.py --update-spec-lock-file"
Copy link
Collaborator

@felix91gr felix91gr Aug 26, 2025

Choose a reason for hiding this comment

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

The one thing that worries me is whether this would open a PR if there are affected guidelines: https://github.com/rustfoundation/safety-critical-rust-coding-guidelines?tab=readme-ov-file#if-you-need-to-audit-the-difference

I'm assuming that perhaps this is skipping the next step depending on the return value of the command? And that in turn handles this edge case?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Copy link
Collaborator

Choose a reason for hiding this comment

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

Agreed with @felix91gr --

It's important to first attempt a normal build using ./make.py and if it fails due to FLS upstream being changed to determine:

  • if there are affected guidelines
  • or not

If there are no affected guidelines, I think it can proceed as you've written here with opening a PR for human review to update the spec lock file.

If there are affected guidelines, I think opening an issue highlighting which ones were affected would be amazing.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Oh interesting, my thought was that we open the PR if there are changes, and let the human decides if the PR affects guidelines.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'll poke at this with a view to checking the normal build first, but not till next week.

Copy link
Collaborator

Choose a reason for hiding this comment

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

@plaindocs I wonder if the script is capable of returning some kind of metadata that we can use from another program (like eg this automation) to know what the result was.

If not, perhaps that's a task to work on to as to enable easier automation :)

Copy link
Collaborator

Choose a reason for hiding this comment

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

Oh interesting, my thought was that we open the PR if there are changes, and let the human decides if the PR affects guidelines.

Gotcha. Here's my 2c:

We have linkage to the FLS which should be vetted when the coding guideline is merged, to help us understand if one is impacted. When we have tens or hundreds of guidelines I think we'd have to lean on this automatation more.

Hope what I wrote made sense.

- name: Create Pull Request
uses: peter-evans/create-pull-request@v4
with:
commit-message: Update FLS (automated PR)
title: Update FLS (automated PR)
body: Update FLS (automated PR)
base: main
labels: automated-pr
branch: update-fls
delete-branch: true