Skip to content
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.

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

Sync summary times #3233

Merged
merged 2 commits into from
May 2, 2024
Merged

Conversation

dbnicholson
Copy link
Member

I was looking into an HTTP caching issue in a different project and it occurred to me that there's no reason the summary and summary.sig files can't have synchronized mtimes since they're now created in a temporary directory. The first commit is unrelated and I can split it out if preferred.

The skip shell function is for skipping an entire test plan. To skip a
single test result, a directive is needed[1]. Without this change, the
test suite errors claiming that 2 test plans were provided when fsverity
isn't available.

1. https://testanything.org/tap-specification.html#skipping-tests
HTTP servers derive Last-Modified from the modification time of the
file. When used in combination with a Cache-Control max-age value,
having the modification times match means that caches will consider them
expired at the same time. This helps make it more likely that clients
won't receive a cached summary and fresh signature or vice versa.

This makes more sense to do now that the summary and signature are
created in a temporary directory and renamed into place. In the old days
where they were created directly in the repo root, it would be strange
to change the summary mtime when it wasn't actually modified.
@dbnicholson
Copy link
Member Author

Oof, forgot about clang-format. Can't say I agree with it's decision, but I will appease it.

@dbnicholson
Copy link
Member Author

Looks like clang-format in rawhide or whatever (clang 18?) disagrees with older versions. I think this is WRT to AlignOperands and BreakBeforeBinaryOperators.

@dbnicholson
Copy link
Member Author

Should I just override the failure? It's in a part of code that I didn't touch and I don't know how to get different versions of clang-format to agree on what the right thing is:

[2024-04-25T15:39:35.622Z] checking clang-format... src/libostree/ostree-sysroot.c:2241:56: error: code should be clang-formatted [-Wclang-format-violations]
[2024-04-25T15:39:35.622Z]                   ? _ostree_sysroot_get_runstate_path (
[2024-04-25T15:39:35.622Z]                                                        ^
[2024-04-25T15:39:35.622Z] src/libostree/ostree-sysroot.c:2243:56: error: code should be clang-formatted [-Wclang-format-violations]
[2024-04-25T15:39:35.622Z]                   : _ostree_sysroot_get_runstate_path (
[2024-04-25T15:39:35.622Z]                                                        ^

Possibly ci/codestyle.sh should only be run from one target so there's only one version of clang-format in use.

@cgwalters
Copy link
Member

Possibly ci/codestyle.sh should only be run from one target so there's only one version of clang-format in use.

Yeah, this has bit us at least twice in the past I believe. It's so messy...even if we pick just one target we force everyone to use that specific version which is not great.

For now...yes I'll follow up to drop the clang-format from everything except just one OS version.

@cgwalters cgwalters merged commit fa720d1 into ostreedev:main May 2, 2024
23 of 24 checks passed
@dbnicholson dbnicholson deleted the sync-summary-times branch May 2, 2024 00:25
@dbnicholson
Copy link
Member Author

Yeah, this has bit us at least twice in the past I believe. It's so messy...even if we pick just one target we force everyone to use that specific version which is not great.

I was thinking the same thing. A simple thing would be a wrapper script that runs clang-format using a container image for whatever is the agreed upon target. Then it would be simpler for developers to match whatever was going to happen in CI. My gut says rawhide because that's always going to have the most recent clang version, but there might be too much chance of random distro breakage.

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