Sure, it seems like an optional thing to me. Spark has a Jenkins setup for
building and testing. This would only affect someone that pushes the code
to gitlab.
I'm happy to keep the commit in a small private branch of my own that I
apply when I need to build an out of cycle build. I just though
Can a '.gitlab-ci.yml' be considered code, in the same way that the k8s
related dockerfiles are code? In other words, something like: "here is a
piece of code you might choose to use for building your own binaries, that
is not specifically endorsed by Apache Spark"? So it would not be involved
in
I understand that "non-dev" persons could become confused and that some
sort of signposting/warning makes sense.
Certainly I consider my personal registry on gitlab.com as ephemeral and
not intended to publish.
We have our own private instance of gitlab where I put artifacts that are
derived and t
Yeah the color on this is that 'snapshot' or 'nightly' builds are not
quite _discouraged_ by the ASF, but need to be something only devs are
likely to find and clearly signposted, because they aren't official
blessed releases. It gets into a gray area if the project is
'officially' hosting a way to
Hi, Jim.
Thank you for the proposal. I understand the request.
However, the following key benefit sounds like unofficial snapshot binary
releases.
> For example, this was used to build a version of spark that included
SPARK-28938 which has yet to be released and was necessary for
spark-operator t
