Skip to content

Conversation

@lgritz
Copy link
Collaborator

@lgritz lgritz commented Feb 23, 2025

Old: Do a build with target 'clang-format', relying on our build system. But that means that we need to do the cmake config step, and need a bunch of dependencies set up so that the config doesn't fail.

New: Make a new run-clang-format.bash utility to issue the commands for the right files. No "build" is requred, and the only dependencies we need are the minimum it takes to run clang-format itself.

These changes reduce the approximate total elapsed time of a CI clang-format job from nearly 7:00 to around 0:45.

Also, I noticed that we never had been clang-format testing the .cpp and .h files in the testsuite itself. So enable that now, and commit the small amount of reformatting that it identified.

@lgritz
Copy link
Collaborator Author

lgritz commented Feb 25, 2025

Any objections?

@EmilDohne
Copy link
Contributor

EmilDohne commented Feb 26, 2025

Maybe not an objection but a suggestion, perhaps we could run clang-tidy first before any other builds trigger to avoid the whole CI running when that check already fails?

Especially now that clang-tidy only takes 45s

@lgritz
Copy link
Collaborator Author

lgritz commented Feb 26, 2025

Maybe not an objection but a suggestion, perhaps we could run clang-tidy first before any other builds trigger to avoid the whole CI running when that check already fails?

Especially now that clang-tidy only takes 45s

I'm not sure. When I do a push or submit a PR, I want to know if the formatting is ok, but also I want to know if the build succeeds and the testsuite works (across a bunch of different platforms). I'm not sure I want one of those failing to prevent me from knowing the status of the other, if you know what I mean.

But I'm interested in hearing others' opinions on this.

Maybe it would work if combined with some actions trickery that will post the fixes as a PR comment with a diff that can be accepted to amend the PR with a single click? (I think this is possible.)

@nrusch
Copy link
Contributor

nrusch commented Feb 26, 2025

When I do a push or submit a PR, I want to know if the formatting is ok, but also I want to know if the build succeeds and the testsuite works (across a bunch of different platforms). I'm not sure I want one of those failing to prevent me from knowing the status of the other, if you know what I mean.

100% agree with this. Formatted code should not be a blocker for functional validation when iterating on changesets.

@EmilDohne
Copy link
Contributor

EmilDohne commented Feb 26, 2025

My original intention for the comment was twofold, of which I now realize one might be irrelevant:

1: if the CI will fail anyways without a valid clang-tidy, it is wasteful to run the rest of the suite only to the have to rerun it. Although, since oiio uses github hosted runners I suppose this is not an issue
2: As a first time contributor you might not have clang-tidy setup to auto-format on change and it would be nice to see front and center that that is a requirement. As a long time/frequent contributor you likely have it set up to auto format so it is unlikely the CI will ever fail.

I do understand your concerns though and it is a fair point that the clang-tidy blocking the rest of the checks is a bit unfortunate.

As a compromise solution I could come up with, especially for first time contributors, is that clang-tidy always runs and does not need explicit approval from a collaborator to kick off. That way, if theyre part of the first group they could iterate and chip away at those errors faster.
It has been a while since I contributed to here outside of comments but iirc CI requires explicit approval to run

@lgritz
Copy link
Collaborator Author

lgritz commented Feb 26, 2025

There are some actions in the GHA marketplace (or maybe we can roll our own) that do the clang-format operation and then can post a PR comment, which the original poster can accept and have the PR amended. I think that can be an effective way to remove the burden from first-time contributors not knowing that/how they should format the code before submission.

@EmilDohne
Copy link
Contributor

I think that would be a good addition (albeit as a different MR)

Old: Do a build with target 'clang-format', relying on our build
system.  But that means that we need to do the cmake config step, and
need a bunch of dependencies set up so that the config doesn't fail.

New: Make a new run-clang-format.bash utility to issue the commands
for the right files. No "build" is requred, and the only dependencies
we need are the minimum it takes to run clang-format itself.

Also, I noticed that we never had been clang-format testing the .cpp
and .h files in the testsuite itself. So enable that now, and commit
the small amount of reformatting that it identified.

These changes reduce the approximate total elapsed time of a CI
clang-format job from nearly 7:00 to 0:35.

Signed-off-by: Larry Gritz <[email protected]>
@lgritz
Copy link
Collaborator Author

lgritz commented Feb 28, 2025

No objections voiced, merging.

The CI failure in the Windows test is happening in all branches and is unrelated to this PR, so I'm not going to let that hold me up. (It looks like the GH Windows 2022 runner updated its MSVS version yesterday.)

@lgritz lgritz merged commit a9c3dd6 into AcademySoftwareFoundation:main Feb 28, 2025
67 of 68 checks passed
@lgritz lgritz deleted the lg-clangformat branch February 28, 2025 21:32
scott-wilson pushed a commit to scott-wilson/OpenImageIO that referenced this pull request May 17, 2025
Old: Do a build with target 'clang-format', relying on our build system.
But that means that we need to do the cmake config step, and need a
bunch of dependencies set up so that the config doesn't fail.

New: Make a new run-clang-format.bash utility to issue the commands for
the right files. No "build" is requred, and the only dependencies we
need are the minimum it takes to run clang-format itself.

These changes reduce the approximate total elapsed time of a CI
clang-format job from nearly 7:00 to around 0:45.

Also, I noticed that we never had been clang-format testing the .cpp and
.h files in the testsuite itself. So enable that now, and commit the
small amount of reformatting that it identified.

Signed-off-by: Larry Gritz <[email protected]>
Signed-off-by: Scott Wilson <[email protected]>
scott-wilson pushed a commit to scott-wilson/OpenImageIO that referenced this pull request May 18, 2025
Old: Do a build with target 'clang-format', relying on our build system.
But that means that we need to do the cmake config step, and need a
bunch of dependencies set up so that the config doesn't fail.

New: Make a new run-clang-format.bash utility to issue the commands for
the right files. No "build" is requred, and the only dependencies we
need are the minimum it takes to run clang-format itself.

These changes reduce the approximate total elapsed time of a CI
clang-format job from nearly 7:00 to around 0:45.

Also, I noticed that we never had been clang-format testing the .cpp and
.h files in the testsuite itself. So enable that now, and commit the
small amount of reformatting that it identified.

Signed-off-by: Larry Gritz <[email protected]>
Signed-off-by: Scott Wilson <[email protected]>
lgritz added a commit to lgritz/OpenImageIO that referenced this pull request May 20, 2025
Old: Do a build with target 'clang-format', relying on our build system.
But that means that we need to do the cmake config step, and need a
bunch of dependencies set up so that the config doesn't fail.

New: Make a new run-clang-format.bash utility to issue the commands for
the right files. No "build" is requred, and the only dependencies we
need are the minimum it takes to run clang-format itself.

These changes reduce the approximate total elapsed time of a CI
clang-format job from nearly 7:00 to around 0:45.

Also, I noticed that we never had been clang-format testing the .cpp and
.h files in the testsuite itself. So enable that now, and commit the
small amount of reformatting that it identified.

Signed-off-by: Larry Gritz <[email protected]>
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.

3 participants