Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
Level
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

The deployment environment 'test' in your bitbucket-pipelines.yml file is invalid. Edited

Hello,

According to Bitbucket, my bitbucket-pipelines.yml file is invalid due to deployment environment 'test' being invalid. Screenshot below:

Screen Shot 2019-01-02 at 12.58.48 PM.png

I checked the validator and it said that my code is valid, so I'm confused as to what I am doing wrong.

My .yml file is as follows:

definitions:
steps:
- step: &step-test
name: "Test"
image: golang:1.11-stretch
deployment: test
script:
- export GOPATH="$HOME/go"
- export PATH="$PATH:$GOPATH/bin"
- go get -u golang.org/x/lint/golint
- go mod vendor
- golint -set_exit_status $(go list ./... | grep -v /vendor/)
# Uncomment these test steps when there are test file available
# - go test -short $(go list ./... | grep -v /vendor/)
# - go test -race -short $(go list ./... | grep -v /vendor/)
artifacts:
- vendor/**
- step: &step-build
name: "Build"
image: golang:1.11-stretch
deployment: test
script:
- go build
- step: &step-deploy
# set GCLOUD_PROJECT environment variable to your project ID
# set GCLOUD_API_KEYFILE environment variable to keyfile as described here (but we aren't base64-encoding the file): https://confluence.atlassian.com/x/dm2xNQ
name: Deploy to GCloud
deployment: production
image: google/cloud-sdk:latest
script:
# Set up credentials
- echo $GCLOUD_API_KEYFILE > ./gcloud-api-key.json
- gcloud auth activate-service-account --key-file gcloud-api-key.json
# Deploy app (and cron if it exists).
- gcloud config set project $GCLOUD_PROJECT
- gcloud --quiet --project $GCLOUD_PROJECT app deploy app.yaml
- if [ -f cron.yaml ]; then gcloud --quiet --project $GCLOUD_PROJECT app deploy cron.yaml; fi

pipelines:
default:
- step: *step-test
- step: *step-build
branches:
master:
- step: *step-test
- step: *step-build
- step: *step-deploy

Any help would be greatly appreciated, thank you! 

 

EDIT: I found out that it is my "step-build" that is failing.

EDIT 2: I was able to have it run by combining both my step-test and step-build stages to one step. Are we not allowed to have multiple steps with the same deployment value?

8 answers

1 accepted

8 votes
Answer accepted

According to the documentation:

Currently Bitbucket Deployments supports deploying to teststaging, and production type environments and whichever you use they must be listed in this order in each pipeline.

This isn't very well phrased, but what it means is that only one step can deploy to any given environment, and that the steps must refer to those environments in that order.

Alright but what if I have more than one step and that I want to use the environment variables for each step?

Like # people like this

Running into same issue, currently using staging to upload projects to S3. We then wanted a development deployment (I was trying to just re-use staging) and a production environment.

Obviously a development deployment doesn't exist as well as the staging deployment, had to rewrite pipelines to fit to using staging and production in that order. I considered using test too but my workflow would have ended up being staging, test, production which also broke pipelines.

Bottom line, you can only use 1 of each and they have to be in that order, I totally don't agree with this. We should be able to add our own deployments and control the order they can be placed rather than being forced to use test, staging & production.

Like # people like this

I just ran into this as well, trying to use the deployment variables for the next step that effects that deploy environment without making the variables global to the repository...

Like Jason Harrison likes this

So, at least update your bitbucket validator. I validate my file but the pipeline fails. Hasn't sense. 

Like # people like this

any update on using deployment variables in various consecutive steps?

The one Bitbucket deployment variable I could find that should work in various consecutive steps is `BITBUCKET_DEPLOYMENT_ENVIRONMENT` (and `BITBUCKET_DEPLOYMENT_ENVIRONMENT_UUID`).

No idea why these deployment variables should not be able to use on consecutive deployment steps.

Please share the name of the variables which are missing.

@T_ Klingenberg Not talking about the bitbucket provided variables those are injected on every step, we're speaking of variables associated to "Deployments" that are defined by users.

Right now you can create variables for specific deployments, this helps reduce code duplication since you can redefine what the variable is per deployment. However, this breaks down completely and all efficiencies are lost if you need to run another step after a deployment since those deployment defined variables are now gone.

It would be nice to have the ability to do something similar to parallel steps where we could define multiple steps within a deployment phase preserving all the user defined variables for that deployment, or like mentioned above, allow for tagging multiple steps as a deployment type so we can reuse those variables in all associated steps.

Like Matt Hill likes this

@Michael Russell Ah, now I understand the problem. You perhaps could persist state between steps in artifacts, this should work if you need multiple steps (e.g. you need different containers for deployments).

Like Jason Harrison likes this

Yeah, thought about saving to .env files but we usually have protected vars as well so would rather keep that exposure very limited, especially considering they would now be stored in a downloadable file.

Hoping that the Bitbucket devs can workout a flow for this, it would reduce a lot of redundancies on my end :)

@Michael Russell You can always encrypt that with an encryption key for all pipelines if you need this on the same level as "secure" variables. There should be also existing utilities for that, unfortunately I don't have a link at hand.

IMHO it kind of makes sense to only have one step for a deployment. Not suggesting this is it but there is also some value in my eyes to not have the deployment triggering too complicated. Perhaps use a deployment image of your own that ships with all needed utilities for your deployment steps.

I completely agree with:

there is also some value in my eyes to not have the deployment triggering too complicated

Which is why I'd like to see an option of either allowing multiple steps be associated to the same deployment (shares the env vars and the locked down user triggers, which we use in our pro plan) or away to nest steps under a deployment umbrella that has the same effect.

All the solutions at present time can over complicate this. Instead of having to reduce to more complicated methods such as setting up a key vault to encrypt env vars/values to artifacts and then decrypt them upon next steps or building out custom images for everything and embedding all your API keys/tokens/passwords; I see value in multi-step deployments along with single step deployments that are very simple.

I'd rather not make one super complicated step that does it all, but, prefer to allow for multiple, repeatable, testable steps that can build upon each other and be moved around, along with making the yml very human readable and predictable.

Perhaps use a deployment image of your own that ships with all needed utilities for your deployment steps.

We've built out lots of custom images that we use for deployments and we've built out Pipes that run tests for each action on each update we make to them, with proper release cycles; However, even with all this we still can't lock down env variables to specific deployments since lots of these deployments happen across multiple steps for most of our projects. The key for Pipes/custom images to be flexible/secure/testable is to not embed API keys/tokens/etc within those images but allow those images to rely on passing those items into them at execution, which, brings me back to how it'd be nice to have a way to associate multiple steps for deployments along with the simple one step deployment :)

I have not yet finished the pipes feature in my local pipelines runner, otherwise it should be possible to run a single step that runs other pipelines. As the environment is shared across all these (IIRC), this should then work. Brings me to the idea to create a pipe for running pipelines.

Yes, it is, however that does not solve for when two steps are needed to complete the deployment process. Thanks for you dedication to this, but, from my end all that's needed is a simple way to have multistep deployment options.

Faced that too doing db migration after app engine deploy via pipe :(

I find it a bit weird that I cannot repeat the `deployment` variable in my step.

I had the following definitions:

- step: &build
  name: build
  caches: - node
  script:
    -
npm ci
    -
npm run aws:config
    -
npm run build
    -
npm run export

- step: &deploy
  name: deploy 
  caches: - node
  script:
    - npm run deploy



and then in my pipeline I had:

branches:
  master:
    - step:
        <<: *build
         deployment: development
         name: Build for development

    - step:
        <<: *deploy
         deployment: development
         name: Deploy to development





This would trigger the error in :

The deployment environment 'development' in your bitbucket-pipelines.yml file occurs multiple times in the pipeline. Please refer to our documentation for valid environments and their ordering.

But I need the environment in my Build step to access the AWS services for the aws:config, And I need the deployment in my deploy step so that the AWS CDK knows where to deploy too (secret and access keys set in bitbucket deployment environment variables).

 

So I find this a bit weird, I now have to create a build and a build-deploy step which is kinda defeating creating separate definitions.

Any news on this Atlassian? I need to run 4 differents steps in same deployment, and they are all using different images, but I need the variable that I set on this specific environment.

If you set variables, these are only specific to the one script you set them for. I don't understand what to expect otherwise on the Atlassian Bitbucket Cloud Pipelines Plugin honestly. To which reference do you refer here?

Like dscheglov likes this

@T_ Klingenberg , I think @Igor Ludgero Miura refers to deployment variables. Currently you can call deployment vars only from one step, as only one step is allowed to access a deployment in each pipeline.

Like # people like this

@Igor Ludgero Miura Sure, I was not aware of these specific deployment variables. This should be available, at least this could be seen as very unexpected to have them *not* in further steps if the deployment pipeline allows to have multiple steps so to say. I hope Atlassian support is able to give this some traction. This is perhaps an easy, quick and safe improvement.

Like # people like this

Please work on this. Having to duplicate the same functions for deployments defeats the purpose of using anchors in the yaml file.

Hello Friend. Its funny we all try to do something that is naturally obvious, yet its not according to Atlassian.

I'm in the same boat here. I need to be able to use 2 different image types across 3 steps for each of test, staging, and production. I can either make my own image, or always install the AWS cli on every deployment, neither of which is ideal.

This seems so arbitrary.

This was not meant as an answer, but as a reply to the above. Go Atlassian UIs!

Your own documentation has me doing steps in this way: https://confluence.atlassian.com/bitbucket/deploy-to-amazon-aws-875304040.html

Your instructions for deployments contradict those instructions.

Like # people like this

I'm facing the same issue.  My requirement is as following.
For Production environment deployment, I've bifurcated pipeline into 2 step: First step check and show files to be deployed and then second step actually deploys those files. This is separated into two because I''ve set set step to manuall. So, after confirmation of files-to-be-deployed, I run second step manually.
But this pipeline limitation is now allowing me to do so as deployment command couldn't be repeated as per their error.
So, any update regarding this bitbucket pipeline limitation? Or anyone can help me out to do same with some other way?

i am also facing same issue 

2 votes

This can only be a joke, especially because the validator still insists that the yml is valid.

Yes I have just run into the same situation @Julian Rabe, failures in the pipeline but all looks good to the validator. 

I have same issue here, any update regarding that Atlassian?

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Bitbucket

Calling any interview participants for Bitbucket Data Center

Hi everyone,  We are looking to learn more about development teams’ workflows and pain points, especially around DevOps, integrations, administration, scale, security, and the related challeng...

485 views 5 4
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you