Github action to update FLS every 24 hours #191
Conversation
✅ Deploy Preview for scrc-coding-guidelines ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
| - name: Install uv | ||
| uses: astral-sh/setup-uv@v6 | ||
| - name: Update FLS | ||
| run: "./make.py --update-spec-lock-file" |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Oh interesting, my thought was that we open the PR if there are changes, and let the human decides if the PR affects guidelines.
There was a problem hiding this comment.
I'll poke at this with a view to checking the normal build first, but not till next week.
There was a problem hiding this comment.
@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 :)
There was a problem hiding this comment.
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: Install uv | ||
| uses: astral-sh/setup-uv@v6 | ||
| - name: Update FLS | ||
| run: "./make.py --update-spec-lock-file" |
There was a problem hiding this comment.
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.
|
Given #195 has been merged, maybe it's a good idea to revert the second commit? |
I did look at Dependabot, but I don't think it quite works for this scenario.