Fwd: [NOTICE] Introducing .asf.yaml for enhanced automation of git repository services

[Gilles Sadowski <gi...@gmail.com>]

Hi.

[Forwarding the following message, so that the discussion can take
place on the "dev" ML.]

---------- Forwarded message ---------
De : Daniel Gruno <hu...@apache.org>
Date: jeu. 5 sept. 2019 à 02:32
Subject: [NOTICE] Introducing .asf.yaml for enhanced automation of git
repository services
To: <co...@apache.org>


Hello, fellow Apache committers and enthusiasts!

Today, the Apache Infrastructure Team is launching new self-serve
features to help augment the productivity of Apache projects through a
series of simple configurations for enabling automation of various
service offerings.

We call this new initiative '.asf.yaml', and as the name implies, it
consists of a new file that projects can add to their git repositories
to control various aspects that were previously done through JIRA
tickets and manual operations by the Infrastructure staff.

For detailed information about these features and how to enable them,
please visit our documentation page at: https://s.apache.org/asfyaml

At launch time, .asf.yaml has three features enabled that projects can
make use of: web site staging, web site publishing, and github meta-data
settings:

web site staging:
   Much like with the Apache CMS system, projects using git can now get
   their web sites staged for previews at a specific (HTTPS-enabled)
   staging domain. Staging supports multi-tenancy, which allows for
   multiple staging web sites from different site repository branches.
   For more information on multi-tenancy, see the canonical documentation
   linked above.

web site publishing:
   Projects can now automatically set up publishing for their own main
   web site ($project.apache.org) and change at will, without the need to
   wait for assistance from the Infrastructure team. New podlings and
   projects can also get web sites bootstrapped and ready immediately.

github meta-data settings:
   Projects can now, via .asf.yaml, specify their repositories' meta-data
   on github, such as the description, homepage URL, and which topics to
   add to a repository's front page.

In the coming months, we will extend this feature with many new,
exciting features such as automated buildbot integration for web site
generation (think CMS but via git) and enhanced JIRA integration
automation.

We hope projects will appreciate and make use of these new features. If
you or your project have any questions, please feel free to reach out to
us at: users@infra.apache.org - but please read through the
documentation first :)

With regards, and on behalf of the Apache Infrastructure Team,
Daniel.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [NOTICE] Introducing .asf.yaml for enhanced automation of git repository services

[Gilles Sadowski <gi...@gmail.com>]

Hello.

> ---------- Forwarded message ---------
> De : Daniel Gruno <hu...@apache.org>
> Date: jeu. 5 sept. 2019 à 02:32
> Subject: [NOTICE] Introducing .asf.yaml for enhanced automation of git
> repository services
> To: <co...@apache.org>
>
>
> Hello, fellow Apache committers and enthusiasts!
>
> Today, the Apache Infrastructure Team is launching new self-serve
> features to help augment the productivity of Apache projects through a
> series of simple configurations for enabling automation of various
> service offerings.
>
> We call this new initiative '.asf.yaml', and as the name implies, it
> consists of a new file that projects can add to their git repositories
> to control various aspects that were previously done through JIRA
> tickets and manual operations by the Infrastructure staff.
>
> For detailed information about these features and how to enable them,
> please visit our documentation page at: https://s.apache.org/asfyaml
>
> At launch time, .asf.yaml has three features enabled that projects can
> make use of: web site staging, web site publishing, and github meta-data
> settings:
>
> web site staging:
>    Much like with the Apache CMS system, projects using git can now get
>    their web sites staged for previews at a specific (HTTPS-enabled)
>    staging domain. Staging supports multi-tenancy, which allows for
>    multiple staging web sites from different site repository branches.
>    For more information on multi-tenancy, see the canonical documentation
>    linked above.
>
> web site publishing:
>    Projects can now automatically set up publishing for their own main
>    web site ($project.apache.org) and change at will, without the need to
>    wait for assistance from the Infrastructure team. New podlings and
>    projects can also get web sites bootstrapped and ready immediately.
>
> github meta-data settings:
>    Projects can now, via .asf.yaml, specify their repositories' meta-data
>    on github, such as the description, homepage URL, and which topics to
>    add to a repository's front page.
>
> In the coming months, we will extend this feature with many new,
> exciting features such as automated buildbot integration for web site
> generation (think CMS but via git) and enhanced JIRA integration
> automation.
>
> We hope projects will appreciate and make use of these new features. If
> you or your project have any questions, please feel free to reach out to
> us at: users@infra.apache.org - but please read through the
> documentation first :)
>
> With regards, and on behalf of the Apache Infrastructure Team,
> Daniel.

I thus experimented with "Commons RNG"[1] and it didn't do what I
expected.

Quoting Daniel Gruno (from "infra"):
---CUT---
The .asf.yaml file controls staging and publishing for _the repository
you enable it in_, meaning it will attempt to stage commons-rng.git as
if it was a web site. If you do not currently have your web site in git,
then it will, as you note, just try to pull in the source code files and
list them. To start staging a web site, you would need to either put
your web site in a specific branch, such as asf-site, in the git repo,
and then tell .asf.yaml to use that branch, or you could create a new
repo, either commons-rng-website or commons-website (recommended), and
use that solely for web site material, then enable .asf.yaml's staging
features in that repository instead.

I will note that for commons, you will have to be a tad careful, as the
commons project has a lot of sub-projects, so you would need one git
repo that contains all of these project sites, as you would be
overriding commons.apache.org with whatever content you decide to
publish via .asf.yaml, should you decide to publish it through that.

My recommendation for commons, and other projects with multiple sources
for their web sites, is to wait and work out a strategy for combining
the sites into one web site repository, then carefully test via staging,
before any sort of publishing. You can of course also stick with the
current publishing methods you have, we are not mandating the use of
these new features.
---CUT---

Hence, are we interested to use this new feature, or do we stick
to the current way(s) of updating the web site(s)?

Regards,
Gilles

[1] Commit a506c3dd48346f9d0d106766729700c3b1229b2e

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org