-
Notifications
You must be signed in to change notification settings - Fork 456
Fetching latest changes Scenario 2 Module library and CI environment
In this scenario you have onboarded both the module library and the CI environment, as described in Getting started Scenario 2 - Onboard module library and CI environment and you would therefore need to fetch latest changes for both.
Depending on the DevOps environment you are using (GitHub or Azure DevOps) the number and implementation of the required steps may vary.
The update process is the following:
- 1. Sync your copy of the library
- 2. Apply specific settings to files
- 3. (Optional) Re-apply your customizations
- 4. Run dependencies pipeline
- 5. Update module parameter files
- 6. (Optional) Convert library to ARM
- 7. Push updated code
- 8. Test and publish modules
GitHub public repository
You have a public fork of public CARML source repository in your target organization.
- Keep your fork synced to the fork upstream repository, on the GitHub web UI or through the GitHub CLI or the command line, as explaind in Syncing a fork documentation.
- Sync your local copy of the fork taking care of eventual customizations you can have in place.
GitHub private repository
You have created your GitHub target repository and uploaded there the content of the CARML repository.
Clone/download CARML repository to create a local copy of it, as explained in Azure DevOps Repository section in Getting started - Scenario 2 Onboard module library and CI environment
Azure DevOps private git
You have created your target repository and uploaded there the content of the CARML repository.
Clone/download CARML repository to create a local copy of it, as explained in Azure DevOps Repository section in Getting started - Scenario 2 Onboard module library and CI environment
Personalize files with your specific settings:
- Update default name prefix
- Update variables file (
global.variables.yml) as explained in Set up variables file
There are different options for library's customization:
The recommendation is to contribute to the public CARML repository so that your updates can improve the public library. In this way your changes will be available on the public library when fetching updates, modules will be already tested with your changes and you won't need to take care of customization on each update.
In some cases, you might need to add to the library company/organization' specifics, that are not sharable with the public CARML repository.
In this scenario every time you'll fetch updates from the public CARML repository merge conflicts are expected. You'll have to compare the new public code with your customized one and re-apply your customizations to the updated code.
This process can be automated, by script or CI, if customization tasks are repeatable.
Run the 'dependencies pipeline' to update dependencies configuration that can be updated on the downloaded CARML release. Follow Deploy dependencies section in Getting started - Scenario 2 Onboard module library and CI environment documentation to do this.
Follow the Update module parameter files procedure
Follow istructions in (Optional) Convert library to ARM
Push the updated local code to your remote public fork (for GitHub public repository scenario) or on your remote target repository for GitHub private repository and Azure DevOps private git scenarios.
If actions/ pipelines are enabled test and publishing of modules starts automatically. In some cases triggers for the pipelines are not enabled, in these cases start actions/pipelines to run tests and publish modules.