On Tue, 19 Dec 2023 at 12:25, Alex Herbert <alex.d.herb...@gmail.com> wrote: > > On Tue, 19 Dec 2023 at 10:41, sebb <seb...@gmail.com> wrote: > > > > Crypto now has a workflow [4] that deploys a SNAPSHOT version. > > > > I don't know if we want to do this for all components, but if so, the > > process is: > > - raise INFRA Jira to request access to the secrets that hold the > > credentials [1] > > - use the java-settings action to create a settings.xml which > > references the variables holding the credentials [2] > > - pass the secrets as environment variables in the job-step that needs > > them [3] (Note:: we don't need the GPG variable) > > > > The Crypto workflow is rather complicated because it needs to build > > the code on several different OSes and then piece the bits together. > > Other components will be much simpler. > > > > Are there any other components that would benefit from/need snapshots? > > Multi-module components are useful to deploy as snapshots if modules > depend on each other. This allows a developer to perform maven build > tasks in the module directory for the code they are working on. Maven > will download the latest snapshot for all the dependencies on other > component modules.
AIUI Maven does not check dependencies every single time; it depends when it was last checked. Unless you override this, you may not get the latest code. Also the CI build may be delayed or fail due to a non-code reason, so you may not get the code that corresponds to the local checkout. > It also allows a component to use a snapshot > dependency on another component outside the repo. This allows two > components to be developed in parallel without the developers having > to perform local installs for each change in the main branch. I agree it's a bit of a pain to have to install modules locally in order to test against them, but it does guarantee to use the latest code from the local checkout. Personally, I think Maven should use the locally compiled code from modules rather than requiring deployment/installation. > Snapshots are deployed for the RNG, Statistics, Numbers, Math and > Geometry components via Jenkins running at ci-builds.apache.org. The > use of snapshots was very useful when bugs in Numbers were found when > developing Statistics. The bugs could be fixed in the Numbers snapshot > and Statistics developers automatically obtained the fix. When dev > work is complete the components can be released in order and SNAPSHOT > dependencies removed. > > One advantage of the Jenkins set-up is that builds can be triggered by > builds in other repos. We have configured downstream projects to build > when the upstream project is updated. However this has yet to discover > an incompatibility or bug in downstream projects in the 4+ years they > have been running. So this feature is not essential. That is also the rationale for Gump - build the latest of everything and see what happens ... > I would be happy to trial a simpler (than Crypto) deploy of snapshots > using GH for one of these components, e.g. Numbers/RNG which have no > dependencies. I'll take a look. > Alex > > > > > Sebb > > [1] e.g. https://issues.apache.org/jira/browse/INFRA-25296 > > [2] https://github.com/actions/setup-java#maven-options > > [3] > > https://github.com/actions/setup-java/blob/main/docs/advanced-usage.md#yaml-example > > [4] > > https://github.com/apache/commons-crypto/blob/master/.github/workflows/maven_crosstest.yml > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
