1

Using Jenkins and pipelines;

I have one repo which drives deployments and cloning its Jenkinsfile should kick off a new build; but I need the jenkins job which wraps it to watch another repo representing the site (not its build process), to watch for and build changes to the site, expected to change often, rather than the build process which hopefully will soon be stable and not subject to much additional change.

Can anyone please advise me how it is I would accomplish this feat?

Hugh Esco
  • 67
  • 1
  • 6
  • Thanks, Joerg S. Yes, you seem to get the use case here. I do not want drupal site developers to have to know jenkins and pipeline, nor do I want to give them an opportunity to mess with what works, or replicate the jenkinsfile's and their supporting build scripts across a bunch of drupal sites where maintenance will become impossible. I will explore how a git post-commit trigger might make this work. – Hugh Esco Apr 30 '18 at 17:27
  • This post did an even better job of articulating what it is I am trying to do here, and gave me a link to a recipe for the git hook, which may not work for him, but poses for me none of the issues he was concerned with. https://stackoverflow.com/questions/41116169/how-can-i-have-a-jenkins-pipeline-build-be-triggered-from-a-repository-with-no-j?rq=1 – Hugh Esco Apr 30 '18 at 17:43

2 Answers2

1

Use the jenkins build step.

In the repo experiencing the changes, have its Jenkins job kick off a https://jenkins.io/doc/pipeline/steps/pipeline-build-step/ for the repo you want to build. You can configure the build step to either wait or not wait for the result of the kicked off job.

build(job: "org/${jobName}/${BRANCH_NAME}", 
    parameters: [
        new StringParameterValue('ENV', env),
        new StringParameterValue('ENV_NO', env_no),
    ],
    propagate: false, 
    wait: false,
)
metalisticpain
  • 2,698
  • 16
  • 26
1

Usually I‘d recommend to have the Jenkinsfile in the very same repository like your source code. Only that way you will have a combined history so it‘ll be much easier to reproduce an older build from - let’s say - one year ago.

However if you still want to go for the separation: The git/checkout steps will usually have the possibility to add a hook in Jenkins so the job will get triggered automatically on changes.

If I did understand your use case correctly the Jenkinsfile will go into stable state. If it’s stable it won’t change. When there are no changes it won’t trigger the job, right?

If that still is not enough I think I would need more details on what you’re trying to achieve and why.

Joerg S
  • 4,730
  • 3
  • 24
  • 43