To close the loop on this, the website automation is now live!

Any changes to the mesos repo will trigger the Mesos-Websitebot CI job that
builds and publishes an updated website that gets reflected on
http://mesos.apache.org

Enjoy!

On Tue, Jun 13, 2017 at 12:24 PM, Vinod Kone <vinodk...@apache.org> wrote:

> This process has started. Tracking ticket: https://issues.apache.
> org/jira/browse/INFRA-14289
>
> Please avoid doing any commits to the *svn repo* until further notice.
>
>
>
> On Fri, Jun 2, 2017 at 4:21 AM, Timothy Anderegg <
> timothy.ander...@gmail.com> wrote:
>
>> Ah, that makes more sense, thanks!
>>
>> On Fri, Jun 2, 2017 at 12:57 AM Vinod Kone <vinodk...@gmail.com> wrote:
>>
>> > Tim, with the 2 repo option, the idea is that the source of the website
>> > will still reside in the main repo even if we keep the publish contents
>> in
>> > a different repo.
>> >
>> > @vinodkone
>> >
>> > > On Jun 1, 2017, at 8:42 PM, Timothy Anderegg <
>> timothy.ander...@gmail.com>
>> > wrote:
>> > >
>> > > Just to chime in, I'm almost done with the changes to the website code
>> > that
>> > > allows the user to select the version of documentation they wish to
>> see
>> > > (haosdent is reviewing the final revisions), and it does depend on
>> using
>> > > git to checkout the previous versions of the website via tags, so if
>> we
>> > did
>> > > isolate the website code to a specific branch or repo, we would also
>> need
>> > > to ensure that the tags of commits to the website code stay in sync
>> with
>> > > tags of commits to the actual code.  This would not be too
>> challenging,
>> > but
>> > > something to keep in mind.
>> > >
>> > > Keeping the website code in a separate repository might be easier to
>> > manage
>> > > from this perspective, since tags are effectively global to a given
>> repo,
>> > > so if we kept the website code in a special branch within the main
>> repo,
>> > > we'd need something like a tag called "1.3.0" for the main code, and
>> > > "website-1.3.0" for the website code, which could be confusing.
>> > >
>> > >> On Thu, Jun 1, 2017 at 8:53 PM Vinod Kone <vinodk...@gmail.com>
>> wrote:
>> > >>
>> > >> Thanks for the analysis Benjamin. Really appreciate it.
>> > >>
>> > >> You bring up good points esp about size bump for supporting multiple
>> > >> versions.
>> > >>
>> > >> Btw, do the numbers change if publish content is only in a branch ?
>> > Guess
>> > >> not?
>> > >>
>> > >> Maybe we can start with a separate git repo and see if it's painful
>> > enough
>> > >> to merge it into our source repo.
>> > >>
>> > >> @vinodkone
>> > >>
>> > >>> On Jun 1, 2017, at 4:06 PM, Benjamin Bannier <
>> > >> benjamin.bann...@mesosphere.io> wrote:
>> > >>>
>> > >>> Hi Vinod,
>> > >>>
>> > >>>> *Implementation details: *
>> > >>>>
>> > >>>> We have an option to move to
>> > >>>> 1) a standalone git repo (say "mesos-site") which will be mirrored
>> on
>> > >>>> github.
>> > >>>> 2) just use our "mesos" git repo and publish a "asf-site" branch
>> with
>> > >>>> website contents (say at 'site/publish' directory)
>> > >>>>
>> > >>>> I'm leaning towards 2) because that allows us to deal with single
>> repo
>> > >>>> instead of two.
>> > >>>
>> > >>> I have never updated the website so I cannot comment on the pain
>> > >> involved.
>> > >>>
>> > >>> As a user of the Mesos source git repository I would however like to
>> > >> bring up that _all_ of the website’s assets are generated from files
>> > >> present in the source repository (at some point in time). The largest
>> > >> fraction of the `publish` directory is Doxygen documentation
>> (currently
>> > >>> 90% at ~100 MB). We should weigh the effect this would have for
>> > developers
>> > >> should we add this content to the Mesos source repository.
>> > >>>
>> > >>> To get a ballpark idea I imported the website’s history into a git
>> > >> repository. After the initial import its `.git` directory contained
>> > ~100 MB
>> > >> which went down to ~30MB after aggressive repository repacking. A
>> fresh
>> > >> clone of the Mesos source repository amounts to ~280 MB, so it seems
>> we
>> > >> would add at least 10% to the repositories size with little benefit
>> to
>> > >> developers. Depending on the implementation, this number would likely
>> > >> increase would we e.g., provide version-dependent website content, or
>> > >> introduce website asset formats not compressing as nicely with git
>> > (e.g.,
>> > >> generated graphics).
>> > >>>
>> > >>> I have the feeling keeping this content in a separate repository
>> might
>> > >> strike a better balance for developers.
>> > >>>
>> > >>>
>> > >>> Benjamin
>> > >>>
>> > >>
>> >
>>
>
>

Reply via email to