You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Davyd McColl <da...@gmail.com> on 2020/05/03 16:23:52 UTC
[log4net] resurrection update
Hi all
I've been a bit busy with other stuff lately, but played a little catch-up today:
- I have a _windows_ docker image (and batch file) which builds log4net fine
- I've sorted out AppVeyer -- builds happen fine there too. I get the nuget package as a build artifact -- I'd guess that, at some point, this build artifact has to be imported into Apache infra to be published -- I'm not sure if figuring that out should happen as part of the PR, or after; I'm quite happy to help with this, but will need some serious guidance (:
Last build is here: https://ci.appveyor.com/project/fluffynuts/logging-log4net/builds/32615159 -- there's a .nupkg artifact included, if anyone wants to check it out.
I'd like to tidy up my commit history a little (there's a metric boatload of experimental commits purely experimenting with external build systems), but I'm about ready to PR, I think.
When there was mention of docker earlier, there wasn't mention of _host_ environment. Is docker available on windows, for windows containers? If not, I'll cull that work from the PR (though I definitely have other uses for it), assuming that AppVeyer is acceptable, as per prior communications.
Thanks
-d
Re: [log4net] resurrection update
Posted by Davyd McColl <da...@gmail.com>.
Hi all
I've raised a PR (https://github.com/apache/logging-log4net/pull/59). I'm sure there's more to be done, process-wise. I'd really appreciate some guidance.
-d
On 2020-05-03 19:32:14, Ralph Goers <ra...@dslextreme.com> wrote:
There is nothing that requires the release build to run on ASF hardware if that helps. I perform all the Log4j releases on my MacBook Pro.
That said, I am sure it would be helpful to have Docker available to preform CI builds.
Ralph
> On May 3, 2020, at 10:23 AM, Davyd McColl wrote:
>
> Hi Ralph
>
> I'll add documentation about build, though it's either:
> 1. run the batch file to run the docker image and build through that
> or
> 2. let AppVeyer build by itself -- which it does -- and grab the build artifact from that, which I don't currently do, as I'm not sure where to put it or how other Apache projects consume AppVeyer. AppVeyer was suggested as a known quantity.
>
> Either way, I'm going to need help: either to have docker installed on an existing windows infra machine, and targeting windows containers, or doing whatever is accepted as a reasonable workflow to get the artifacts from AppVeyer
>
> As for signing, the .snk is included in the repo and there's a note in the readme that it was done that way on purpose, so there should be no need to sort that out. Security around upload to nuget.org prevents nefarious packages from being released -- I gather that was considered good enough.
>
> I'll clean up commits and raise a PR (hopefully tomorrow), but I'm going to need some help with this as I've done what I can: build, test (tests all pass) and generate the package. From here on out, I'm going to need an Apache buddy to get any further, assuming even that my PR is acceptable.
>
> -d
> On 2020-05-03 19:10:16, Ralph Goers > wrote:
> All releases at the ASF follow the guidelines at https://infra.apache.org/release-publishing.html. Although each project is free the tailor the release process to meed its needs, the end result must comply with what is documented there. For example, Log4j 2 uses https://cwiki.apache.org/confluence/display/LOGGING/Log4j+2+Release+Process.
>
> In a nutshell, the mail requirements of a release are
> 1. It contain a LICENSE file.
> 2. It contain a NOTICES file if one is needed.
> 3. It should contain a RELEASE_NOTES file, but this is not required.
> 4. It must compile (notice the ASF requirements don’t even require it passing unit tests)
> 5. It must be signed. Getting a trusted signing key can take some time so help may be required for that.
> 6. It must be uploaded to https://dist.apache.org/repos/dist/release/logging/. This requires privileges that only Logging PMC and ASF members have.
>
> Note that the ASF only requires that the source code be packaged for a release. However, most projects provide “convenience” binaries since that is what most users really want. These binaries can also be uploaded to the distribution directory and may be distributed in other ways that make it easy for uses to obtain them. For example, all Log4j releases are published to the ASF Nexus repository which will forward them to the Maven Central Repository.
>
> As for Docker, since you are using that as a build environment you can make any requirements you want on the platform docker runs on. That said, although I have never done it (since I haven’t had a computer natively running Windows in at least 10 years), Docker does seem to run on Windows - https://docs.docker.com/docker-for-windows/.
>
> Have you documented the instructions to perform the build somewhere?
>
> Ralph
>
>
>
>
>
>> On May 3, 2020, at 9:23 AM, Davyd McColl wrote:
>>
>> Hi all
>>
>> I've been a bit busy with other stuff lately, but played a little catch-up today:
>>
>> - I have a _windows_ docker image (and batch file) which builds log4net fine
>> - I've sorted out AppVeyer -- builds happen fine there too. I get the nuget package as a build artifact -- I'd guess that, at some point, this build artifact has to be imported into Apache infra to be published -- I'm not sure if figuring that out should happen as part of the PR, or after; I'm quite happy to help with this, but will need some serious guidance (:
>>
>> Last build is here: https://ci.appveyor.com/project/fluffynuts/logging-log4net/builds/32615159 -- there's a .nupkg artifact included, if anyone wants to check it out.
>>
>> I'd like to tidy up my commit history a little (there's a metric boatload of experimental commits purely experimenting with external build systems), but I'm about ready to PR, I think.
>>
>> When there was mention of docker earlier, there wasn't mention of _host_ environment. Is docker available on windows, for windows containers? If not, I'll cull that work from the PR (though I definitely have other uses for it), assuming that AppVeyer is acceptable, as per prior communications.
>>
>> Thanks
>> -d
Re: [log4net] resurrection update
Posted by Ralph Goers <ra...@dslextreme.com>.
There is nothing that requires the release build to run on ASF hardware if that helps. I perform all the Log4j releases on my MacBook Pro.
That said, I am sure it would be helpful to have Docker available to preform CI builds.
Ralph
> On May 3, 2020, at 10:23 AM, Davyd McColl <da...@gmail.com> wrote:
>
> Hi Ralph
>
> I'll add documentation about build, though it's either:
> 1. run the batch file to run the docker image and build through that
> or
> 2. let AppVeyer build by itself -- which it does -- and grab the build artifact from that, which I don't currently do, as I'm not sure where to put it or how other Apache projects consume AppVeyer. AppVeyer was suggested as a known quantity.
>
> Either way, I'm going to need help: either to have docker installed on an existing windows infra machine, and targeting windows containers, or doing whatever is accepted as a reasonable workflow to get the artifacts from AppVeyer
>
> As for signing, the .snk is included in the repo and there's a note in the readme that it was done that way on purpose, so there should be no need to sort that out. Security around upload to nuget.org <http://nuget.org/> prevents nefarious packages from being released -- I gather that was considered good enough.
>
> I'll clean up commits and raise a PR (hopefully tomorrow), but I'm going to need some help with this as I've done what I can: build, test (tests all pass) and generate the package. From here on out, I'm going to need an Apache buddy to get any further, assuming even that my PR is acceptable.
>
> -d
> On 2020-05-03 19:10:16, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
> All releases at the ASF follow the guidelines at https://infra.apache.org/release-publishing.html. Although each project is free the tailor the release process to meed its needs, the end result must comply with what is documented there. For example, Log4j 2 uses https://cwiki.apache.org/confluence/display/LOGGING/Log4j+2+Release+Process.
>
> In a nutshell, the mail requirements of a release are
> 1. It contain a LICENSE file.
> 2. It contain a NOTICES file if one is needed.
> 3. It should contain a RELEASE_NOTES file, but this is not required.
> 4. It must compile (notice the ASF requirements don’t even require it passing unit tests)
> 5. It must be signed. Getting a trusted signing key can take some time so help may be required for that.
> 6. It must be uploaded to https://dist.apache.org/repos/dist/release/logging/. This requires privileges that only Logging PMC and ASF members have.
>
> Note that the ASF only requires that the source code be packaged for a release. However, most projects provide “convenience” binaries since that is what most users really want. These binaries can also be uploaded to the distribution directory and may be distributed in other ways that make it easy for uses to obtain them. For example, all Log4j releases are published to the ASF Nexus repository which will forward them to the Maven Central Repository.
>
> As for Docker, since you are using that as a build environment you can make any requirements you want on the platform docker runs on. That said, although I have never done it (since I haven’t had a computer natively running Windows in at least 10 years), Docker does seem to run on Windows - https://docs.docker.com/docker-for-windows/.
>
> Have you documented the instructions to perform the build somewhere?
>
> Ralph
>
>
>
>
>
>> On May 3, 2020, at 9:23 AM, Davyd McColl wrote:
>>
>> Hi all
>>
>> I've been a bit busy with other stuff lately, but played a little catch-up today:
>>
>> - I have a _windows_ docker image (and batch file) which builds log4net fine
>> - I've sorted out AppVeyer -- builds happen fine there too. I get the nuget package as a build artifact -- I'd guess that, at some point, this build artifact has to be imported into Apache infra to be published -- I'm not sure if figuring that out should happen as part of the PR, or after; I'm quite happy to help with this, but will need some serious guidance (:
>>
>> Last build is here: https://ci.appveyor.com/project/fluffynuts/logging-log4net/builds/32615159 -- there's a .nupkg artifact included, if anyone wants to check it out.
>>
>> I'd like to tidy up my commit history a little (there's a metric boatload of experimental commits purely experimenting with external build systems), but I'm about ready to PR, I think.
>>
>> When there was mention of docker earlier, there wasn't mention of _host_ environment. Is docker available on windows, for windows containers? If not, I'll cull that work from the PR (though I definitely have other uses for it), assuming that AppVeyer is acceptable, as per prior communications.
>>
>> Thanks
>> -d
Re: [log4net] resurrection update
Posted by Matt Sicker <bo...@gmail.com>.
I'm not sure if our Jenkins here is set up for Docker on Windows yet
as that's even a fairly recent integration being worked on in Jenkins
itself right now (mostly around packaging Jenkins in a Windows Docker
container, but it's part of the larger experience). If you already
have it working on AppVeyor, then there's no need to figure out a
duplicate Jenkins pipeline.
For signing, there's a gpg signature that needs to be created for
Apache releases independent of any application-specific signatures
that are included (e.g., a jar file can contain signatures of the
files inside it using a code signing certificate, and I'd assume
you're talking about something similar for the nuget package). If we
also need a code signing certificate (e.g., for an app store release
type of thing), then that will complicate things slightly, but there
is some sort of code signing service here at Apache nowadays (in
theory, it'd be useful if we made any OS-specific packages for any GUI
apps).
One thing to keep in mind about the gpg signing is that it should be
done on your own computer, not in a CI environment. The only potential
exception around that would be for fully binary reproducible builds,
but that's its own project. In the case of AppVeyor, that could mean
downloading the release artifacts from it, testing them out, then
signing and uploading the files for staging the release.
On Sun, 3 May 2020 at 12:23, Davyd McColl <da...@gmail.com> wrote:
>
> Hi Ralph
>
> I'll add documentation about build, though it's either:
> 1. run the batch file to run the docker image and build through that
> or
> 2. let AppVeyer build by itself -- which it does -- and grab the build artifact from that, which I don't currently do, as I'm not sure where to put it or how other Apache projects consume AppVeyer. AppVeyer was suggested as a known quantity.
>
> Either way, I'm going to need help: either to have docker installed on an existing windows infra machine, and targeting windows containers, or doing whatever is accepted as a reasonable workflow to get the artifacts from AppVeyer
>
> As for signing, the .snk is included in the repo and there's a note in the readme that it was done that way on purpose, so there should be no need to sort that out. Security around upload to nuget.org prevents nefarious packages from being released -- I gather that was considered good enough.
>
> I'll clean up commits and raise a PR (hopefully tomorrow), but I'm going to need some help with this as I've done what I can: build, test (tests all pass) and generate the package. From here on out, I'm going to need an Apache buddy to get any further, assuming even that my PR is acceptable.
>
> -d
> On 2020-05-03 19:10:16, Ralph Goers <ra...@dslextreme.com> wrote:
> All releases at the ASF follow the guidelines at https://infra.apache.org/release-publishing.html. Although each project is free the tailor the release process to meed its needs, the end result must comply with what is documented there. For example, Log4j 2 uses https://cwiki.apache.org/confluence/display/LOGGING/Log4j+2+Release+Process.
>
> In a nutshell, the mail requirements of a release are
> 1. It contain a LICENSE file.
> 2. It contain a NOTICES file if one is needed.
> 3. It should contain a RELEASE_NOTES file, but this is not required.
> 4. It must compile (notice the ASF requirements don’t even require it passing unit tests)
> 5. It must be signed. Getting a trusted signing key can take some time so help may be required for that.
> 6. It must be uploaded to https://dist.apache.org/repos/dist/release/logging/. This requires privileges that only Logging PMC and ASF members have.
>
> Note that the ASF only requires that the source code be packaged for a release. However, most projects provide “convenience” binaries since that is what most users really want. These binaries can also be uploaded to the distribution directory and may be distributed in other ways that make it easy for uses to obtain them. For example, all Log4j releases are published to the ASF Nexus repository which will forward them to the Maven Central Repository.
>
> As for Docker, since you are using that as a build environment you can make any requirements you want on the platform docker runs on. That said, although I have never done it (since I haven’t had a computer natively running Windows in at least 10 years), Docker does seem to run on Windows - https://docs.docker.com/docker-for-windows/.
>
> Have you documented the instructions to perform the build somewhere?
>
> Ralph
>
>
>
>
>
> > On May 3, 2020, at 9:23 AM, Davyd McColl wrote:
> >
> > Hi all
> >
> > I've been a bit busy with other stuff lately, but played a little catch-up today:
> >
> > - I have a _windows_ docker image (and batch file) which builds log4net fine
> > - I've sorted out AppVeyer -- builds happen fine there too. I get the nuget package as a build artifact -- I'd guess that, at some point, this build artifact has to be imported into Apache infra to be published -- I'm not sure if figuring that out should happen as part of the PR, or after; I'm quite happy to help with this, but will need some serious guidance (:
> >
> > Last build is here: https://ci.appveyor.com/project/fluffynuts/logging-log4net/builds/32615159 -- there's a .nupkg artifact included, if anyone wants to check it out.
> >
> > I'd like to tidy up my commit history a little (there's a metric boatload of experimental commits purely experimenting with external build systems), but I'm about ready to PR, I think.
> >
> > When there was mention of docker earlier, there wasn't mention of _host_ environment. Is docker available on windows, for windows containers? If not, I'll cull that work from the PR (though I definitely have other uses for it), assuming that AppVeyer is acceptable, as per prior communications.
> >
> > Thanks
> > -d
>
>
--
Matt Sicker <bo...@gmail.com>
Re: [log4net] resurrection update
Posted by Davyd McColl <da...@gmail.com>.
Hi Ralph
I'll add documentation about build, though it's either:
1. run the batch file to run the docker image and build through that
or
2. let AppVeyer build by itself -- which it does -- and grab the build artifact from that, which I don't currently do, as I'm not sure where to put it or how other Apache projects consume AppVeyer. AppVeyer was suggested as a known quantity.
Either way, I'm going to need help: either to have docker installed on an existing windows infra machine, and targeting windows containers, or doing whatever is accepted as a reasonable workflow to get the artifacts from AppVeyer
As for signing, the .snk is included in the repo and there's a note in the readme that it was done that way on purpose, so there should be no need to sort that out. Security around upload to nuget.org prevents nefarious packages from being released -- I gather that was considered good enough.
I'll clean up commits and raise a PR (hopefully tomorrow), but I'm going to need some help with this as I've done what I can: build, test (tests all pass) and generate the package. From here on out, I'm going to need an Apache buddy to get any further, assuming even that my PR is acceptable.
-d
On 2020-05-03 19:10:16, Ralph Goers <ra...@dslextreme.com> wrote:
All releases at the ASF follow the guidelines at https://infra.apache.org/release-publishing.html. Although each project is free the tailor the release process to meed its needs, the end result must comply with what is documented there. For example, Log4j 2 uses https://cwiki.apache.org/confluence/display/LOGGING/Log4j+2+Release+Process.
In a nutshell, the mail requirements of a release are
1. It contain a LICENSE file.
2. It contain a NOTICES file if one is needed.
3. It should contain a RELEASE_NOTES file, but this is not required.
4. It must compile (notice the ASF requirements don’t even require it passing unit tests)
5. It must be signed. Getting a trusted signing key can take some time so help may be required for that.
6. It must be uploaded to https://dist.apache.org/repos/dist/release/logging/. This requires privileges that only Logging PMC and ASF members have.
Note that the ASF only requires that the source code be packaged for a release. However, most projects provide “convenience” binaries since that is what most users really want. These binaries can also be uploaded to the distribution directory and may be distributed in other ways that make it easy for uses to obtain them. For example, all Log4j releases are published to the ASF Nexus repository which will forward them to the Maven Central Repository.
As for Docker, since you are using that as a build environment you can make any requirements you want on the platform docker runs on. That said, although I have never done it (since I haven’t had a computer natively running Windows in at least 10 years), Docker does seem to run on Windows - https://docs.docker.com/docker-for-windows/.
Have you documented the instructions to perform the build somewhere?
Ralph
> On May 3, 2020, at 9:23 AM, Davyd McColl wrote:
>
> Hi all
>
> I've been a bit busy with other stuff lately, but played a little catch-up today:
>
> - I have a _windows_ docker image (and batch file) which builds log4net fine
> - I've sorted out AppVeyer -- builds happen fine there too. I get the nuget package as a build artifact -- I'd guess that, at some point, this build artifact has to be imported into Apache infra to be published -- I'm not sure if figuring that out should happen as part of the PR, or after; I'm quite happy to help with this, but will need some serious guidance (:
>
> Last build is here: https://ci.appveyor.com/project/fluffynuts/logging-log4net/builds/32615159 -- there's a .nupkg artifact included, if anyone wants to check it out.
>
> I'd like to tidy up my commit history a little (there's a metric boatload of experimental commits purely experimenting with external build systems), but I'm about ready to PR, I think.
>
> When there was mention of docker earlier, there wasn't mention of _host_ environment. Is docker available on windows, for windows containers? If not, I'll cull that work from the PR (though I definitely have other uses for it), assuming that AppVeyer is acceptable, as per prior communications.
>
> Thanks
> -d
Re: [log4net] resurrection update
Posted by Ralph Goers <ra...@dslextreme.com>.
All releases at the ASF follow the guidelines at https://infra.apache.org/release-publishing.html. Although each project is free the tailor the release process to meed its needs, the end result must comply with what is documented there. For example, Log4j 2 uses https://cwiki.apache.org/confluence/display/LOGGING/Log4j+2+Release+Process.
In a nutshell, the mail requirements of a release are
1. It contain a LICENSE file.
2. It contain a NOTICES file if one is needed.
3. It should contain a RELEASE_NOTES file, but this is not required.
4. It must compile (notice the ASF requirements don’t even require it passing unit tests)
5. It must be signed. Getting a trusted signing key can take some time so help may be required for that.
6. It must be uploaded to https://dist.apache.org/repos/dist/release/logging/. This requires privileges that only Logging PMC and ASF members have.
Note that the ASF only requires that the source code be packaged for a release. However, most projects provide “convenience” binaries since that is what most users really want. These binaries can also be uploaded to the distribution directory and may be distributed in other ways that make it easy for uses to obtain them. For example, all Log4j releases are published to the ASF Nexus repository which will forward them to the Maven Central Repository.
As for Docker, since you are using that as a build environment you can make any requirements you want on the platform docker runs on. That said, although I have never done it (since I haven’t had a computer natively running Windows in at least 10 years), Docker does seem to run on Windows - https://docs.docker.com/docker-for-windows/.
Have you documented the instructions to perform the build somewhere?
Ralph
> On May 3, 2020, at 9:23 AM, Davyd McColl <da...@gmail.com> wrote:
>
> Hi all
>
> I've been a bit busy with other stuff lately, but played a little catch-up today:
>
> - I have a _windows_ docker image (and batch file) which builds log4net fine
> - I've sorted out AppVeyer -- builds happen fine there too. I get the nuget package as a build artifact -- I'd guess that, at some point, this build artifact has to be imported into Apache infra to be published -- I'm not sure if figuring that out should happen as part of the PR, or after; I'm quite happy to help with this, but will need some serious guidance (:
>
> Last build is here: https://ci.appveyor.com/project/fluffynuts/logging-log4net/builds/32615159 -- there's a .nupkg artifact included, if anyone wants to check it out.
>
> I'd like to tidy up my commit history a little (there's a metric boatload of experimental commits purely experimenting with external build systems), but I'm about ready to PR, I think.
>
> When there was mention of docker earlier, there wasn't mention of _host_ environment. Is docker available on windows, for windows containers? If not, I'll cull that work from the PR (though I definitely have other uses for it), assuming that AppVeyer is acceptable, as per prior communications.
>
> Thanks
> -d