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
