fix: the configuration must not be used as temporary storage #849
Labels
No labels
FreeBSD
Kind/Breaking
Kind/Bug
Kind/Chore
Kind/DependencyUpdate
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
Windows
linux-powerpc64le
linux-riscv64
linux-s390x
run-end-to-end-tests
run-forgejo-tests
No milestone
No project
No assignees
5 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
forgejo/runner!849
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "earl-warren/runner:wip-valid-volumes"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
rc.Config should be treated as read-only and not as a temporary storage for the variable list of valid volumes for containers sharing this configuration.
Refs forgejo/runner#848
f9a509e75228d0a596a9It is unclear if this is the root cause of #848, but is certainly is a source of problems.
WIP: fix: the configuration must not be used as temporary storage [skip cascade]to fix: the configuration must not be used as temporary storage [skip cascade]this might fix the rather frequent (once every 5 or 10 runs at least) false negative from #848
28d0a596a982cf344f51fix: the configuration must not be used as temporary storage [skip cascade]to fix: the configuration must not be used as temporary storage82cf344f513ab438ae41cascading-pr updated at actions/setup-forgejo#592
It seems
ValidVolumes []string // only volumes (and bind mounts) in this slice can be mounted on the job container or service containerscan be removed as well?
Gusted's comment about
ValidVolumesno longer being necessary on the Config object seems right at a glance; other than that this change makes sense to me.I was curious, since I've never used it before, and I did a little test for whether the data race detector would identify this condition. It does... and there are a few other data races identified. After this fix, is there value in pursuing those, eliminating them, and maybe enabling data race detection during tests? I'd volunteer to try, as long as nobody would advise against it (eg. based upon their experience, if the data race detector isn't a valuable tool or the resource usage is too high to justify, etc.?).
eg.
@mfenniak wrote in #849 (comment):
I have no experience using this tool and since it caught this one (which was painful to figure out), I'd say there is value in it. Maybe @Gusted did some work with that and has more experience.
@mfenniak wrote in #849 (comment):
I'm afraid to look... very cowardly of me.
@Gusted wrote in #849 (comment):
It is set from the runner configuration value
[container].valid_volumeshttps://forgejo.org/docs/next/admin/actions/runner-installation/#configuration
ValidVolumes: r.cfg.Container.ValidVolumes,@earl-warren wrote in #849 (comment):
The race detector can be quite useful, but it's proportional to the amount of tests that make sure concurrent work is being done.
viceice-bot referenced this pull request2025-08-18 00:10:15 +00:00
viceice-bot referenced this pull request2025-08-18 00:31:54 +00:00
viceice-bot referenced this pull request2025-08-18 01:02:08 +00:00
viceice-bot referenced this pull request2025-08-18 01:31:08 +00:00
viceice-bot referenced this pull request2025-08-18 02:01:42 +00:00
viceice-bot referenced this pull request2025-08-18 02:31:02 +00:00
viceice-bot referenced this pull request2025-08-18 03:01:42 +00:00
viceice-bot referenced this pull request2025-08-18 03:31:00 +00:00
viceice-bot referenced this pull request2025-08-18 04:01:39 +00:00
viceice-bot referenced this pull request2025-08-18 04:31:00 +00:00
viceice-bot referenced this pull request2025-08-18 05:02:28 +00:00
viceice-bot referenced this pull request2025-08-18 05:31:15 +00:00