nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Scheduled pipeline

Richard Tremblay

Hi,

I'm looking for a way to execute pipeline at a specific time each day but only if there's something new in a specific branch, if there's nothing new, don't run. And at the same time, to only run at that time, do not run when something is push in that branch.

The idea is to have a way to automate code pushed to a specific branch to one of our server automatically but only at a specific time, i.e. only deploy in our server at 1am.

Any idea are welcome.

Accepted answers

All comments

ktomk

You can create a custom pipeline and time it (schedule it).

A custom pipeline is immune to pushes and can be scheduled to be executed on a specific branch.

You would need to deal in the pipeline to do the change detection.

E.g. if you have a deployment package and store it on an object store like AWS S3, and the object name contains the revision, you can easily check whether or not the revision has been build already. Only if not, build it, deploy it and store it on S3.

S3 is only exemplary here. Bitbucket has downloads as well, it might work as well (e.g. you don't have or want an(other) AWS account for only having S3. The REST API is fairly straight forward for it and behind the scenes it is S3 as well, you just don't need to manage it your own.

Richard Tremblay

Thanks for your answer.

I have figured everything except how can I do the changes detection part, this is a git repository, and I want to look for changes in the current branch the pipeline is being executed.

Is there a way to do something like

If git diff current branch vs deployment branch

- Merge branch

Else

- Do nothing

ktomk

@Richard Tremblay Yes, that is possible with the git command line utility.

Given the pipeline script runs on the current branch:

when HEAD is already merged into the deployment branch, exit the pipeline script (already deployed)
when HEAD does not merge with the deployment branch, exit the pipeline script with error (does not merge and can not be deployed)
when HEAD does merge, merge it fast-forward into the deployment branch and push it upstream (origin) to trigger the deployment pipeline

Would this scenario describe your use-case requirements?

If so you might be looking for the git commands. I have no concrete example at hand but did this already so I know it's perfectly possible.

Some hints on git commands, I'm pretty sure there are others, so this is merely informative:

`git fetch origin <deployment-branch>` will ensure the merge target from origin is available remote reference `origin/<deployment-branch>` in the local clone (within the pipeline)
`git merge-base origin/<deployment-branch> HEAD` will either
1. exit non-zero if there is no merge-base (this *should* not happen, so it's fine as it paints the pipeline red then)
2. gives the git revision hash otherwise (if it's the same as HEAD it means that HEAD is merged already)
`git rev-parse --verify HEAD` gives you the actual commit from the pipeline, so this is HEAD as the revision head.
`git merge ...` and `git push ...` I assume you know already and can handle them.

Some caveat:

In Bitbucket Pipelines the HEAD revision is available as well as a Bitbucket Pipelines variable (`$BITBUCKET_COMMIT`) which kicked of the pipeline. I have found it unstable in the meaning that it was sometimes in the short form and sometimes in the long form.

This is cumbersome for comparing, e.g. the short one might reference the same revision but does not work in a string comparison when it's against the long one.

The `git rev-parse --verify <ref>` command does help here to turn it into the full (long) revision hash. That command will also fail if `<ref>` can not be verified.

Summing it up:

Finding about differences is making use of the version control system, here git. This requires understanding git a bit more and also how to obtain all needed revisions to make the decisions you need to make.

A Bitbucket pipelines script is effectively a shell script, so it's easy to call the diverse git commands and also do decisions based on string comparison and similar tests.

One example for such a test:

test ! -z "$(git merge-base deploy HEAD)" -a ! "$(git merge-base deploy HEAD)" = "$(git rev-parse --verify HEAD)"

test for 1.) there is a merge base AND 2.) the merge base is not at HEAD

See `man test`, `man git-merge` and `man git-rev-parse` for detailed information.

If you've got a shell at hand, you can write a shell script for a first test as long as the git utility is available on the command-line.

To test further with pipeline integration you can consider to simulate pipelines with more scripts and docker or a local Bitbucket Pipelines runner which does the heavy lifting (intended as an out-of-the-box experience, disclosure: I'm the author of it, your mileage may vary).

Hope this helps you to further improve your pipeline and enables you to reach your goals.

Richard Tremblay

That is exactly what I want, thank you again!

I'll do a few test and let you know how it turns out.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

bitbucket-pipelines