Open anhixon opened 6 years ago
Hi,
I'm having troubles to reproduce this. Could you please provide me a minimal example of a DSL where this happens? Also, have you tried updating to the latest plug-in version 1.9.5 to see if this still occurs?
Thanks, Michael
Hi Michael,
Still occurs on 1.9.5
The following code is the build and deployment steps for the plan in question.
` addBuildStage plan, repoName
// add deployment
plan.deploymentProject(name: "Deploy ESB ${repoName}") {
CorePermissions.addDeploymentProjectPermissions delegate
releaseVersioning('${bamboo.buildResultKey}-release-1') {
autoIncrement()
}
def deploymentProject = delegate
Config.Plans.Mule.ENVS.nonProd.each { addEnvironment deploymentProject, repoName, planKey, it, false }
Config.Plans.Mule.ENVS.prod.each { addEnvironment deploymentProject, repoName, planKey, it, true }
}
}
/**
* Configure the build stage for the repo
*/
private static addBuildStage(Plan plan, String repoName) {
plan.stage(name: 'Build Stage') {
manual false
job(key: 'BUILDJOB', name: 'Default Job') {
tasks {
checkout {
description 'Checkout Default Repository'
repository("${Config.ESB_KEY}/${repoName}") {}
}
Maven3xTask.setVersion delegate, '1.0.${bamboo.buildNumber}'
maven3x('clean deploy') {
description 'Build, test and push Mule App to Artifact Repo'
Maven3xTask.configureTask delegate
withTests {
testResultsDirectory '**/target/surefire-reports/*.xml'
}
}
}
artifacts {
definition(name: "${repoName} Zip", copyPattern: '**/*.zip') {
location 'target'
shared true
}
}
}
}
}
/**
* Configures the stage to trigger a deployment for the given environment
*/
private static addDeployTasks(Environment environment, String repoName, Map env, String planKey) {
environment.tasks {
cleanWorkingDirectory() {
description 'Clean the working directory'
}
checkout{
description "Download the wrapper"
repository("${Config.ESB_KEY}/icare-cli-wrapper") {}
}
npm(executable: 'Node.js', command: 'install'){
description 'install required packages for the wrapper'
}
artifactDownload() {
description 'Download release content'
artifact(name: "${repoName} Zip") {
sourcePlanKey "${Config.ESB_KEY}-${planKey}"
}
}
checkout{
description 'Download the application configurations'
repository("${Config.ESB_KEY}/cicd-config") {}
}
nodeJs(executable: 'Node.js', script: 'app.js') {
description 'execute Node; deploy via the cli wrapper'
enabled false
workingSubDirectory 'src'
arguments "-t application -u \${bamboo.cliUsername} -p \${bamboo.cliPassword} -o icare -e ${env.platformName} -n \${bamboo.shortPlanName}-1.0.\${bamboo.buildNumber}.zip -a \${bamboo.build.working.directory}/mule-hello-world-1.0.\${bamboo.buildNumber}.zip -m \${bamboo.build.working.directory}/configs/meta.json -c \${bamboo.build.working.directory}/configs/mule-app.properties"
}
command() {
description "Deploy ${repoName} to ${env.name} - to be removed once MuleSoft fix reading properties files"
enabled true
argument "--username=\${bamboo.cliUsername} --password=\${bamboo.cliPassword} --environment=${env.platformName} --organization=icare runtime-mgr cloudhub-application modify icare-${env.shortName}-\${bamboo.shortPlanName} \${bamboo.shortPlanName}-1.0.\${bamboo.buildNumber}.zip"
executable 'Anypoint'
}
}
}
/**
* Configures a new environment in the deployment plan
*/
private static addEnvironment(DeploymentProject deploymentProject, String repoName, String planKey, Map env, boolean isProd) {
deploymentProject.environment(name: env.name) {
CorePermissions.addDeploymentEnvironmentPermissions delegate, env
addDeployTasks delegate, repoName, env, planKey
}
}`
thanks, Anthony
Hi Michael,
just wondering if this is still a valid issue on your end and if there has been any progress on this?
Thanks, Anthony
Hi Anthony,
Please excuse my late reply. I'm having troubles to reproduce this because the provided DSL contains a lot of custom logic I cannot deal with. Would it be possible for you to provide me some kind of minimal example including the project, plan and deployment project? That would help me much.
Thanks, Michael
Saw this issue first on 13/9/17 Occurred without pause until work around discovered for 2 days whenever a the seed task was triggered
Steps to reproduce: 1) Submit a plan dsl task with linked deployment phases 2) Execute seed task 3) update seed task 4) run seed task 5) Build should fail
Note: if not update provided build will not fail
Work around: Remove deployment projects (all effected - usually will be every project; can only confirm this by removing one at a time and running again) and execute seed task. I did think this was a bamboo defect at first - please see https://getsupport.atlassian.com/servicedesk/customer/portal/10/BSP-34817
Running Bamboo 6.1.0 and Plan DSL 1.9.1
bamboo_task_fail.txt