Support for `condition`

[Andreas Sundqvist]

Hi

What I can see the library don't support condition and changesets

I saw that you have a test yaml file with the structure test/data/yml/condition.yml but it don't seem to be used for anything else than to verify that its a valid pipeline config

So is this something that would be possible to implement or would you be open to a pull-request?

---

Yes we use git. And we only use it in BitBucket

How the detection work in BitBucket:

• In the branches sections they looks in the last commit and sees if any files matches the includePaths and if so run the step. This should be fairly simple to implement
• In the pull-requests section it will look in all commits for changes that matches includePaths. This might be harder but maybe we could require an option with a destionation branch and do the check against that diff?

Usage example:

pipelines:
  pull-requests:
      '**': #this runs as default for any branch not elsewhere defined
          - step:
                script:
                    - phpunit
                condition:
                    changesets:
                        includePaths:
                            - src/
                            - composer.lock

          - step:
                script:
                    - eslint
                condition:
                    changesets:
                        includePaths:
                            - js/

    branches:
        master:
            - step:
                  script:
                      - phpunit
                  condition:
                      changesets:
                          includePaths:
                              - src/
                              - composer.lock

[Tom Klingenberg]

Hey @sunkan, thanks for your interest!

What I can see the library don't support condition and changesets

That is correct.

I saw that you have a test yaml file with the structure test/data/yml/condition.yml but it don't seem to be used for anything else than to verify that its a valid pipeline config

This is to ensure that pipelines don't choke on them, yes. It also shows we're aware such a feature exists.

So is this something that would be possible to implement or would you be open to a pull-request?

Sure, both ;) It was just so far this was never requested. And I personally had no hard requirement for it.

Can you please share your concrete use-case (e.g. exemplary use with a (reduced) bitbucket-pipelines.yml file) here as a comment (or even better edit the specifics into your first comment so this is visible upfront)? It's since quite some time I last looked into that feature and it would help me better understand your requirements.

Also please let me know which version control system you're using for that project (e.g. git probably) and the version of it.

My educated guess is that the information will be from the VCS (currently unimplemented) to identify whether or not the condition is met.

So also please let me know what is preferable for executing local (.e.g. changes between two revisions) and if you have requirements to also run this remote in CI somewhere (apart from Bitbucket itself) so that this is visible upfront and the implementation can be made as reduced as possible (the more concrete the requirements are the better).

[Tom Klingenberg]

Thanks for updating the issue and the additional clarification @sunkan. This already answers a couple of question that came to my mind, very helpful.

A steps.condition entry will be added to the TODO in the read-me in the next release (0.0.60).

This feature requires a couple of preparing steps in my eyes, all I'd like to get into pipelines:

• project directory abstraction
• git detection
• obtaining the list of changed paths via git (likely git-log)

The existing pattern/path matching is likely fitting and if not I'd assume it require only little changes/additions.

The conditional check would run before executing the step, on the host.

Do you make use of the --trigger option when running pipelines (did you knew it exits)?

[Tom Klingenberg]

The last two releases were driven by changes while looking into supporting <pipeline>.step.conditions.

Parsing the condition has been roughly done and more sooner than later we can push another release so that --show and --show-pipelines annotates steps with conditions already. It's not much of the functionality.

Now I have to think about the git integration and what the best behaviour is running pipelines without additional parameters. For that I could benefit again from your feedback @sunkan

So if you don't mind to share your thoughts, that would be great. Given to execute pipelines "as-is", what would you consider to happen? Should the git integration detect which kind of pipeline is to be run? If so what would be your expectations?

Earlier I was thinking about to have this influenced by --trigger, however that switch is merely for the situation when no vcs (git) is in use. As with this feature we'll start to have git integration, so if from checkout it is possible to detect the pipeline to run already, it would be good to know if that would be expected.

For development/testing I'm also considering to just take the last commit plus maybe staged file paths (and perhaps also non-staged modified and/or untracked files that are not ignored) to ease testing. This may be put behind a command-line flag so that I can file releases for user-tests until the feature stabilizes (questions can be often better answered by just executing and getting a feeling what is useful and what can be improved I can imagine). This should allow to see conditions already in action as it would create the list of paths to check the condition against. Also the git integration must not be that advanced as the information from git vcs is to generate a list of pathnames only, which is needed to run the conditions against.

Additionally similar to --no-manual there should come (an) argument/s to control conditions, a --conditions[=<mode>] argument, the current design:

• --conditions (with no <mode> option) as an alias for --conditions=stop for now.
• --conditions=auto is the default mode to have the current behaviour and change it later. As-if --conditions would not be passed on the command-line. auto will map to ignore for now.
• --conditions=ignore conditions are ignored and any step with conditions is run as-if there were no conditions (current behaviour).
• --conditions=skip steps with conditions aren't run. That is a new behaviour. Run continues on the next step, continuing effectively with the next step that has no conditions. If there is no further pipeline step without conditions, then pipelines exits with zero exit-status.
• --conditions=debug stops at a step with conditions and shows for each pattern the pattern and paths matching from the project directory (working tree / working dir), followed by a --step argument example how to continue for a or no match. Exit status is non-zero.
• --conditions=vcs-debug similar to debug, but providing additional information from/about vcs (git).
• --conditions=stop stops at a step with conditions and shows the patterns, followed by a --step argument example how to continue for a or no match. Exit status is non-zero.

(sorry for this wall of text)

[Tom Klingenberg]

Short update, in 0.0.65 conditions are now read from file and annotated as *C with --show and --show-pipelines.

The release is not adding any other functionality though.