Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Is it possible to create a generic pipeline, and use it in other projects?

Oneide Luiz Schneider September 16, 2020

I have many Microservices in Java.

The idea is to create just one pipeline(bitbucket-pipelines.yml) for all the same projects, and put what is common.

Steps:

  • Create one bitbucket-pipelines.yml with the common values
  • Import this YML in all the other projects.

So, with that, we can change in just one file, instead of a change in every .yml.

For example in gitlab it's possible with include: file:

1 answer

0 votes
ktomk
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 16, 2020

AFAIK Bitbucket Pipelines has no pre-processor that can import/include YAML partials before being executed.

YAML doesn't have either.

So no, not possible the way it's done in Gitlab on Bitbucket.

But that's perhaps looking at the wrong side of the problem.

Have you considered to use the same build container for this many micro services project?

It should have what is common, just the sane defaults.

You could also favor convention over configuration.

ktomk
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 16, 2020

Following the rationale and part of the discussion in Include external files in .gitlab-ci.yml (Gitlab Foss; Aug 2016) what might be a mapping in Bitbucket Pipelines next to the build image are Pipes.

Oneide Luiz Schneider September 22, 2020

Hi, thanks for your answer.

I've got a base image for all these MS(microservices).
I tried Pipes but still are not good enough.

I tried a different approach right now.
Because the problem/difficulty was on CI not on the approach of the MS.
If it works well I'll come back here and answer.

 

Thanks a lot.

ktomk
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 22, 2020

No concrete idea about your problem, if you need bootstrapping that is shared across multiple pipelines (like a one-size-fits-it-all approach) configured in a central repository:

  • vendor a bootstrap script in all of the subscribing repositories which
    • checks out one or more git sub-modules during the build (needs configuration on Atlassian Bitbucket Pipelines add-on, ref: Bitbucket Pipelines and git submodules ) -or- just downloads a non-versioned payload (via curl or alike) which would re-present the include on Gitlab
    • invokes commands/scripts within those checked out submodules/payload(s)

Similar to the Gitlab includes is that it is an include, just thinly implemented for Atlassian Bitbucket Pipelines.

A downside is, that you need to implement this your own (not configurable within the bitbucket-pipelines.yml file directly but a bit more indirectly as instead on the level of yaml, it's an "include" command in the step script. The simpler this is, normally the better.

I somewhat tend to git sub-modules here despite they are a bit bulky and tend to appear to stand in the way. And specifically on Bitbucket they need some configuration work. Nevertheless look into them.

On the plus side you have more control and by using a git repository as sub-module a much more controlled environment compared to the Gitlab include feature (think security, versioning and configuration management).

Your mileage may vary, just idea/options outlines here.

What I normally do is having a script in the repository that is getting called in a step script line. This keeps the yaml file clean and gives more flexibility (change a process instead of the yaml file [overall build process]. In your scenario it could do the bootstrapping and then execute a shared payload across multiple repositories).

The dirtiest resolution would be to download a script and execute it directly. Take care with such an approach, it has severe implications. Same applies to the Gitlab approach IMHO, I'm not sure that it is actually not flawed as it circumvents many of the pre-cautions that are to be considered.

Only it works often doesn't mean it's done. Take care and looking forward to your feedback and comments.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events