I agree with Zike that the root cause of this specific case is that 3.0
changes the docker images artifacts and we don't update the process.
Before we correct the process to ensure that human can follow, automation
only automatically make mistakes.
tison 于2023年6月2日 周五00:53写道：
> The ASF only cou
The ASF only counts the source releases the official releases. All binaries
including docker images should be for convenience only.
Even the image needs to go through a vote, you can of course build and
stage the image with any method in hand. The problem is where we can share
a build environment
> The best solution is to make the build repeatable. IIUC, that will let
us build all of the artifacts using CI instead of personal machines,
which removes this class of errors.
I agree! But I don't know if Apache rules allow this operation, and if
so, I recommend using the CI to publish our proje
> The best solution is to make the build repeatable. IIUC, that will let
us build all of the artifacts using CI instead of personal machines,
which removes this class of errors.
I don't think this issue is related to where the docker image was
built. It has nothing to do with caching and nothing t
I understand that you can't build a release process due to Apache
foundation rules, that makes it mandatory to release something you built on
your own machine.
On Wed, May 31, 2023 at 5:54 PM Enrico Olivelli wrote:
> Il giorno mer 31 mag 2023 alle ore 16:50 Michael Marshall
> ha scritto:
> >
>
Il giorno mer 31 mag 2023 alle ore 16:50 Michael Marshall
ha scritto:
>
> The best solution is to make the build repeatable. IIUC, that will let
> us build all of the artifacts using CI instead of personal machines,
> which removes this class of errors.
>
> That being said, I don't know how much e
The best solution is to make the build repeatable. IIUC, that will let
us build all of the artifacts using CI instead of personal machines,
which removes this class of errors.
That being said, I don't know how much effort it would be to achieve.
Thanks,
Michael
On Tue, May 30, 2023 at 2:24 AM Zi
Hi, Enrico
> When we ran the VOTE and we provided the docker images, were they
already broken ?
Actually, they are not broken unless we use the new features of Pulsar 3.0.0.
I think we need something like verification test scripts, to verify
the release candidate. For example, we use the image p
Hi, Asaf
> How do you suggest we prevent it from happening next time?
I have pushed a PR to fix it: https://github.com/apache/pulsar/pull/20435
This PR specifies the correct image name for `pulsar` image to build pulsar-all.
Note that, in the release of Pulsar 3.0, we build the docker image by
e
I am really worried about the process.
When we ran the VOTE and we provided the docker images, were they
already broken ?
In any case we cannot overwrite those images, they have been cached
all over the world now.
It is safer to cut a new 3.0.1 release and run a VOTE.
Maybe we can remove the o
Good catch!
How do you suggest we prevent it from happening next time?
On Mon, May 29, 2023 at 1:34 PM Zike Yang wrote:
> Hi, all
>
> Recently, we found an issue with the `pulsar-all:3.0.0` image. The
> pulsar library included in `pulsar-all:3.0.0` is the version of
> 2.11.0:
>
> ```
> docker r
11 matches
Mail list logo
