It occurs to me that we *should* create a specific "git" repository for holding web site contents; having the "asf-site" and "asf-staging" branches in the component's repository is looking for trouble: It will be too easy to commit the (generated) web files into "master" instead of the appropriate branch. [If allowed (even recommended as per the doc) by INFRA, we should not frown upon the increased separation of concern (source code vs web site management).]
"Logging" has one repository for the top-level site and a separate repository for every component. IMO, we should do the same (and copy their ".asf.yaml" layout). Until we make the git switch for the live top-level site, we would indeed (as you proposed) not have a "publish" section in any of the ".asf.yaml" files (in any of the repositories); we'd only use the "staging" section that will make the site accessible at https://commons.staged.apache.org Any objection to creating the following repositories: commons-site.git commons-math-site.git ? Gilles Le mer. 28 avr. 2021 à 00:39, sebb <seb...@gmail.com> a écrit : > > On Tue, 27 Apr 2021 at 17:03, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > > > > > > > > On Apr 27, 2021, at 6:57 AM, Gilles Sadowski <gillese...@gmail.com> wrote: > > > > > > Le mar. 27 avr. 2021 à 12:32, sebb <seb...@gmail.com > > > <mailto:seb...@gmail.com>> a écrit : > > >> > > >> On Tue, 27 Apr 2021 at 02:10, Gilles Sadowski <gillese...@gmail.com> > > >> wrote: > > >>> > > >>>>>> [...] > > >>>>> > > >>>>> OK to create the > > >>>>> commons-site > > >>>>> "git" repository? > > >>>> > > >>>> Are you offering to do the work? > > >>> > > >>> If the option is still on the table, I could test the > > >>> website-related feature of ".asf.yaml": > > >>> > > >>> https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-BranchProtection > > >> > > >> Please do NOT attempt to use the 'publish' feature. > > >> > > >> As I already wrote that will likely mangle the current website and may > > >> require Infa assistance to untangle. > > > > > > I certainly do not want to do that. > > > > > >> Removal of a publish entry from .asf.yaml does not undo the checkout, > > >> and only Infra have direct access to the TLP server. > > > > > > Alas, there is a limit to INFRA's magics... ;-) > > > > > >> However, you could experiment with the 'staging' feature, and see how > > >> easy it is to publish the site to the asf-site branch. > > > > > > I must be missing something because I don't see what there is > > > to do then, apart from > > > $ git checkout asf-site > > > $ mvn site site:stage > > > > > > And, just as now, the functional (except perhaps for the links to > > > the top-level Commons site) static site will be under > > > target/staging > > > > > > > ASF git-based web sites use two branches; asf-site for the live site and > > asf-staging for the > > taged site. So when Sebb is telling you to work on the staging site only he > > means commit > > only to the asf-staging branch. > > > > > > >> > > >> Just don't attempt to publish that branch. > > >> > > >>>> > > >>>> BTW, I have found out that it is possible to combine site content from > > >>>> SVN and Git repos in order to create the website checkout. > > >>>> So there is no need to convert to Git. > > >>> > > >>> Is it the solution straightforwardly applicable to the current > > >>> setup of the Commons web site? [So that ".asf.yaml" should > > >>> not be used for the projects' sites.] > > >> > > >> AFAICT, yes. > > >> > > >> The website is currently taken from: > > >> > > >> https://svn-master.apache.org/repos/infra/websites/production/commons > > >> > > >> This is done as a single checkout. > > >> > > >> This could be changed to take the top-level website from its own > > >> location, and the dormant, sandbox and proper trees could be checked > > >> out into the relevant subdirectories. > > >> > > >> This should be fine so long as the top-level site does not have any > > >> files in those 3 subdirectories. > > >> > > >> For an example of this, go to > > >> https://infra-reports.apache.org/site-source/ > > >> and enter 'ant.apache.org' in the search box 'Find a web site' > > >> > > >> You should see 4 entries at different levels derived from different SVN > > >> URLs. > > >> Note that in each case the parent SVN tree does not have an entry for > > >> its children. > > >> E.g. The SVN location for ant.apache.org does not have a directory > > >> easyant or ivy. > > >> > > >> Note that .asf.yaml does not apply to SVN checkouts. > > >> > > >> If we were to determine that Git was better for the proper websites, > > > > > > How to do that without a playground for testing? > > > > > > You create a repo that only has an .asf.yaml in the asf-staging branch. > > Until you > > merge the asf-staging branch to the asf-site branch nothing will be live > > from it as it > > will not have an .asf.yaml file. > > Actually I *am* suggesting to try merging to the asf-site branch. > That is needed to explore the full process needed to move to Git > (apart from final publication) > > Of course it is vital that the .asf.yaml file does *not* have a > publish entry yet. > > If Commons does decide that Git is the way to go, at some point the > asf.yaml file publish entry can be added. > This will have to be carefully co-ordinated with the removal of the > existing SVN site to avoid mangling the site. > > > > > Ralph > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org