I have a project organized in the following tree
|.
|..
|-- devops
|-- project1
|-- project2
In the devops folder, I have included the other two projects as submodules, since these two projects are developed independently by two different teams.
|.
|..
|-- project1@0deed0fa
|-- project2@0beef0fb
|-- .gitlab-ci.yml
I have setup the pipeline to deploy the projects. Whenever there are new commits on any of the projects, a trigger is setup to run the devops
project pipeline. As part of the devops jobs, I run git submodule
commands to fetch and merge. Then build. It works.
The problem I have is, over a period of time, there are a lot of changes made to the submodules. The changes from the last submodule commit to the devops project folder is replayed every time there is a commit on any of the projects. Once a month, I manually update the devops
project folder and update to the latest commit of the submodule projects. I can commit the changes from the devops pipeline task, but that will generate new pipeline in the same devops pipeline. (I didn't test it but it seems obvious).
Is there any way I can update the submodules to the latest commit as part of the devops pipeline?
Thanks.
Using git submodules are not the best practice for implementing an integration pipeline. The seminal book Continuous Delivery states the following in the section Only Build Your Binaries Once
(Chapter 5):
Many build systems use source code held in the version control system as the canonical source for many steps. The code will be compiled repeatedly in different contexts during the commit process, again at acceptance test time, [etc.] Every time you compile the code, you run the risk of introducing some difference.
Also, recompiling takes a lot of time, resulting in longer feedback cycles. The recommendation is:
You should only build your binaries once, during the commit stage of the build. These binaries should be stored in a filesystem somewhere [...] where it is easy to retrieve them for later stages of the pipeline.
Following this paradigm, your workflow would look something like this:
project1
and project2
will push a commitrelease
repositoryNotice how the source code is only built once.
There are a number of popular binary repositories available. Most have a free and paid pro version. Check their websites for more info.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.