QA: Cross OS Build Testing & Documentation #3471
Replies: 4 comments
-
"core developer" -> "community", because community > titles
Why does this activity need this title/group? |
Beta Was this translation helpful? Give feedback.
-
maybe it does, maybe it doesn't, it's just a label. |
Beta Was this translation helpful? Give feedback.
-
To help the community get started: here's a Dockerfile that you can use to test archlinux (rolling distro so it always has rather up-to-date packages): FROM archlinux
WORKDIR /build
RUN pacman -Sy \
&& pacman --noconfirm -S git base-devel boost libevent python db
ARG GITREF=1.15.0-dev
ARG MAKEOPTS=-j8
RUN git clone https://github.com/dogecoin/dogecoin.git \
&& cd dogecoin \
&& git checkout $GITREF \
&& ./autogen.sh \
&& ./configure --without-gui --without-miniupnpc \
&& make $MAKEOPTS \
&& make check running this will attempt to self-compile Dogecoin Core from the This bug is already reported, and a fix is proposed with #3456, which is waiting for review. Once that has been merged, you can run this Dockerfile again, to see if that resolved the issue, or change the cloned url and GITREF variable in the docker file to test the patch while it's still pending, after which you could even leave a comment at the pull request that you tested it and it resolved the issue, which would potentially help getting it through. By doing this, the community would:
|
Beta Was this translation helpful? Give feedback.
-
I’ve noted somewhere between one and two dozen issues in the last month that appear to be loosely related to this topic. |
Beta Was this translation helpful? Give feedback.
-
This issue arises from discussion in #3437 to assist with understanding which OS flavors are "in scope" for core developer support and documented as "clean" for new developer onboarding.
Per @patricklodder it is recommended to start with linux distributions that already have documented build guides and work outwards with creating guides and documenting known issues for (hopefully) all builds represented in the Minimum (pre-compiled binary) OS documentation.
Broadly speaking, for each maintained version, "Core QA" will create a Dockerfile and run a build each time dependencies are updated.
When something fails "Core QA" will document failures by opening an issue with the Dockerfile for senior members of the core development team to reproduce the errors, warnings etc. and work through a solution.
Alternatively, if "Core QA" is feeling advanced they are free to take on and work through the issue themselves by submitting PRs with support from senior members of the team.
Beta Was this translation helpful? Give feedback.
All reactions