-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplify the Galasa contribution + build process : 17-> 10 code repositories #1828
Comments
Tutorial to build Galasa on local: 1.- Disable GPG: galasa/modules/wrapping/.github/workflows/pr-build.yaml:78: -Dgpg.skip=true 2.- Disable check_secrets in build-locally.sh scripts 3.- Create a GPG key on your local Export the GPG key to: /home/jenkins/.gnupg/secring.gpg 4.- Add next values to your gradle.properties file: signingPassword=xxxxx 5.- Update script: galasa/modules/obr/build-locally.sh 175 #export GALASA_BUILD_TOOL_NAME=galasabld-darwin-${ARCHITECTURE} 6.- Run script: ./galasa/tools/build-locally.sh [INFO] Installing /home/jenkins/repo/galasa/galasa/modules/cli/temp/dev.galasa.example.banking/dev.galasa.example.banking.obr/target/testcatalog.json to /home/jenkins/.m2/repository/dev/galasa/example/banking/dev.galasa.example.banking.obr/0.0.1-SNAPSHOT/dev.galasa.example.banking.obr-0.0.1-SNAPSHOT-testcatalog.json Use the results.. |
Working on this task: |
Release process/automation updates in this PR: galasa-dev/automation#625 |
Updates to mono repo creator tool in this PR: galasa-dev/mono-repo-creator#1 |
Updates to the Isolated/MVP build workflows to support the new mono repo structure in this PR: galasa-dev/isolated#73 |
Updates to the CLI build workflows to support the new mono repo changes in this PR: galasa-dev/cli#299 |
This works. Marking as done. |
Story
As a Galasa code developer I want a simpler build process, so it's easier to contribute changes.
Background
Currently we have many repositories which have separate build processes. These
Lets change things to have fewer, like this:
+ves: Easier to commit atomic changes across framework/extensions/managers/obr
-ves: Slightly longer build time, as there is more code. We could speed things up with a build cache.
Question: Can VScode cope with this ? You can always open vscode one folder down in the source tree.
Tasks
Analyse the existing github workflows to see how they can be combined into one, or called from one, with information flowing between them which does not need docker images to be stood-up on infrastructure.
Create a top-level prototype of a github workflow which builds the gradle and maven modules. Demonstrating how information is shared between them.
Create a PR to the mono-repo-creator containing this top-level gh actions wizardry.
When a PR build occurs it shouldn't have to build everything if it didn't touch it.
Test with different changes in different modules, to check that the logic builds the correct things
Release processed needs changing + release documentation.
The text was updated successfully, but these errors were encountered: