-
Currently, I do not believe there is a way to run a step (or even a job) if a branch matches a certain pattern. It is only possible to run an entire workflow on a master/tagged branch, but this requires duplicating the workflow just to add another step for releasing/publishing. I could also create an action for the build/test steps, but both creating an action and duplicating the code seem superfulous and more likely to cause errors since someone could forget that both files need to be edited. A common example of this would be:
Am i missing something and there is an easy way to do this? I know i can do:
but that only works when you know the branch/tag exactly and something like (with pattern):
does not work. Right now the best approach I can think of is to create some type of conditional-step-action that will allow you to input your if condition and then run the step if the branch/tag condition matches, but exit without failing if it does not (so as not to fail the job). |
Beta Was this translation helpful? Give feedback.
Replies: 8 comments 4 replies
-
Hi @bhowell2, First, you do not need to use conditional syntax with the “if” statement. See the following excerpt from: "About context and expressions" When you use expressions in an if conditional, you do not need to use the expression syntax ({{ }}) because GitHub automatically evaluates the if conditional as an expression. As for pattern matching with the if statement, I suggest using the contains function. Here’s an example:
|
Beta Was this translation helpful? Give feedback.
-
@bradenmthanks for the response (and noted on the if expression!). Contains does not do pattern matching, but it could definitely work. Using contains would require people to name their release tags something that is unlikely to occur elsewhere (luckily tags are generally for some type of releases anyway). As you put it “release” is a pretty good indicator that the tag is for a release. Many currently use something more of the form “v*” or maybe just a semantic versioned number (e.g. 1.0.1), but probably wouldn’t be a huge deal for people to adjust this by adding “release”, “milestone” or whatever in the tag. This would be much less of a problem anyway if workflows could be reused/referenced which would be preferred to using the IF condition at all. |
Beta Was this translation helpful? Give feedback.
-
You can use bash substitutions: e.g.
would strip refs/heads and give you “master” You should be able to use also RegExp here. Also see https://github.community/t5/GitHub-Actions/Implementing-Dry-Run-Logic-If-and-env/td-p/49882 |
Beta Was this translation helpful? Give feedback.
-
For those looking at this article today and onward, please use the new declaration for setting environment variables:
|
Beta Was this translation helpful? Give feedback.
-
You could fork https://github.com/fkirc/skip-duplicate-actions to get branch-specific skipping. With such a fork, it should be doable with less than 5 lines of code. |
Beta Was this translation helpful? Give feedback.
-
This is epic, thank you for sharing the $GITHUB_ENV trick! |
Beta Was this translation helpful? Give feedback.
-
Just FYI for anyone else using this as a reference, the values should be |
Beta Was this translation helpful? Give feedback.
-
Note that this should be single quotes around release. Otherwise you will get an invalid workflow warning. For example:
|
Beta Was this translation helpful? Give feedback.
Hi @bhowell2,
First, you do not need to use conditional syntax with the “if” statement. See the following excerpt from: "About context and expressions"
When you use expressions in an if conditional, you do not need to use the expression syntax ({{ }}) because GitHub automatically evaluates the if conditional as an expression.
As for pattern matching with the if statement, I suggest using the contains function. Here’s an example: