<p>Just to make sure I understand, you have the following situation...</p>
<ol>
<li>You change the code for a component</li>
<li>You commit the code</li>
<li>An automated build runs</li>
<li>The artifact is published</li>
</ol>
<p>And you are thinking, why stop there? You have projects that depend on this component, so can't it &quot;cascade&quot; onwards, so the application that depends on the component gets the updated dependency.</p>
<p>This <em>is</em> something that is emerging. GitHub has Dependabot, which can submit pull requests for updated dependencies. You need to manually review them, but that's <em>close</em> to what you're talking about.</p>
<p>Because Dependabot looks at all your dependencies, it may update interal and external ones. The pull request process helps you review the changes it makes. You can set it up to achieve your desired noise-level (you can run it once a week, for example), so it's not quite &quot;on artifact change&quot;.</p>
<p>More tools are starting to appear in this space as software supply chain security is a hot topic.</p>
<p>I'm sure this will concept will develop further.</p>

CC BY-SA 4.0
2023-03-31T08:26:06.787Z
2023-03-31T08:26:06.787Z
Fenton
<p>I am wondering about this:<br />
we are all used to continuous build. I.e. every push of source code to a version control system triggers a build job on a build system (Jenkins, GitLab CI/CD, whatever, ...) that builds the source code.
Builds produce artifacts, usually libraries (jar files, dll files, whatever ...) that are pushed to an artifact storage (Nexus, artifactory, GitLab package registry, whatever ...).<br />
Then builds trigger other builds of components that depend on the just created artifacts.
This in turn triggers further builds up the software dependency hierarchy.</p>
<p><strong>Q</strong>: why do only updates of source code trigger builds jobs, but updates of artifacts in an artifact store don't? Is there a specific reason?</p>
<p>At least the environment I'm used to (Jenkins, GitLab CI/CD, Nexus, GitLab package registry) works like that.<br />
<strong>Q</strong>: are there other environments (build automation systems, artifact stores, whatever, ...) that include job triggers by any artifact update?</p>

<build-pipeline><builds><artifacts>
Builds triggered by change of arbitrary artifacts?
Pirx
# Builds triggered by change of arbitrary artifacts?

(Asked by: username_0 on 2023-03-31)

I am wondering about this:  
we are all used to continuous build. I.e. every push of source code to a version control system triggers a build job on a build system (Jenkins, GitLab CI/CD, whatever, ...) that builds the source code.
Builds produce artifacts, usually libraries (jar files, dll files, whatever ...) that are pushed to an artifact storage (Nexus, artifactory, GitLab package registry, whatever ...).  
Then builds trigger other builds of components that depend on the just created artifacts.
This in turn triggers further builds up the software dependency hierarchy.

**Q**: why do only updates of source code trigger builds jobs, but updates of artifacts in an artifact store don't? Is there a specific reason?

At least the environment I'm used to (Jenkins, GitLab CI/CD, Nexus, GitLab package registry) works like that.  
**Q**: are there other environments (build automation systems, artifact stores, whatever, ...) that include job triggers by any artifact update?

**Tags:** build-pipeline, builds, artifacts


---

## 1 answers

### Answer by username_1 on 2023-03-31. Score: 0

Just to make sure I understand, you have the following situation...

1. You change the code for a component
2. You commit the code
3. An automated build runs
4. The artifact is published

And you are thinking, why stop there? You have projects that depend on this component, so can't it "cascade" onwards, so the application that depends on the component gets the updated dependency.

This *is* something that is emerging. GitHub has Dependabot, which can submit pull requests for updated dependencies. You need to manually review them, but that's *close* to what you're talking about.

Because Dependabot looks at all your dependencies, it may update interal and external ones. The pull request process helps you review the changes it makes. You can set it up to achieve your desired noise-level (you can run it once a week, for example), so it's not quite "on artifact change".

More tools are starting to appear in this space as software supply chain security is a hot topic.

I'm sure this will concept will develop further.


---

