Is it possible to get all the releases to newly created project from shared configuration project?

[pradeep jeevan]

want to create a new project-B using the shared configuration from project-A. Is it possible to get a releases from Project-A to Project-B using the automation?

[Darryl Lee · Accepted solution]

Hi @pradeep jeevan - correct me if I'm wrong, but you're wanting to create a new Project B based on the configuration of Project A, and specifically you'd like to copy Versions.

So using Automation for Jira, you can access those versions as a Smart Value list:

{{project.versions}}

In addition, there is an Action to Create version that accepts Smart Values:

https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Create-version

So the trick would be iterating through all the Versions from Project A and then creating each one in Project B.

So, assuming you'd want to run this script after creating a new project, you'd use a manual trigger to kick off the automation. And I believe it would be scoped to the current project.

And that would be a problem: 

• If you trigger it from Project A, you could get the list of versions, but there'd be no way to create versions in Project B
• If you triggger it from Project B, there would be no way to get the list of versions from Project A.

Does that seem right to you, @Bill Sheboy ?

In which case, @Stefan Salzl is right: You'd need to use the API to write an external script to read versions from Project A and create them in Project B.

[Darryl Lee]

Now if the set of Versions is relatively static, then you *could* simply hard-code the versions into an automation that you trigger after creating a new project. 

Oh, and I forgot, there is a trigger for Project Created.

But yeah, same thing applies, I don't think you'd be able to get the list of Versions from Project A.

[Darryl Lee]

Oh, I figured out how to read the list of Versions from Project A (Branch rule / related issues - JQL), but unfortunately there's no way to nest an Advanced Branch within that.

But because 1) branches execute in parallel and/or 2) smart value variables are not global, I cannot then iterate over {{allversions}} to create the versions:

I tried to avoid the whole problem of not being able to have a list object by using split, but nope:

{{allversions.split("---")}}

[pradeep jeevan]

Hi @Darryl Lee 

Thanks for the info.

I am new to automation rules. shall I get the list of the smart values available in automation? 

correct me if I'm wrong, but you're wanting to create a new Project B based on the configuration of Project A, and specifically you'd like to copy Versions - Yes, I want to create a multiple projects, like 100+  based on the shared configuration from  the project-A and want to copy all the versions available in project -A to project - B.

Regards

Pradeep

[Bill Sheboy]

Hello, everyone!

I saw that @Darryl Lee pinged me, so I am jumping in with a couple of ideas, merging ideas already posted by Darryl and Stefan:

@pradeep jeevan -- If you need to do this often, I recommend investigating the Atlassian marketplace for addons to help with cross-project version management.  Unless you already have a Cloud Premium license, doing this manually can be challenging.

That being noted...If you still want to try this with an automation rule, perhaps try a project created trigger and calling the REST API (as Stefan notes) to get all the versions for a project, then re-create them in the new project.  Some challenges with this approach:

• This will probably need to be a global/multi-project scope rule, and so rule execution limits could be a problem unless you are already on the Premium license level
• If you need all of the versions added in the same order as the original project, that is not possible in an automation rule.  As soon as the branch executes, it processes in parallel and asynchronously...with no guarantee of ordering or completion timeframe.

Kind regards,
Bill

[Darryl Lee]

Oooooh, I totally forgot you could get the versions via REST API. Clever. But can you process those as a list value, @Bill Sheboy

I feel like this was a question/answer we've gotten in the past. Something about the ability to treat Web Request responses as objects...

Or did you end up having to split it?

[Bill Sheboy]

I remember trying this quite a while ago, but I cannot find my example rule...

This is the relevant REST API function, and the versions' name list could be extracted from the response to iterate on a branch on smart values to add them.  Perhaps add smart value, list filtering if all of them are not needed.

https://docs.atlassian.com/software/jira/docs/api/REST/1000.824.0/#api/2/project-getProjectVersions

[Darryl Lee]

Ah, fun stuff!

So @pradeep jeevan you'll need to make "Send web request" to your own Jira instance using an API Token. This is very well-documented here.

Here's what mine looks like:

You should use the "Validate your web request configuraton" tool to make sure that's all working.

Once that's set, you can use Advanced branching to iterate through all of the versions returned. And yes, as @Bill Sheboy points out, they might be created out of order. The first time I tested this they were in order, the second time, out of order.

For my own reference, this question about Accessing a JsonArray syntax? was the one I was thinking about whether we needed to split JSON list arrays from web responses.

We don't but it get me to thinking about an ugly solution to the ordering problem would be to have a bunch of sequential Create version actions (not in a branch), creating a bunch each version in order. So then a bunch of these:

Create version

Version name: {{webhookResponse.body.name.get(0)}}
Start date: {{#if(exists(webhookResponse.body.startDate.get(0)))}}{{webhookResponse.body.startDate.get(0)}}{{/}}
Release date: {{#if(exists(webhookResponse.body.releaseDate.get(0)))}}{{webhookResponse.body.releaseDate.get(0)}}{{/}}
Description: {{#if(exists(webhookResponse.body.description.get(0)))}}{{webhookResponse.body.description.get(0)}}{{/}}

Create version

Version name: {{webhookResponse.body.name.get(1)}}
Start date: {{#if(exists(webhookResponse.body.startDate.get(1)))}}{{webhookResponse.body.startDate.get(1)}}{{/}}
Release date: {{#if(exists(webhookResponse.body.releaseDate.get(1)))}}{{webhookResponse.body.releaseDate.get(1)}}{{/}}
Description: {{#if(exists(webhookResponse.body.description.get(1)))}}{{webhookResponse.body.description.get(1)}}{{/}}

...

Which is, of course, a horrible idea. :-} 

(Bill, I was thinking of something like a FOR loop counting up from 0 to .size, but alas, there's no such thing.)

Anywho though, if order isn't a big deal, this should do the trick. :-}

[pradeep jeevan]

Thank you @Darryl Lee , @Bill Sheboy 

I will try what I understand here and if anything is required I will reach out to you.

Thanks for the valuable suggestions and answers.

Thanks

Pradeep

[Stefan Salzl · Accepted solution]

Hi @pradeep jeevan ,

mainly the configuration only relies on how your project is set up and how things in the project behave (issues, workflows, etc).

The versions are entities within a project and refer to this specific project. So a version from project a cannot natively be chosen as fixedVersion in an issue of project B.

One way that comes to my mind would be to work with the Jira API. It‘s capable of getting all versions of a project as well as creating new versions in a project. Guess it could work this way.

Please let me know if this was helpful or if there are further questions.

Best
Stefan

[pradeep jeevan]

Hi @Stefan Salzl 

Much appreciated for the info.

Thanks

Pradeep