Updating repository to follow calng-format-wheel #88
Conversation
|
The PR is unfinished as GitHub action requires some changes, but there are some minor doubts about the code as it is. Header files added to the wheel. Why are they necessary for the wheel? Probably I'm overseeing something there. install(
DIRECTORY
${CMAKE_BINARY_DIR}/llvm/lib/clang/${CLANG_TIDY_VERSION_MAJOR}/include
DESTINATION clang_tidy/data/lib/clang/${CLANG_TIDY_VERSION_MAJOR}
)Visual Studio I don't use VS, but I assume this is useful here for whom uses it. set(config-subfolder "")
if(CMAKE_GENERATOR MATCHES "Visual Studio")
set(config-subfolder "Release")
endif()
set(clang-tidy-executable ${CMAKE_BINARY_DIR}/llvm/${config-subfolder}/bin/clang-tidy${CMAKE_EXECUTABLE_SUFFIX}) |
|
About GitHub action for release. I have some experience, but I prefer to ask Minor improvementsOS runnersClang-format-wheel uses Ubuntu:latest but not latest versions for macOS and windows. I would suggest (at least for this repo) moving all them to use latest, so deprecation OS runners don't affect. MacOS-12 is part of the workflows of this repo, and it's deprecated Issue. However, as you compile for Intel and Arm64 macOS, it will require maintenance sooner rather than later. Automatic workflow updates with dependent bot.There are a couple of PR from dependent bot #84 #85 #86. I can modify them manually in the PR, or you merge them and I pull them. Excluded OS compilationsSome of the combinations are commented, but we can use the strategy of clang-format-wheel repo. Additionally, modify the default answer to the simulation to false, so we skip them by default. About this PRThis part will take some time to be finished as there are a lot of small changes to test, running act with this workflow release leads to BSOD (expected as there are like 6 different targets to compile). I can add any of the previous modifications if you find them useful. Once the PR is merged, I would do a final test with a release of 19.1.6 for example. |
|
Looking good so far @CalebFuster, thanks!
Don't remember. If you're keen to know, have you looked at the git blame of the file? Maybe the adding commit has some notes.
Agree on moving to what is currently latest. I just generally try to avoid using the
I was hesitant to merge #86 since that potential for needing changes in the workflow. Same with #76, this has a very low compat score. So it would be great if you can trial those changes in your fork.
Not quite sure what you're saying here. Do you want to try to re-enable some currently commented combinations? |
tmp: Std folder to add files in repos for testing and other stuff. wheelhouse: Std output of builds with cibuildwheel. We can avoid to add them by mistake when debugging locally or with Docker IDE config folders: Everyone has their own way of doing things. Good to ignore configs
I found the reason the headers are need for some of the checks.
I wanted to remove the comment on the qemu combinadtion and run them conditionally as (clang-format workflow). However, the workflow was not conditional and it triggered all the combinations. About dependant bot, qemu is not use anyway so we can remove it in the meantime. About pypi upload, I will try tomorrow to test it against test pypi, but quite confident on it. |
Testing the release workflowI ran the workflow in my fork. All the combination passed, but the dist failed because I erased the line of removing the package before testing. (I will adrress this need of erase in another PR because this is going a bit out of my intended scope) I ran this part of the workflow and test the upload and I commented the other side of the workflow because it consumes a lot of github action time. (I had to change the name of the project to test as I don't have access to your test Pypi). Here is the tar.gz uploaded in my TestPypi PR ReadyFrom my side, the PR is ready. Now, both repos are in a similar state and fullfil #87 issue. I found some minor things that affect both repos and I should be able to solve it later (e.g. the need to erase to test). Release workflow still on shambles, I will purpose some improvements in a separate issue, but I want to do some testing prior because I'm not 100% sure. |
https://github.com/ssciwr/clang-tidy-wheel/actions/runs/12925505916/job/36052083672 Looks like my suspicion was correct. Not sure if that trusted uploader route is now mandatory? |
|
They are enforcing it and making it the default way to go, but support both ways right now. about Trusted Publishing - action-pypi-publish Then I can revert to token / pass. I didn't though about you needing to enabling in pypi Trusted Publishing for this repo |
|
I'll try switching tomorrow, failing that we could still revert to old mechanism, but looks like that'll go away soon engouh anyhow. |
|
When you want to test the Trusted publish, you can re-run only the failed upload and you won't need to wait run all the release workflow. This will reduce drastically waiting time and github computation time. |
Updated repository to follow ssciwr/clang-format-wheel to ease maintenance.
Update include: