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 <ralph.go...@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
