I don’t understand what it means to keep both staging and publish in “asf-site”. By definition, the asf-site branch is the live web-site and asf-staging is the staging web site. Are you talking about the build scripts or something?
I started to reply to this earlier today but got sidetracked with my day job. To be honest, I still prefer the repo per web site model but I am OK with any solution that: * is 100% consistent no matter which web site it is. * doesn’t require a Confluence page or Readme to locate the web site source for a project By consistent I mean that if it is using branches then the branch name follows a pattern such as asf-site-2.x and asf-staged-2.x even if we are only publishing a single version of the web site for the project. Ralph > On Jan 15, 2024, at 11:52 AM, Volkan Yazıcı <vol...@yazi.ci> wrote: > > Even though it wouldn't be of my preference, keeping both `staging` and > `publish` configuration in `asf-site` sounds like a middle ground I can > live with. I will appreciate it if you can adapt your existing changes (in > `logging-log4j-kotlin`, `logging-parent`, etc.) to comply with this, unless > you have already done so. > > On Mon, Jan 15, 2024 at 12:27 PM Piotr P. Karwasz <piotr.karw...@gmail.com> > wrote: > >> Hi Volkan, >> >> On Mon, 15 Jan 2024 at 11:07, Volkan Yazıcı <vol...@yazi.ci> wrote: >>>> * you can stage the website for a release with a simple: >>>> >>>> git checkout asf-staging >>>> git reset --hard asf-site >>>> unzip ... >>>> git push -f >>>> >>> >>> You can do the same in the existing setup too. You just need a `sed` >>> one-liner to adapt the `.asf.yaml` content: >>> >>> $ sed -i -e 's/^publish:/staging:/g' -e 's/^ whoami:.+/ :whoami: >>> asf-staging/g' asf.yaml >>> >>> Not to mention this is a detail that will be a part of the CI-based >> release >>> process. That is, no PMC member will need to recall or type any of these >>> `git`, `sed`, `unzip`, etc. commands to cut a release. >>> >>> Given I addressed your "quickly stage a website" concern, are we good? >> >> I agree with your objections on not **requiring** all `.asf.yaml` to >> be in sync. However I also don't see a reason not to have a `staging` >> configuration on the `asf-site` branch and a `publish` configuration >> on the `asf-staging` branch. >> >> I would prefer for the CI not to meddle with critical files such as >> `.asf.yaml`, especially if changes to these files are almost never >> required. >> >> Piotr >> >> PS: I removed the `publish` and `staging` sections on the main branch >> of `logging-parent` and the `github` section on the site branches. >>
