Hi Tobiasz, Thank you for your work on this. I think this is making great progress and I agree that it will simplify the release process. I asked a few clarifying questions on the PR. (I do not want to repeat it here to avoid diverging the conversation.)
Thank you! Ahmet On Tue, Jun 9, 2020 at 2:39 AM Tobiasz Kędzierski < [email protected]> wrote: > Hi, > > I've added some important updates to > https://github.com/apache/beam/pull/11877 and I wanted to share some > thoughts with you about possible improvements: > > During releasing a new version of Beam the script > *build_release_candidate.sh* is executed. It builds sources and puts them > into the GCS staging bucket where they are consumed by separate repository > CI jobs (beam-wheels). Then they are downloaded and processed by > *sign_hash_python_wheels.sh* script. > > By using github actions this process could be simplified as follows: > 1. Within *build_release_candidate.sh* *release* and *release candidate* > branches are pushed to the remote repository (this is done by it now). > 2. gh-actions will build sources and wheels based on these branches. > 3. *build_release_candidate.sh* could verify status of the build by using > github api and corresponding data (name of the branch, commit hash) and > after successful build download sources and wheel files from gh-action > artifacts and use them in further actions. > > Happy to know your opinion on this > > BR > Tobiasz Kędzierski > > On Mon, Jun 1, 2020 at 11:02 PM Ahmet Altay <[email protected]> wrote: > >> > @Ahmet Altay <[email protected]> happy to understand the extent of what >> you had in mind, maybe the extensions are not as important to plan out, as >> they're straightforwardly bolted on (ex: daily builds). More tactically >> would be valuable to ensure I understand what all needs to occur. Any >> other source of info to consume other than >> https://github.com/apache/beam-wheels and >> https://beam.apache.org/contribute/release-guide/. >> >> I added a bit more details to >> https://issues.apache.org/jira/browse/BEAM-9388 as a comment, so that it >> is preserved in the JIRA. Thank you all for working on this. >> >> On Mon, Jun 1, 2020 at 9:20 AM Kamil Wasilewski < >> [email protected]> wrote: >> >>> "unistd.h" C header is present on POSIX systems (MacOS and Linux), but >>> not on Windows, therefore you can't build a wheel for Windows. >>> >>> I took a look and "statesampler_fast.pyx" uses "unistd.h" only because >>> of the `usleep` function. Unless we use C++ which offers [1], the solution >>> would be to search for the equivalent of `usleep` that works on Windows. >>> >> >> +Robert Bradshaw <[email protected]> +Valentyn Tymofieiev >> <[email protected]> - Do you have any suggestions on how building >> wheels could work on Windows? >> >> >>> >>> [1] https://en.cppreference.com/w/cpp/thread/sleep_for >>> >> >
