Kudos and feedback: Bitbucket Pipes

[neomatrix369]

I know I have raised a number of questions and issues in the last two weeks using Bitbucket the latest being Bitbucket Pipe, apparently, I didn't have too many issues that I couldn't solve myself.

Overall kudos to the teams that worked to make this feature amazing.

Although there have been two improvements that can be made to the docs https://confluence.atlassian.com/bitbucket/how-to-make-a-pipe-for-pipelines-966051288.html. 

For the simple or complete examples, the final `bitbucket-pipeline.yml` is missing the deployment directive without which the pipeline is not activated. And this applies to both the Test and Push and Tag stages:

test: &test

    deployment: test

push: &push

    deployment: production

My other feedback would be improvements to the release.sh script. Currently, it does not handle an edge case fully i.e. if a git commit results in no changes to a release then we get this error: No changes to release. Skipping release process.

And the build breaks, I think the build should not break, instead, silently exit with the above message.

I have tried to work around with this:

##
# Step 1: Generate new version
##
previous_version=$(semversioner current-version)
semversioner release &> $(pwd)/semversioner-output
foundNoChangesMessage=$(grep "No changes to release. Skipping release process." $(pwd)/semversioner-output || true)
if [[ ! -z "${foundNoChangesMessage}" ]]; then
   echo "Skipping rest of the steps"
   cat $(pwd)/semversioner-output
   exit 0
fi
new_version=$(semversioner current-version)

Although my build is still marked as failed despite exit 0 - any suggestions around this issue?

The docs do not clearly specify if you can use another SCM repository to host your pipes code or does it have to be on Bitbucket?

[Raul Gomis]

Hey @neomatrix369 ,

Thanks for the Kudos! the team definitely appreciates it.

is missing the deployment directive without which the pipeline is not activated

The pipeline can be activated and work without the directive, however it is recommended to use it so that you have more visibility on what has been deployed on each environment. We'll add it to our examples.

My other feedback would be improvements to the release.sh script. Currently, it does not handle an edge case fully i.e. if a git commit results in no changes to a release then we get this error: No changes to release. Skipping release process.

The idea behind our proposal in `release.sh` is that every time you create a pull-request and merge to master it will generate a new version based on the changeset file specified with `semversioner` (that's why the changeset file is always mandatory).

• Would you mind sharing what development / deployment workflow you are using?
• Aren't you releasing every time you merge to master?
• Which types of changes you are merging to master and you don't want to release?

Maybe it'd be great if you could share an example.

Thanks for the feedback!

Regards,

Raul

[neomatrix369]

Hi @Raul Gomis 

Glad to hear about your teams response.

The pipeline can be activated and work without the directive, however it is recommended to use it so that you have more visibility on what has been deployed on each environment. We'll add it to our examples.

With regards to the above, its a technical difficulty, if the directive is absent, you CANNOT deploy the pipeline, it simply won't move to the next stage where you can execute the pipeline - it's easy to reproduce, have a look at the commits on https://bitbucket.org/meterian-bot/bitbucket-meterian-pipe/src/master/bitbucket-pipelines.yml (and reverse the commits till the directive is removed).

The idea behind our proposal in `release.sh` is that every time y...

I agree with what you are saying. Although every pipe would have two parts the source that is code to the pipe and supporting files (README, docs, scripts to build and test the pipe). The support files are not necessarily candidates of versioning in my view since `semversioner` in the provided example scripts do not track them.

You will see the pipe CI/CD flow is broken - https://bitbucket.org/meterian-bot/bitbucket-meterian-pipe/addon/pipelines/home#!/results/7, although I have put a check in the release script to not release or increment a version in case `semversioner` does not see a change has occurred, see https://bitbucket.org/meterian-bot/bitbucket-meterian-pipe/src/master/ci-scripts/release.sh.

Although the script fails - maybe because it needs to be written differently. I hope I have been able to give you an example that throws light on my query over the release script. If we can fix this, it will be a good example covering both the happy path and the one other potential edge case.

Look forward to your response.

Thanks,

Regards,

Mani

[neomatrix369]

@Raul Gomis Any feedback for me on this one? Would really help to get to know what your thoughts are.

[Raul Gomis]

Hi @neomatrix369 ,

With regards to the above, its a technical difficulty, if the directive is absent, you CANNOT deploy the pipeline, it simply won't move to the next stage where you can execute the pipeline - it's easy to reproduce, have a look at the commits on https://bitbucket.org/meterian-bot/bitbucket-meterian-pipe/src/master/bitbucket-pipelines.yml (and reverse the commits till the directive is removed).

I can see from your commit (https://bitbucket.org/meterian-bot/bitbucket-meterian-pipe/commits/bfd051976fbfb5e2f749338988961ff8087f5122) that you enabled pipelines by clicking into the Deployments section in the sidebar. You can enable pipelines by clicking into the Pipelines section, and in that case, you don't need the deployment directive. 

I agree with what you are saying. Although every pipe would have two parts the source that is code to the pipe and supporting files (README, docs, scripts to build and test the pipe). The support files are not necessarily candidates of versioning in my view since `semversioner` in the provided example scripts do not track them.

We designed it (with continuous deployment) so that every change in the master branch is released. The README.md and docs should still be versioned and released, as documentation is also a deliverable. If you don't want to release your pipe every time you merge to master I would recommend to:

• Configure a manual step in the production step, so that you can accumulate changes in master and release it when you need it by clicking the button. Add `trigger: manual` in the YAML configuration file. See more details here: https://confluence.atlassian.com/bitbucket/run-pipelines-manually-861242583.html
• Have a develop branch in which you can accumulate changes (with multiple changeset files) and then you can merge it to master when you want to generate a release.

I wouldn't encourage to make the build successful when there is no changeset file, as you won't be able to know easily whether you did a release or not. However, you can totally adapt your release process to whatever works better for your team.

Regards,  

Raul

[neomatrix369]

Hi @Raul Gomis 

With regards to the first feedback I shared, I followed the docs on your site and found that the workflow had changed - so your advices on them are not going to help the next user who tries to go thru the docs - I suggest update the docs and if necessary the workflow (with the help of your engineering team), to make the journey frictionless for your users.

About the build process advice, we would like to be able to keep things simple and just now we are not able to do it. Unfortunately, we can't apply your advices as it does not work for us. Just a matter of help can someone from your tech support or engineering team give any suggestion on how to achieve what we are trying to do with https://bitbucket.org/meterian-bot/bitbucket-meterian-pipe/src/master/ci-scripts/release.sh. Our goal is for all code changes that builds and tests successfully we would like to release and go green. For non-code changes we still like to stay green and record that in our build logs that it has a non-code change. For all else that are good reasons for a failed build we are happy to break the build.

I have made amendments to the `release.sh` as you can see from the link above, but it does not seem to work and also breaks for reasons unclear to me:

This block of code tries to see if semversioner returns `No changes to release. Skipping release` and we want to exit with a code of 0 - passing the build and recording in the logs that it's not a release as no code changes have been made / detected.

```

foundNoChangesMessage=$(grep "No changes to release. Skipping release process." $(pwd)/semversioner-output || true)
if [[ ! -z "${foundNoChangesMessage}" ]]; then
echo "Skipping rest of the steps"
cat $(pwd)/semversioner-output
exit 0
fi

```