Re: KIE - Question about "staging" binaries/artifacts
Hi, > Thank you all for the inputs, but we still seeking clarity on NPM. > > We - Apache KIE podling - are trying to get a single release procedure for > all binaries, but with lack of NPM infra for staging makes it really > complex. > > I notice that OpenDAL publishes to NPM, is there anyone involved in OpenDAL > here that could help us sort this out? > > For container images, we have similar issue with staging… less of issue is > the build. I would publish them, tag them as release candidates, and then update that tag/description if the release vote passes. Also see our distribution guidelines [1] for other important information on publishing to non-official channels. Kind Regards, Justin 1. https://incubator.apache.org/guides/distribution.html
Re: KIE - Question about "staging" binaries/artifacts
Thank you all for the inputs, but we still seeking clarity on NPM. We - Apache KIE podling - are trying to get a single release procedure for all binaries, but with lack of NPM infra for staging makes it really complex. I notice that OpenDAL publishes to NPM, is there anyone involved in OpenDAL here that could help us sort this out? For container images, we have similar issue with staging… less of issue is the build. On Mon, May 13, 2024 at 5:50 PM PJ Fanning wrote: > I may be misinterpreting 'live website' but it is quite common for Apache > projects to have a 'staged' version of their website (i.e. a pre-release > version of the web site). > https://kie.apache.org/ could also have a https://kie.staged.apache.org/ > > https://pekko.staged.apache.org/ is a staged version of > https://pekko.apache.org/ (for instance) > > See the .asf.yaml docs: > > https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-Stagingawebsitepreviewdomain > > For quay.io, you could raise a JIRA for INFRA team to discuss supporting > an > account for deployments. Or maybe, the KIE PPMC could set up an account and > share the credentials among the KIE release managers. > > > > > > On Mon, 13 May 2024 at 22:30, Tiago Bento wrote: > > > Thank you for the prompt responses. > > > > We're aware that for Maven artifacts we could "promote" them after > > publishing them to a staging repo. > > > > But for container images, for example, I'm not sure I understand how such > > process would look like. Prior to being in Apache, we used to push images > > to Quay.io under a "[version]-prerelease" tag for "staging". Then we > would > > have a completely new build when we would be ready for a actual release. > > > > I guess for other kinds of artifacts, like the NPM packages, live > > websites, and Chrome and VS Code Extensions, I also still don't > understand > > very well how this could be achieved... Any advice? It's hard to tell > what > > "promoting" those would look like, as for example, one of our live > websites > > is hosted in GitHub Pages. > > > > Thanks again! > > > > Regards, > > > > Tiago Bento > > > > > > > > On 2024/05/13 20:35:35 PJ Fanning wrote: > > > For Java jars, the ASF has repository.apache.org - a Nexus instance > that > > > can be used to stage and later release jars. > > > The login credentials are the same credentials you use to access other > > ASF > > > resources. > > > > > > > > > On Mon, 13 May 2024 at 21:28, Enrico Olivelli > > wrote: > > > > > > > Tiago, > > > > > > > > > > > > Il Lun 13 Mag 2024, 22:11 Tiago Bento ha > > scritto: > > > > > > > > > Hello general@incubator, > > > > > > > > > > My name is Tiago Bento (@tiagobento on GitHub), and I’m one of the > > > > > committers of the KIE project of the incubator. > > > > > > > > > > We’re gearing towards our first release under Apache, and we’re > very > > > > > excited to be approaching this important milestone. > > > > > > > > > > Some resources [1] [2] that we found already guided us in the right > > > > > direction, but still, some questions remain about the release > process > > > > > itself. > > > > > > > > > > We understand that in Apache, releases are done from the source > code > > > > > perspective, not the binaries/artifacts’. However, we still don’t > > > > > understand very clearly how Apache verifies signatures and > checksums > > > > > of the binaries that are eventually published. > > > > > > > > > > > > > It is better that in case you provide binaries to your users those > > binaries > > > > are released together with the sources during the same VOTE. > > > > > > > > Having reproducible builds would help a lot, but that's not always > > easy to > > > > do. > > > > > > > > In your VOTE you should stage all the sources and binaries, signed > > with the > > > > same signature (by the release manager) and the same artifacts will > be > > > > promoted in case of a successful VOTE. > > > > > > > > The PMC can at least verify the signatures and any digests that are > > staged > > > > as part of the VOTE. > > > > > > > > Please note that if you don't have a reproducible build the PMC will > > never > > > > be able to verify that the binaries match the sources. > > > > > > > > > > > > > The KIE project has three main types of consumable artifacts: Maven > > > > > modules, Container images, and NPM packages; and we also maintain > > some > > > > > live web pages like https://sandbox.kie.org, and extensions for > > Chrome > > > > > [3] and VS Code [4]. > > > > > > > > > > For the release to be voted, we understand we have to provide a > .zip > > > > > file containing the source code along with instructions on how to > > > > > build it. Once/if approved, our understanding is that the exact > same > > > > > approved source code could be used to build and publish > > > > > binaries/artifacts of any sort to public registries/repositories. > > > > > > > > > > I’m laying out all the information I could gather so
Re: KIE - Question about "staging" binaries/artifacts
I may be misinterpreting 'live website' but it is quite common for Apache projects to have a 'staged' version of their website (i.e. a pre-release version of the web site). https://kie.apache.org/ could also have a https://kie.staged.apache.org/ https://pekko.staged.apache.org/ is a staged version of https://pekko.apache.org/ (for instance) See the .asf.yaml docs: https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-Stagingawebsitepreviewdomain For quay.io, you could raise a JIRA for INFRA team to discuss supporting an account for deployments. Or maybe, the KIE PPMC could set up an account and share the credentials among the KIE release managers. On Mon, 13 May 2024 at 22:30, Tiago Bento wrote: > Thank you for the prompt responses. > > We're aware that for Maven artifacts we could "promote" them after > publishing them to a staging repo. > > But for container images, for example, I'm not sure I understand how such > process would look like. Prior to being in Apache, we used to push images > to Quay.io under a "[version]-prerelease" tag for "staging". Then we would > have a completely new build when we would be ready for a actual release. > > I guess for other kinds of artifacts, like the NPM packages, live > websites, and Chrome and VS Code Extensions, I also still don't understand > very well how this could be achieved... Any advice? It's hard to tell what > "promoting" those would look like, as for example, one of our live websites > is hosted in GitHub Pages. > > Thanks again! > > Regards, > > Tiago Bento > > > > On 2024/05/13 20:35:35 PJ Fanning wrote: > > For Java jars, the ASF has repository.apache.org - a Nexus instance that > > can be used to stage and later release jars. > > The login credentials are the same credentials you use to access other > ASF > > resources. > > > > > > On Mon, 13 May 2024 at 21:28, Enrico Olivelli > wrote: > > > > > Tiago, > > > > > > > > > Il Lun 13 Mag 2024, 22:11 Tiago Bento ha > scritto: > > > > > > > Hello general@incubator, > > > > > > > > My name is Tiago Bento (@tiagobento on GitHub), and I’m one of the > > > > committers of the KIE project of the incubator. > > > > > > > > We’re gearing towards our first release under Apache, and we’re very > > > > excited to be approaching this important milestone. > > > > > > > > Some resources [1] [2] that we found already guided us in the right > > > > direction, but still, some questions remain about the release process > > > > itself. > > > > > > > > We understand that in Apache, releases are done from the source code > > > > perspective, not the binaries/artifacts’. However, we still don’t > > > > understand very clearly how Apache verifies signatures and checksums > > > > of the binaries that are eventually published. > > > > > > > > > > It is better that in case you provide binaries to your users those > binaries > > > are released together with the sources during the same VOTE. > > > > > > Having reproducible builds would help a lot, but that's not always > easy to > > > do. > > > > > > In your VOTE you should stage all the sources and binaries, signed > with the > > > same signature (by the release manager) and the same artifacts will be > > > promoted in case of a successful VOTE. > > > > > > The PMC can at least verify the signatures and any digests that are > staged > > > as part of the VOTE. > > > > > > Please note that if you don't have a reproducible build the PMC will > never > > > be able to verify that the binaries match the sources. > > > > > > > > > > The KIE project has three main types of consumable artifacts: Maven > > > > modules, Container images, and NPM packages; and we also maintain > some > > > > live web pages like https://sandbox.kie.org, and extensions for > Chrome > > > > [3] and VS Code [4]. > > > > > > > > For the release to be voted, we understand we have to provide a .zip > > > > file containing the source code along with instructions on how to > > > > build it. Once/if approved, our understanding is that the exact same > > > > approved source code could be used to build and publish > > > > binaries/artifacts of any sort to public registries/repositories. > > > > > > > > I’m laying out all the information I could gather so someone can > > > > correct me if somehow I got the wrong idea of any part of the > process. > > > > > > > > I guess the main question I have at the moment is: Are we able to > pass > > > > the release vote only with the sources (without any published > > > > artifacts) so that once/if approved, we could publish definitive > > > > binaries/artifacts to public registries/repositories? > > > > > > > > > > You can do it. But you should state it very clearly in the downloads > pages > > > and in any repository. > > > > > > Also it is better to leverage as much as possible the ASF infra to > build > > > automatically such derived artifacts. > > > > > > Foe instance in Apache BookKeeper we build the docker images using a >
Re: KIE - Question about "staging" binaries/artifacts
Thank you for the prompt responses. We're aware that for Maven artifacts we could "promote" them after publishing them to a staging repo. But for container images, for example, I'm not sure I understand how such process would look like. Prior to being in Apache, we used to push images to Quay.io under a "[version]-prerelease" tag for "staging". Then we would have a completely new build when we would be ready for a actual release. I guess for other kinds of artifacts, like the NPM packages, live websites, and Chrome and VS Code Extensions, I also still don't understand very well how this could be achieved... Any advice? It's hard to tell what "promoting" those would look like, as for example, one of our live websites is hosted in GitHub Pages. Thanks again! Regards, Tiago Bento On 2024/05/13 20:35:35 PJ Fanning wrote: > For Java jars, the ASF has repository.apache.org - a Nexus instance that > can be used to stage and later release jars. > The login credentials are the same credentials you use to access other ASF > resources. > > > On Mon, 13 May 2024 at 21:28, Enrico Olivelli wrote: > > > Tiago, > > > > > > Il Lun 13 Mag 2024, 22:11 Tiago Bento ha scritto: > > > > > Hello general@incubator, > > > > > > My name is Tiago Bento (@tiagobento on GitHub), and I’m one of the > > > committers of the KIE project of the incubator. > > > > > > We’re gearing towards our first release under Apache, and we’re very > > > excited to be approaching this important milestone. > > > > > > Some resources [1] [2] that we found already guided us in the right > > > direction, but still, some questions remain about the release process > > > itself. > > > > > > We understand that in Apache, releases are done from the source code > > > perspective, not the binaries/artifacts’. However, we still don’t > > > understand very clearly how Apache verifies signatures and checksums > > > of the binaries that are eventually published. > > > > > > > It is better that in case you provide binaries to your users those binaries > > are released together with the sources during the same VOTE. > > > > Having reproducible builds would help a lot, but that's not always easy to > > do. > > > > In your VOTE you should stage all the sources and binaries, signed with the > > same signature (by the release manager) and the same artifacts will be > > promoted in case of a successful VOTE. > > > > The PMC can at least verify the signatures and any digests that are staged > > as part of the VOTE. > > > > Please note that if you don't have a reproducible build the PMC will never > > be able to verify that the binaries match the sources. > > > > > > > The KIE project has three main types of consumable artifacts: Maven > > > modules, Container images, and NPM packages; and we also maintain some > > > live web pages like https://sandbox.kie.org, and extensions for Chrome > > > [3] and VS Code [4]. > > > > > > For the release to be voted, we understand we have to provide a .zip > > > file containing the source code along with instructions on how to > > > build it. Once/if approved, our understanding is that the exact same > > > approved source code could be used to build and publish > > > binaries/artifacts of any sort to public registries/repositories. > > > > > > I’m laying out all the information I could gather so someone can > > > correct me if somehow I got the wrong idea of any part of the process. > > > > > > I guess the main question I have at the moment is: Are we able to pass > > > the release vote only with the sources (without any published > > > artifacts) so that once/if approved, we could publish definitive > > > binaries/artifacts to public registries/repositories? > > > > > > > You can do it. But you should state it very clearly in the downloads pages > > and in any repository. > > > > Also it is better to leverage as much as possible the ASF infra to build > > automatically such derived artifacts. > > > > Foe instance in Apache BookKeeper we build the docker images using a docker > > bot that is handled by the ASF infra > > > > > > > This question comes from the fact that we’re not sure how such a > > > “staging” environment could be created for artifacts/binaries that are > > > not Maven modules. We started a thread [5] on Slack several hours ago, > > > but no luck getting > > > I apologize if I’m lacking obvious information, and appreciate any > > > resource or reply that would put us closer to a successful release. > > > > > > > This is the right place for asking questions, not Slack. > > > > > > > Regards, > > > > > > > I hope that help > > > > Thanks for sharing your problem, this thread will be a good reference for > > other projects > > > > Enrico > > > > > > > > Tiago Bento > > > > > > > > > > > > [1] https://lists.apache.org/thread/ropp09n8m75rl6hlvnmpwcv85oyq5op9 > > > [2] https://www.apache.org/info/verification.html > > > [3] > > > > >
Re: KIE - Question about "staging" binaries/artifacts
For Java jars, the ASF has repository.apache.org - a Nexus instance that can be used to stage and later release jars. The login credentials are the same credentials you use to access other ASF resources. On Mon, 13 May 2024 at 21:28, Enrico Olivelli wrote: > Tiago, > > > Il Lun 13 Mag 2024, 22:11 Tiago Bento ha scritto: > > > Hello general@incubator, > > > > My name is Tiago Bento (@tiagobento on GitHub), and I’m one of the > > committers of the KIE project of the incubator. > > > > We’re gearing towards our first release under Apache, and we’re very > > excited to be approaching this important milestone. > > > > Some resources [1] [2] that we found already guided us in the right > > direction, but still, some questions remain about the release process > > itself. > > > > We understand that in Apache, releases are done from the source code > > perspective, not the binaries/artifacts’. However, we still don’t > > understand very clearly how Apache verifies signatures and checksums > > of the binaries that are eventually published. > > > > It is better that in case you provide binaries to your users those binaries > are released together with the sources during the same VOTE. > > Having reproducible builds would help a lot, but that's not always easy to > do. > > In your VOTE you should stage all the sources and binaries, signed with the > same signature (by the release manager) and the same artifacts will be > promoted in case of a successful VOTE. > > The PMC can at least verify the signatures and any digests that are staged > as part of the VOTE. > > Please note that if you don't have a reproducible build the PMC will never > be able to verify that the binaries match the sources. > > > > The KIE project has three main types of consumable artifacts: Maven > > modules, Container images, and NPM packages; and we also maintain some > > live web pages like https://sandbox.kie.org, and extensions for Chrome > > [3] and VS Code [4]. > > > > For the release to be voted, we understand we have to provide a .zip > > file containing the source code along with instructions on how to > > build it. Once/if approved, our understanding is that the exact same > > approved source code could be used to build and publish > > binaries/artifacts of any sort to public registries/repositories. > > > > I’m laying out all the information I could gather so someone can > > correct me if somehow I got the wrong idea of any part of the process. > > > > I guess the main question I have at the moment is: Are we able to pass > > the release vote only with the sources (without any published > > artifacts) so that once/if approved, we could publish definitive > > binaries/artifacts to public registries/repositories? > > > > You can do it. But you should state it very clearly in the downloads pages > and in any repository. > > Also it is better to leverage as much as possible the ASF infra to build > automatically such derived artifacts. > > Foe instance in Apache BookKeeper we build the docker images using a docker > bot that is handled by the ASF infra > > > > This question comes from the fact that we’re not sure how such a > > “staging” environment could be created for artifacts/binaries that are > > not Maven modules. We started a thread [5] on Slack several hours ago, > > but no luck getting > > I apologize if I’m lacking obvious information, and appreciate any > > resource or reply that would put us closer to a successful release. > > > > This is the right place for asking questions, not Slack. > > > > Regards, > > > > I hope that help > > Thanks for sharing your problem, this thread will be a good reference for > other projects > > Enrico > > > > > Tiago Bento > > > > > > > > [1] https://lists.apache.org/thread/ropp09n8m75rl6hlvnmpwcv85oyq5op9 > > [2] https://www.apache.org/info/verification.html > > [3] > > > https://chromewebstore.google.com/detail/bpmn-dmn-test-scenario-ed/mgkfehibfkdpjkfjbikpchpcfimepckf > > [4] > > > https://marketplace.visualstudio.com/items?itemName=kie-group.vscode-extension-kie-ba-bundle > > [5] https://the-asf.slack.com/archives/CBX4TSBQ8/p1715605377484379 > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > >
Re: KIE - Question about "staging" binaries/artifacts
Tiago, Il Lun 13 Mag 2024, 22:11 Tiago Bento ha scritto: > Hello general@incubator, > > My name is Tiago Bento (@tiagobento on GitHub), and I’m one of the > committers of the KIE project of the incubator. > > We’re gearing towards our first release under Apache, and we’re very > excited to be approaching this important milestone. > > Some resources [1] [2] that we found already guided us in the right > direction, but still, some questions remain about the release process > itself. > > We understand that in Apache, releases are done from the source code > perspective, not the binaries/artifacts’. However, we still don’t > understand very clearly how Apache verifies signatures and checksums > of the binaries that are eventually published. > It is better that in case you provide binaries to your users those binaries are released together with the sources during the same VOTE. Having reproducible builds would help a lot, but that's not always easy to do. In your VOTE you should stage all the sources and binaries, signed with the same signature (by the release manager) and the same artifacts will be promoted in case of a successful VOTE. The PMC can at least verify the signatures and any digests that are staged as part of the VOTE. Please note that if you don't have a reproducible build the PMC will never be able to verify that the binaries match the sources. > The KIE project has three main types of consumable artifacts: Maven > modules, Container images, and NPM packages; and we also maintain some > live web pages like https://sandbox.kie.org, and extensions for Chrome > [3] and VS Code [4]. > > For the release to be voted, we understand we have to provide a .zip > file containing the source code along with instructions on how to > build it. Once/if approved, our understanding is that the exact same > approved source code could be used to build and publish > binaries/artifacts of any sort to public registries/repositories. > > I’m laying out all the information I could gather so someone can > correct me if somehow I got the wrong idea of any part of the process. > > I guess the main question I have at the moment is: Are we able to pass > the release vote only with the sources (without any published > artifacts) so that once/if approved, we could publish definitive > binaries/artifacts to public registries/repositories? > You can do it. But you should state it very clearly in the downloads pages and in any repository. Also it is better to leverage as much as possible the ASF infra to build automatically such derived artifacts. Foe instance in Apache BookKeeper we build the docker images using a docker bot that is handled by the ASF infra > This question comes from the fact that we’re not sure how such a > “staging” environment could be created for artifacts/binaries that are > not Maven modules. We started a thread [5] on Slack several hours ago, > but no luck getting > I apologize if I’m lacking obvious information, and appreciate any > resource or reply that would put us closer to a successful release. > This is the right place for asking questions, not Slack. > Regards, > I hope that help Thanks for sharing your problem, this thread will be a good reference for other projects Enrico > > Tiago Bento > > > > [1] https://lists.apache.org/thread/ropp09n8m75rl6hlvnmpwcv85oyq5op9 > [2] https://www.apache.org/info/verification.html > [3] > https://chromewebstore.google.com/detail/bpmn-dmn-test-scenario-ed/mgkfehibfkdpjkfjbikpchpcfimepckf > [4] > https://marketplace.visualstudio.com/items?itemName=kie-group.vscode-extension-kie-ba-bundle > [5] https://the-asf.slack.com/archives/CBX4TSBQ8/p1715605377484379 > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
KIE - Question about "staging" binaries/artifacts
Hello general@incubator, My name is Tiago Bento (@tiagobento on GitHub), and I’m one of the committers of the KIE project of the incubator. We’re gearing towards our first release under Apache, and we’re very excited to be approaching this important milestone. Some resources [1] [2] that we found already guided us in the right direction, but still, some questions remain about the release process itself. We understand that in Apache, releases are done from the source code perspective, not the binaries/artifacts’. However, we still don’t understand very clearly how Apache verifies signatures and checksums of the binaries that are eventually published. The KIE project has three main types of consumable artifacts: Maven modules, Container images, and NPM packages; and we also maintain some live web pages like https://sandbox.kie.org, and extensions for Chrome [3] and VS Code [4]. For the release to be voted, we understand we have to provide a .zip file containing the source code along with instructions on how to build it. Once/if approved, our understanding is that the exact same approved source code could be used to build and publish binaries/artifacts of any sort to public registries/repositories. I’m laying out all the information I could gather so someone can correct me if somehow I got the wrong idea of any part of the process. I guess the main question I have at the moment is: Are we able to pass the release vote only with the sources (without any published artifacts) so that once/if approved, we could publish definitive binaries/artifacts to public registries/repositories? This question comes from the fact that we’re not sure how such a “staging” environment could be created for artifacts/binaries that are not Maven modules. We started a thread [5] on Slack several hours ago, but no luck getting definitive answers. I apologize if I’m lacking obvious information, and appreciate any resource or reply that would put us closer to a successful release. Regards, Tiago Bento [1] https://lists.apache.org/thread/ropp09n8m75rl6hlvnmpwcv85oyq5op9 [2] https://www.apache.org/info/verification.html [3] https://chromewebstore.google.com/detail/bpmn-dmn-test-scenario-ed/mgkfehibfkdpjkfjbikpchpcfimepckf [4] https://marketplace.visualstudio.com/items?itemName=kie-group.vscode-extension-kie-ba-bundle [5] https://the-asf.slack.com/archives/CBX4TSBQ8/p1715605377484379 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
