Le mar. 27 avr. 2021 à 12:32, sebb <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 > > 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? > we would need to ensure that the existing site is removed from SVN > before trying to replace it with one from Git. That's why we should be able to test the full set of options. Is it possible to "publish" to some place that would not interfere with the current setup (and its adapting to INFRA's requirements)? Could we perhaps use the "subdir" feature (see below the copy/paste of INFRA's instructions) in order to publish to an alternative page: https://commons.apache.org -> current top-level (still using SVN) https://commons.apache.org/git-site-commons -> alternative top-level (testing ".asf.yaml", publishing to given "sudir") https://commons.apache.org/math -> current site for component (using SVN) https://commons.apache.org/git-site-math -> component's alternative site If the git top-level site is not created yet (due to lack of time or deciding it's not worth it), links from the alternative site would point to the current top-level, but that would still allow each component to independently test (at its own pace) the move to "git". > > > > > > == > > > > > > If there is a desire to use Git for the component websites, I suggest > > > you try creating a couple of branches in the commons-math repository: > > > asf-staging and asf-site. > > > > > > See if it is easy to create the staging site and then commit it to the > > > asf-site branch. > > > > Did I misunderstand that the above documentation assumes a > > dedicated "git" repository for the web site's contents? > > Not sure what documentation you are referring to. >From the link above, here is the part that concerns web sites publication: ---CUT--- Web Site Deployment Service for Git Repositories The staging and publish features of the .asf.yaml file in a git repository manages web site deployment. NOTE : Web site staging and publishing features are applied using the repository in which you have specified staging and publishing . Thus, only specify it within the repository that contains your web site material, or you could end up just seeing a list of source code files from your source repository. Primer A basic staging and publishing profile to get you started could be: # Staging and publishing profile for yourproject-website.git: staging: profile: ~ whoami: asf-staging publish: whoami: asf-site This configuration enables a staging (live preview) web site at yourproject.staged.apache.org using the asf-staging branch of your repository, as well as deploying the asf-site branch of the repository to your main web site at yourproject.apache.org. Details below: Staging a web site preview domain To enable staging (live preview) of your project's web site, add a staging entry to the site repository's .asf.yaml file. As an example, take the imaginary yourproject-website.git with an .asf.yaml file containing the following entry: staging: profile: beta This would stage the current branch at https://yourproject-beta.staged.apache.org/ . You can add multiple staging profiles and thus multiple branches staged for preview. This can be helpful when doing A/B evaluations of website contents and features. You can also omit the profile value, and stage directly at https://yourproject.staged.apache.org/ . ( "~" (tilde) means "no value" in YAML): staging: profile: ~ Preventing branch-override on cloning a branch Set a protection on multi-tenancy by specifying a whoami setting. If the setting's value does not match the current branch, no checkout/update will happen. You can have this in the .asf.yaml file on the asf-staging branch: staging: profile: ~ whoami: asf-staging When you clone that branch to a new branch like asf-staging-copy, the staging web site server will notice that the value of whoami does not match asf-staging-copy, and will ignore that branch until the whoami is updated to match it. Publishing a branch to your project web site Note: if you have previously used gitwcsub for web site publishing, your first publish action using .asf.yaml will cause any existing gitwcsub or svnwcsub subscription to stop working. This ensures that there are no race conditions or "repository fights" going on when you publish. To publish a branch to your project web site sub-domain (yourproject.apache.org), set up a configuration block called publish in your .asf.yaml file. Enable branch-protection through the whoami parameter, like so: publish: whoami: asf-site If, for whatever reason, a project wishes to revert back to gitwcsub for publishing, remove the publish feature in your .asf.yaml file. Specifying a non-apache.org hostname By default, web sites will be published at $project.apache.org where $project is the sub-domain name of your project, as determined by the repository name. Some projects have special domains, like openoffice.org, and may publish to these by specifying a hostname attribute in the publish configuration block: publish: whoami: asf-site hostname: www.openoffice.org NOTE: You cannot specify your $project.apache.org hostname with this setting. It has to be inferred to prevent abuse. Also, please do not abuse this feature, thanks! Specifying a sub-directory to publish to To publish to a sub-directory of the web site URL, specify a subdir value. Such checkouts can be useful for sub-projects. For instance, if httpd wished to check out a repository into httpd.apache.org/subproject, they could use the following configuration: publish: whoami: asf-site subdir: subproject CMS/pelican sub-directories for static output The staging and deployment servers support both the content/ sub-dir and the pelican build output/ sub-dir as the root directory for the web site. Thus, the website root can be any of: The root of the git branch The content/ directory at the root of the branch The output/ directory at the root of the branch ---CUT--- > > But AFAIK it does not matter if there is a separate Git repo with the > asf-site and asf-staging branches, just as long as they can be > separately checked out. Perhaps; however isn't it a step towards more flexibility? [E.g. if one wants to use alternative tools for generating the HTML files.] > > Or is this suggested only for an overhaul of how the sites are > > built? I.e. do we need/want something like > > https://gitbox.apache.org/repos/asf?p=logging-site.git > > https://gitbox.apache.org/repos/asf?p=logging-log4j-site.git;a=tree > > or not? > > > > Strangely, there is something there: > > https://commons.staged.apache.org/ > > That is part of the CMS, and will be going away. ? This is part of the setup that uses ".asf.yaml" (cf. doc). > > > > > > I suspect it won't be significantly easier than the current process. > > > > > > However do *not* publish the asf-site branch as that will likely mess > > > up the commons website; this may require Infra involvement to recover > > > things. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
