automation - Epic creation when a certain new version is created

[Christophe H-M]

For each major release we need to create couple of generic Epics (for packaging, documentation, maintenance, etc). I'm looking for automation as I think it is the best solution and I'm facing couple of difficulties.

Preliminary information:

• The versions usually follow this pattern: "ProductName year.update - Milestone"
  • ProductName being a certain string, its length can vary and it can contain dot or other special characters. --> I'm ok to have this part given in the pattern definition
  • year.update: usually the year is on 4 digits and the update on 1 digit, separated by a dot. But it could be also a version on 2 digit + an update on 1 digit (xx.y) --> this should be recognized in the pattern
  • Milestone can be Alpha or Beta or Release or anything else (Feature Freeze, Proto...) --> here I want the rule to be triggered only for "Release" milestone so this has to be given in the pattern definition

The rule I created for now (which doesn't work) is as follow:

• When: version created
  • version name filter "ProductName.......-.Release"
• Then: Create a new issue
  • Project = myProject
  • issuetype = Epic
  • Summary = "{{version.name}} Production"
  • Fix version = {{version.name}}

Now my questions:

1. I'm sure the pattern for version recognition can be improved. But I'm not a developer and the pointed documentation is not really of help for me. The pattern works but if the version is not yyyy.u then it doens't work anymore.
2. the epic creation doesn't work. I assume the {{version.name}} is not working.
   1. in documentation I can see the smart value being {{version}} therefore I tried {{version.name}} without success
   2. the rest of documentation doesn't mention the smart values from versions (it does for project, issues, lists...)

Anybody to help?

[Bill Sheboy · Accepted solution]

Hi @Christophe H-M 

For a question like this, please post an image of your complete automation rule, images of any relevant actions / conditions / branches, an image of the audit log details showing the rule execution, and explain what is not working as expected.  Those will provide context for the community to offer ideas.  Thanks!

Until we see those...

For the regular expression, you seem to have some variability for the naming.  Perhaps try using the digit matcher \d for your patterns, and specifically look for "- Release" at the end.

For the epic, {{version.name}} should work for the Summary, but to set the Fix Version instead use the id with {{version.id}}

Kind regards,
Bill

[Christophe H-M]

Hi @Bill Sheboy 

I thought the pictures would not add any valuable info therefore I didn't send that. However no problem to share them. Please find below the automation rule:

Note: I modified the pattern and this one seems to work pretty well for my need, so only my second problem remains (epic creation).

The details of the Epic creation is like

As you see it is a very simple rule for now (I'll complexify step by step). Just create an Epic in the given project - VRE (I tried "in same project but it didn't change anything) and just set the summary and the fix version.

I set {{version.id}} as you suggested but it didn't help. At least I don't know if it improves or not since the error message is of no help for me.

Here we see the first (below) trial were I gave a different name than Release to check if the naming pattern was working and it seems it is ok.

Then I made another trial with the right name (upper) and the rule passes to the next step which is Epic creation. But then "some error" happened.

I don't know if I can trigger some more debug information.

Thanks for your support

Christophe

[Bill Sheboy]

Sorry for my mistake, as when I just tested an example rule, I found that the name must be used to set the fix version in the issue create: {{version.name}}

Please try that and let me know what you observe.

Also...Are you trying to create an issue in the same project where the version is created, or in a different project?  I tested in the same project, with a project-scope rule.

[Christophe H-M]

Hi

I tried also with {{version.name}} but it doesn't change.

I tried using the "same project" option for the Epic creation but then I get a complain about it not being defined.

I would have preferred this generic option to deploy it as a global rule but I can handle it as local rule, not an issue.

[Bill Sheboy]

I just tested this scenario as a global-scope rule and it worked for me, with a specific project selected and "project from trigger" (which would automatically select the project for the version).

Let's try to narrow down some possible impacts...

• What is the project type of all projects involved: company-managed, team-managed, or both? 
  • Each team-managed project has its own configuration, such as issue types, and they are not compatible between projects.
• I notice what appears to be a different issue type than the built-in Epic.  Is that a custom issue type, and if so, in which projects does it exist? 
  • If it does not exist in the specific project that could explain this error.
• Which user is the rule actor? 
  • This can impact the permissions available to the rule.
  • The default is "Automation for Jira", which has enough permissions to do most things (except for JPD project types)
• Rules updated / published many times can get "glitched", where their underlying JSON is broken.  The ways to check for that cause are:
  • Disable the rule, wait a minute, re-enable it, and re-test
  • If that did not help, disable the rule, re-create it from scratch, and re-test

[Christophe H-M]

Hi Bill

I went to check every single point you listed and it triggered something in my brain... Here are the answer and the solution.

• company managed product (we mostly use this type of project here, at least wherever I'll need the rule)
• built-in Epic : here I'm not sure. I think we only changed the icon but I cannot confirm. However I'm sure the same issue type exist in all the targeted projects.
• rule actor: yes the automation for Jira agent has all rights
• rule which gets corrupted. I didn't need to try, see below.

After running all the verifications above I started to believe I was doing the right thing (since it works for you) but I must have forgotten a basic thing. So I created a new rule which is "manual trigger --> create an Epic". No smart value, nothing fancy. As simple as that. This simple rule failed as well. Then I realized (how dumb I am and) that in our template, we have couple of mandatory fields at creation time. Once I added all those fields to the rule and set proper values, my simple rule worked.

I did the same changes to the initial rule which is triggered from version creation and I got my Epic issue created, with the correct title and the correct fix version.

I'll now be able to complexify step by step the rule to get the most out of it (I already faced the next issue but I'll dig it out).

Thank you very much for your good support Bill. 

[Bill Sheboy]

Well done diagnosing that! 

That is a curious, and unhelpful error in the log for the required field.  When others have encountered that scenario a different error can appear for this in the audit log.  My hypothesis is this error depends upon the type of field which was required.

I checked the public backlog for any suggestions for this and did not find one, so consider adding one here: https://jira.atlassian.com/secure/Dashboard.jspa  I am currently on a free license and so can no longer add suggestions.

[Kalyan Sattaluri]

Hello @Christophe H-M 

Can you tell what is your requirement to create Epic. 

Should the newly created Version have "-.Release" in it?

[Christophe H-M]

Hello @Kalyan Sattaluri 

Thanks for your quick support

my requirement is when a version is created, if its name matches the pattern, then couple of EPICS must be created. The Epics should get the version name in their summary, plus some addition to give the topic of the Epic. The fixversion should also be set with the version name.

Yes as of today our process is to have "- Release" in it as we use the releases also for intermediate milestones (if Atlassian release the milestones in Advance Roadmap we may change our process but they didn't comment on the request lately). 

I think I found a working pattern with "ProductName.*Release".