You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
Next: Root
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
As part of running the pipe below
- pipe: atlassian/aws-lambda-deploy:0.5.7
variables:
AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID}
AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY}
AWS_DEFAULT_REGION: 'eu-west-2'
FUNCTION_NAME: 'MyFunction'
COMMAND: 'update'
ZIP_FILE: 'code.zip'
The script update-lambda.sh writes to /opt/atlassian/pipelines/agent/build/.bitbucket/pipelines/generated/pipeline/pipes/aws-lambda-deploy-env. That file is then read by pipe.sh in a subsequent pipe when you run with the alias command. e.g.
COMMAND: 'alias'
However if I have another pipe in my bitbucket-pipelines.yml file before the aws-lambda-deploy pipe. e.g.
sonarsource/sonarcloud-scan:1.2.1
then update-lamda.sh cannot write the aws-lambda-deploy-env file as it gets a permission denied error.
Shouldn't the aws-lambda-deploy-env file be created in /opt/atlassian/pipelines/agent/build/.bitbucket/pipelines/generated/pipeline/pipes/atlassian/aws-lambda-deploy ?
And why does the creation of the /opt/atlassian/pipelines/agent/build/.bitbucket/pipelines/generated/pipeline/pipes/ by another pipe stop it being available for the subsequent pipe?
The solution was to delete the shared directory before running the aws-lambda-deploy pipe.
... previous steps call the sonarsource/sonarcloud-scan pipe ...
- step:
name: 'Deploy Lambda to AWS'
script:
# Writing the $BITBUCKET_PIPE_SHARED_STORAGE_DIR/aws-lambda-deploy-env file causes a permissions denied failure, so we first delete the directory
- rm -rf /opt/atlassian/pipelines/agent/build/.bitbucket/pipelines/generated/pipeline/pipes
- pipe: atlassian/aws-lambda-deploy:0.5.7
variables:
AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID}
AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY}
AWS_DEFAULT_REGION: 'eu-west-2'
FUNCTION_NAME: 'MyFunction'
COMMAND: 'update'
ZIP_FILE: 'code.zip'
Still don't know why running the sonar pipe first prevents the aws pipe from writing to the shared storage location
It worked fine for me!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Just had this issue come up myself specifically with sonarcloud-scan where we have multiple pipes deploying to different environments.
The first deployment is fine but the second fails as it cannot write to
/opt/atlassian/pipelines/agent/build/.bitbucket/pipelines/generated/pipeline/pipes/sonarsource/sonarcloud-scan/sonarcloud-scan.log: Permission denied
This solution was as above.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.