You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@logging.apache.org by pk...@apache.org on 2023/12/27 07:50:11 UTC
(logging-log4j-kotlin) 01/01: Synchronize `.asf.yaml` between site branches
This is an automated email from the ASF dual-hosted git repository.
pkarwasz pushed a commit to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/logging-log4j-kotlin.git
commit ba7e51dee84af097e3246b84238997bc9173aa84
Author: Piotr P. Karwasz <pi...@karwasz.org>
AuthorDate: Wed Dec 27 08:49:51 2023 +0100
Synchronize `.asf.yaml` between site branches
---
.asf.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/.asf.yaml b/.asf.yaml
index 46afaa1..545694d 100644
--- a/.asf.yaml
+++ b/.asf.yaml
@@ -21,3 +21,8 @@ publish:
profile: ~
whoami: asf-site
subdir: content/log4j/kotlin
+
+staging:
+ profile: ~
+ whoami: asf-staging
+ subdir: content/log4j/kotlin
Re: [log4j] `.asf.yaml` between branches
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Jan 16, 2024, at 9:15 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>
>
>
>> On Jan 15, 2024, at 11:18 PM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>>
>> Hi Ralph,
>>
>> On Tue, 16 Jan 2024 at 01:56, Ralph Goers <ra...@dslextreme.com> wrote:
>>>
>>> I don’t understand what it means to keep both staging and publish in “asf-site”. By definition, the asf-site branch is the live web-site and asf-staging is the staging web site. Are you talking about the build scripts or something?
>>
>> We are talking about this `.asf.yaml` content:
>>
>> publish:
>> profile: ~
>> whoami: asf-site
>> subdir: content/logging-parent
>>
>> staging:
>> profile: ~
>> whoami: asf-staging
>> subdir: content/logging-parent
>>
>> Due to the `whoami` attribute, the `.asf.yaml` file on both the
>> `asf-site` and `asf-staging` branch can be the same. INFRA will ignore
>> the `staging` instruction on `asf-site` and the `publish` instruction
>> on `asf-staging`.
>
> Thanks. That makes sense then.
Actually, it almost HAS to be that way if you are going to be able to simply do a merge from staging to the publish branch to go live.
Ralph
Re: [log4j] `.asf.yaml` between branches
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Jan 15, 2024, at 11:18 PM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>
> Hi Ralph,
>
> On Tue, 16 Jan 2024 at 01:56, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>> I don’t understand what it means to keep both staging and publish in “asf-site”. By definition, the asf-site branch is the live web-site and asf-staging is the staging web site. Are you talking about the build scripts or something?
>
> We are talking about this `.asf.yaml` content:
>
> publish:
> profile: ~
> whoami: asf-site
> subdir: content/logging-parent
>
> staging:
> profile: ~
> whoami: asf-staging
> subdir: content/logging-parent
>
> Due to the `whoami` attribute, the `.asf.yaml` file on both the
> `asf-site` and `asf-staging` branch can be the same. INFRA will ignore
> the `staging` instruction on `asf-site` and the `publish` instruction
> on `asf-staging`.
Thanks. That makes sense then.
Ralph
Re: [log4j] `.asf.yaml` between branches
Posted by Gary Gregory <ga...@gmail.com>.
Should these files contain comments to this effect?
Gary
On Tue, Jan 16, 2024, 1:18 AM Piotr P. Karwasz <pi...@gmail.com>
wrote:
> Hi Ralph,
>
> On Tue, 16 Jan 2024 at 01:56, Ralph Goers <ra...@dslextreme.com>
> wrote:
> >
> > I don’t understand what it means to keep both staging and publish in
> “asf-site”. By definition, the asf-site branch is the live web-site and
> asf-staging is the staging web site. Are you talking about the build
> scripts or something?
>
> We are talking about this `.asf.yaml` content:
>
> publish:
> profile: ~
> whoami: asf-site
> subdir: content/logging-parent
>
> staging:
> profile: ~
> whoami: asf-staging
> subdir: content/logging-parent
>
> Due to the `whoami` attribute, the `.asf.yaml` file on both the
> `asf-site` and `asf-staging` branch can be the same. INFRA will ignore
> the `staging` instruction on `asf-site` and the `publish` instruction
> on `asf-staging`.
>
> Piotr
>
Re: [log4j] `.asf.yaml` between branches
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Ralph,
On Tue, 16 Jan 2024 at 01:56, Ralph Goers <ra...@dslextreme.com> wrote:
>
> I don’t understand what it means to keep both staging and publish in “asf-site”. By definition, the asf-site branch is the live web-site and asf-staging is the staging web site. Are you talking about the build scripts or something?
We are talking about this `.asf.yaml` content:
publish:
profile: ~
whoami: asf-site
subdir: content/logging-parent
staging:
profile: ~
whoami: asf-staging
subdir: content/logging-parent
Due to the `whoami` attribute, the `.asf.yaml` file on both the
`asf-site` and `asf-staging` branch can be the same. INFRA will ignore
the `staging` instruction on `asf-site` and the `publish` instruction
on `asf-staging`.
Piotr
Re: [log4j] `.asf.yaml` between branches
Posted by Ralph Goers <ra...@dslextreme.com>.
I don’t understand what it means to keep both staging and publish in “asf-site”. By definition, the asf-site branch is the live web-site and asf-staging is the staging web site. Are you talking about the build scripts or something?
I started to reply to this earlier today but got sidetracked with my day job.
To be honest, I still prefer the repo per web site model but I am OK with any solution that:
* is 100% consistent no matter which web site it is.
* doesn’t require a Confluence page or Readme to locate the web site source for a project
By consistent I mean that if it is using branches then the branch name follows a pattern such as asf-site-2.x and asf-staged-2.x even if we are only publishing a single version of the web site for the project.
Ralph
> On Jan 15, 2024, at 11:52 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
>
> Even though it wouldn't be of my preference, keeping both `staging` and
> `publish` configuration in `asf-site` sounds like a middle ground I can
> live with. I will appreciate it if you can adapt your existing changes (in
> `logging-log4j-kotlin`, `logging-parent`, etc.) to comply with this, unless
> you have already done so.
>
> On Mon, Jan 15, 2024 at 12:27 PM Piotr P. Karwasz <pi...@gmail.com>
> wrote:
>
>> Hi Volkan,
>>
>> On Mon, 15 Jan 2024 at 11:07, Volkan Yazıcı <vo...@yazi.ci> wrote:
>>>> * you can stage the website for a release with a simple:
>>>>
>>>> git checkout asf-staging
>>>> git reset --hard asf-site
>>>> unzip ...
>>>> git push -f
>>>>
>>>
>>> You can do the same in the existing setup too. You just need a `sed`
>>> one-liner to adapt the `.asf.yaml` content:
>>>
>>> $ sed -i -e 's/^publish:/staging:/g' -e 's/^ whoami:.+/ :whoami:
>>> asf-staging/g' asf.yaml
>>>
>>> Not to mention this is a detail that will be a part of the CI-based
>> release
>>> process. That is, no PMC member will need to recall or type any of these
>>> `git`, `sed`, `unzip`, etc. commands to cut a release.
>>>
>>> Given I addressed your "quickly stage a website" concern, are we good?
>>
>> I agree with your objections on not **requiring** all `.asf.yaml` to
>> be in sync. However I also don't see a reason not to have a `staging`
>> configuration on the `asf-site` branch and a `publish` configuration
>> on the `asf-staging` branch.
>>
>> I would prefer for the CI not to meddle with critical files such as
>> `.asf.yaml`, especially if changes to these files are almost never
>> required.
>>
>> Piotr
>>
>> PS: I removed the `publish` and `staging` sections on the main branch
>> of `logging-parent` and the `github` section on the site branches.
>>
Re: [log4j] `.asf.yaml` between branches
Posted by Volkan Yazıcı <vo...@yazi.ci>.
Even though it wouldn't be of my preference, keeping both `staging` and
`publish` configuration in `asf-site` sounds like a middle ground I can
live with. I will appreciate it if you can adapt your existing changes (in
`logging-log4j-kotlin`, `logging-parent`, etc.) to comply with this, unless
you have already done so.
On Mon, Jan 15, 2024 at 12:27 PM Piotr P. Karwasz <pi...@gmail.com>
wrote:
> Hi Volkan,
>
> On Mon, 15 Jan 2024 at 11:07, Volkan Yazıcı <vo...@yazi.ci> wrote:
> > > * you can stage the website for a release with a simple:
> > >
> > > git checkout asf-staging
> > > git reset --hard asf-site
> > > unzip ...
> > > git push -f
> > >
> >
> > You can do the same in the existing setup too. You just need a `sed`
> > one-liner to adapt the `.asf.yaml` content:
> >
> > $ sed -i -e 's/^publish:/staging:/g' -e 's/^ whoami:.+/ :whoami:
> > asf-staging/g' asf.yaml
> >
> > Not to mention this is a detail that will be a part of the CI-based
> release
> > process. That is, no PMC member will need to recall or type any of these
> > `git`, `sed`, `unzip`, etc. commands to cut a release.
> >
> > Given I addressed your "quickly stage a website" concern, are we good?
>
> I agree with your objections on not **requiring** all `.asf.yaml` to
> be in sync. However I also don't see a reason not to have a `staging`
> configuration on the `asf-site` branch and a `publish` configuration
> on the `asf-staging` branch.
>
> I would prefer for the CI not to meddle with critical files such as
> `.asf.yaml`, especially if changes to these files are almost never
> required.
>
> Piotr
>
> PS: I removed the `publish` and `staging` sections on the main branch
> of `logging-parent` and the `github` section on the site branches.
>
Re: [log4j] `.asf.yaml` between branches
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Volkan,
On Mon, 15 Jan 2024 at 11:07, Volkan Yazıcı <vo...@yazi.ci> wrote:
> > * you can stage the website for a release with a simple:
> >
> > git checkout asf-staging
> > git reset --hard asf-site
> > unzip ...
> > git push -f
> >
>
> You can do the same in the existing setup too. You just need a `sed`
> one-liner to adapt the `.asf.yaml` content:
>
> $ sed -i -e 's/^publish:/staging:/g' -e 's/^ whoami:.+/ :whoami:
> asf-staging/g' asf.yaml
>
> Not to mention this is a detail that will be a part of the CI-based release
> process. That is, no PMC member will need to recall or type any of these
> `git`, `sed`, `unzip`, etc. commands to cut a release.
>
> Given I addressed your "quickly stage a website" concern, are we good?
I agree with your objections on not **requiring** all `.asf.yaml` to
be in sync. However I also don't see a reason not to have a `staging`
configuration on the `asf-site` branch and a `publish` configuration
on the `asf-staging` branch.
I would prefer for the CI not to meddle with critical files such as
`.asf.yaml`, especially if changes to these files are almost never
required.
Piotr
PS: I removed the `publish` and `staging` sections on the main branch
of `logging-parent` and the `github` section on the site branches.
Re: [log4j] `.asf.yaml` between branches
Posted by Volkan Yazıcı <vo...@yazi.ci>.
On Mon, Jan 15, 2024 at 9:45 AM Piotr P. Karwasz <pi...@gmail.com>
wrote:
> This setup has some pros:
>
> * you don't need to navigate to all the website branches to see how
> they are configured,
>
This would only work *iff* the `.asf.yaml` between the branch you are
looking at (e.g., `main`) and the target branch (e.g. `asf-site`) do match.
This is an assumption and an extra maintenance task. We both witnessed
several of such assumptions were unheld while refactoring the existing
Log4j websites. Not just I fixed several `.asf.yaml` files, I even deleted
long forgotten website branches.
> * you can stage the website for a release with a simple:
>
> git checkout asf-staging
> git reset --hard asf-site
> unzip ...
> git push -f
>
You can do the same in the existing setup too. You just need a `sed`
one-liner to adapt the `.asf.yaml` content:
$ sed -i -e 's/^publish:/staging:/g' -e 's/^ whoami:.+/ :whoami:
asf-staging/g' asf.yaml
Not to mention this is a detail that will be a part of the CI-based release
process. That is, no PMC member will need to recall or type any of these
`git`, `sed`, `unzip`, etc. commands to cut a release.
Given I addressed your "quickly stage a website" concern, are we good?
So maybe we could use a mixed approach:
>
> * the Github config can only be on a single branch,
> * the website config is copied to every branch.
>
All in all, I am against assumptions and extra maintenance tasks. You and I
have been working on Log4j full time for several months. This might not be
the case next year anymore. People come and go. I value the simplicity and
ease of maintenance above all in community projects.
> What do you think? See also my e-mail on the site repo/branches mess.
> I doubt most PMC members can tell you where each part of the website
> is coming from.
>
As I explained in my response to your other email, the *"site repo/branches
mess"* statement is not true. Besides a few exceptions I shared, the
*"`asf-{site,staging}`
branch of every repository points to the website"* scheme is clear enough
for everyone, IMO.
Re: [log4j] `.asf.yaml` between branches
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Volkan,
On Mon, 15 Jan 2024 at 09:28, Volkan Yazıcı <vo...@yazi.ci> wrote:
> Piotr, I have seen you applied this *"sync'ing `asf.yaml` between branches"*
> practice in `logging-parent` too. I find this new setup
>
> - *confusing* – Previously, say, `asf-site` related configuration was
> only in the `asf-site` branch. Now it is in multiple branches of which
> it has no association with.
> - *requiring more work for changes* – If I need to make a change to
> `asf-site`, I need to update in several branches.
> - *prone to causing difficult to solve INFRA issues* – We know INFRA is
> sensitive to configuration overrides that appear in multiple branches.
>
> Hence, I prefer you revert all these changes in all repositories and switch
> back to *"configuration related to branch X goes to branch X"* practice.
This setup has some pros:
* you don't need to navigate to all the website branches to see how
they are configured,
* you can stage the website for a release with a simple:
git checkout asf-staging
git reset --hard asf-site
unzip ...
git push -f
I partly agree on your remark regarding INFRA issues: the INFRA script
has problems with the **Github** configuration if we set it on
multiple branches (the scripts run on the default branch, a branch
named `main` and `master`).
However I didn't notice any issues if you copy the **Website**
configuration to multiple branches: the `whoami` parameter has been
introduced exactly for that. INFRA ignores all website configuration
unless `whoami` is equal to the name of the current branch.
So maybe we could use a mixed approach:
* the Github config can only be on a single branch,
* the website config is copied to every branch.
What do you think? See also my e-mail on the site repo/branches mess.
I doubt most PMC members can tell you where each part of the website
is coming from.
Piotr
[log4j] `.asf.yaml` between branches
Posted by Volkan Yazıcı <vo...@yazi.ci>.
Piotr, I have seen you applied this *"sync'ing `asf.yaml` between branches"*
practice in `logging-parent` too. I find this new setup
- *confusing* – Previously, say, `asf-site` related configuration was
only in the `asf-site` branch. Now it is in multiple branches of which
it has no association with.
- *requiring more work for changes* – If I need to make a change to
`asf-site`, I need to update in several branches.
- *prone to causing difficult to solve INFRA issues* – We know INFRA is
sensitive to configuration overrides that appear in multiple branches.
Hence, I prefer you revert all these changes in all repositories and switch
back to *"configuration related to branch X goes to branch X"* practice.
On Wed, Dec 27, 2023 at 8:50 AM <pk...@apache.org> wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> pkarwasz pushed a commit to branch asf-staging
> in repository https://gitbox.apache.org/repos/asf/logging-log4j-kotlin.git
>
> commit ba7e51dee84af097e3246b84238997bc9173aa84
> Author: Piotr P. Karwasz <pi...@karwasz.org>
> AuthorDate: Wed Dec 27 08:49:51 2023 +0100
>
> Synchronize `.asf.yaml` between site branches
> ---
> .asf.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/.asf.yaml b/.asf.yaml
> index 46afaa1..545694d 100644
> --- a/.asf.yaml
> +++ b/.asf.yaml
> @@ -21,3 +21,8 @@ publish:
> profile: ~
> whoami: asf-site
> subdir: content/log4j/kotlin
> +
> +staging:
> + profile: ~
> + whoami: asf-staging
> + subdir: content/log4j/kotlin
>
>