Hi, On Thu, 02 Feb 2023 13:52:08 -0300, Leonardo Brás wrote: > On Thu, 2023-02-02 at 23:42 +0900, Akira Yokosawa wrote: >> On Thu, 02 Feb 2023 01:37:02 -0300, Leonardo Brás wrote: >> [...] >>> >>> It looks like it can be done by "Running CI/CD for external repositories". > > Nah, it looks like this won't work either. After my patch on top of master, it's > already warning about diverging repositories when I try to sync. > > Another solution I could find: > - Change the patch I sent before to keep the file on another directory, even > with a different name: this will not trigger the build for anyone. > - Change my repository config to trigger the CI from that file. > > The file would only be a random YML file in the repo. > Would that be ok? Hmm, yes, I think I can live with it. > >>> >>> I removed my previous repository and then imported perfbook again using the >>> above mentioned mode. According to the man page, it will run CI for the project >>> whenever a new push to the referenced repository happens. >>> >>> So it's just a matter of waiting a new commit getting push'ed to see if it will >>> be working. >> >> Hi Leonardo, >> >> I noticed a minor glitch in the generated PDFs. >> They don't have Git commit info in the title page and footer area of >> pages. >> >> I can't tell what went wrong, but expected autodate.tex should look like: > > I found it out: gitlab was doing a shallow clone, and the previous tag was not > in the commits, so I modified the Gitlab config so it does a complete clone of > the repository instead. Aha! The script has never tested under a shallow clone... Let me see if I can improve its behavior. > The last output of the pipeline seems to have been correct, please check: > https://gitlab.com/linux-kernel/perfbook/-/jobs/3705185694/artifacts/browse Apparently, the commit id does not make sense in Paul's repo. But the random YML file approach should resolve it. Thanks, Akira
