We are using some own plugins. On atlas-create-jira-plugin , the procedure is described how we are kick-starting these plugins and this is also how our CI/CD build pipelines are setup.
Since some scripts are ignoring parameters, our CI/CD Pipelines are currently broken and we are back to manual compile; which has a significant impact to our productivity.
This should take the parameters provided and run non-interactively.
Instead, it asks for that Parameters again:
...
Feb 23, 2021 3:48:45 PM java.util.prefs.FileSystemPreferences$1 run
INFO: Created user preferences directory.
[INFO] Google Analytics Tracking is enabled to collect AMPS usage statistics.
[INFO] Although no personal information is sent, you may disable tracking by adding <allowGoogleTracking>false</allowGoogleTracking> to the amps plugin configuration in your pom.xml
[INFO] Sending event to Google Analytics: AMPS:jira - SDK First Run - 8.1.0
[INFO] using stable product version: 7.13.0
[INFO] using stable data version: 7.13.0
Define value for groupId:
And stops.
This is the same with all the atlas-create-[APP]-plugin scripts.
My team maintains the SDK. I’m just trying to understand your use case. Normally the atlas-create-jira-plugin script (and its equivalents for the other Atlassian on-premise products) is used interactively as a one-off step when a developer is starting a new plugin project. However it seems like you’re running it from an automated pipeline. Can I ask why you would be doing that?
I had a look at the command and at the very least it doesn’t seem to have changed recently - could you clarify if the command you specified was working in a previous version and stopped working in a more recent version?
What I found is that --non-interactive seems to work if you specify all options (including --package com.henkel.jira) and it doesn’t work otherwise.
So in your case, you could run: atlas-create-jira-plugin --group-id com.henkel.jira --artifact-id remote-user-auth --version 1.0.2 --package com.henkel.jira --non-interactive
This is to check for any updates to versions in the pom.xml file; like for amps.version or atlassian.spring.scanner.version. We found doing this after an atlas-update to be the easiest way to “stay up2date”.
Wow, interesting. So after the SDK generates the new plugin project, what happens next? How do you see what’s changed since the previous run?
FWIW, Atlassian has recently started rolling out Renovate to many of its projects, to keep all the dependencies up to date. I don’t know if this might be another approach you could try, with the benefit of not having to write or maintain your own tooling?