Re: [NUMBERS] GH deploy snapshot test
Thanks Sebb, Note that previously the GH action was running the default goal: 'clean verify javadoc:javadoc'. Since we now need to specify the 'deploy' goal as well the above defaults can be switched in for your additions when Infra have created the credentials. Alex On Tue, 19 Dec 2023 at 14:29, sebb wrote: > > Created https://issues.apache.org/jira/browse/INFRA-25297 to get > access to credentials > > Added code to maven.yml to deploy the snapshot (needs to be enabled > when creds are granted) > > - > 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
Re: [ALL] Deploying SNAPSHOTS from GH workflows
I think it would be a nice-to-have feature for all active components, allowing us to achieve parity with what used to happen with Jenkins (which I never used and rarely pay attention to). When can then drop all Jenkins build and free up those resources. Gary On Tue, Dec 19, 2023, 5:41 AM sebb 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? > > 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 > >
[NUMBERS] GH deploy snapshot test
Created https://issues.apache.org/jira/browse/INFRA-25297 to get access to credentials Added code to maven.yml to deploy the snapshot (needs to be enabled when creds are granted) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Deploying SNAPSHOTS from GH workflows
On Tue, 19 Dec 2023 at 12:25, Alex Herbert wrote: > > On Tue, 19 Dec 2023 at 10:41, sebb 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
Re: [ALL] Deploying SNAPSHOTS from GH workflows
On Tue, 19 Dec 2023 at 10:41, sebb 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. 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. 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. 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. 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
[ALL] Deploying SNAPSHOTS from GH workflows
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? 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
