On Fri, Feb 03, 2023 at 08:23:05AM +0900, Akira Yokosawa wrote: > 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. Apologies, I left it untracked. There is now a Leonardo.2023.02.01a branch that references it. Thanx, Paul