Pipeline workspace variables slow to update?

[Bruce Kibbey]

I ran into an issue last night (and this morning) where I changed some workspace variables and then run the pipeline manually and it seems that it is not able to read the updated values for some time.

Is this documented somewhere?  It really feels like if I just wait several minutes that the variables are suddenly able to be read.  

[Theodora Boudale]

Hi @Bruce Kibbey and welcome to the community.

- Are you updating the workspace variables values from the UI? Or via an API call?

- Is this issue consistently reproducible? If so, I would like to ask if you can create a screen recording, that shows the process of you changing the variable value, then triggering the pipeline manually and then where you see the old value when the build finishes.

Then, open a ticket with Bitbucket Cloud support team (or I can open it for you, please feel free to let me know) and attach the screen recording, so the support team can further investigate. The support ticket will be visible only to you and Atlassian staff, so I think it's best to upload the screen recording there, instead of here publicly, for privacy reasons.

If there is a support ticket open, the engineer working on your case will also be able to access the repo and extra logs from our side if needed, to further investigate.

I can't find any other reports regarding variables needing time to update, I have also been unable to reproduce this issue in a repo of mine, so I believe this can be better investigated in a support ticket.

You can open a ticket via https://support.atlassian.com/contact/#/, in "What can we help you with?" select "Technical issues and bugs" and then Bitbucket Cloud product, or please let me know if you'd like me to open the ticket for you.

Kind regards,
Theodora

[Bruce Kibbey]

Thank you for your reply Theodora - I figured out what was going on here, odd situation but I'll write it up here in case others run into something similar.

My Situation was... I have a BitBucket Workspace with the following.

- Backend Repository, with Pipelines enabled, most functions in a bash shell script.

- Frontend Repository, with Pipelines enabled, most functions in a bash shell script.

- Workspace Variables for my ssh keys for Test/ Stage/ Prod - I have to maintain different keys to each environment.

I was updating the variables in the Bitbucket UI - Both of the pipelines are using the same variables.  I had gotten the Backend pipeline to work fine / repeatedly for all 3 environments but was struggling with the Frontend pipeline where my shell script went to use the ssh key for scp/ssh.

Issue: the frontend pipeline server could connect to my test environment, but not stage or prod.  My host was rejecting the connection due to bad private key.  I had double/triple checked the key and wracked my brain trying to figure out why.

Attempts to diagnose: I forced the pipeline to write the id_rsa file to the pipeline server and then had my shell script echo it (exposing the private key until I could get it to work and replace it)...  before connection.  

The key was CORRECT.  But it wasn't working.  Why?

More diagnosis:  I started to change the stored variables with purposely bad values just to see if things were updating right... then running pipeline again and finding the id_rsa file was populating with the key still.

This lead to my post... it was very confusing.

I later learned - through much trail and error that there were 2 contributing factors in MY CONFIG that lead to these issues.

1 - I had an ssh key stored in the ssh values of the repository that was getting used in the pipeline... so i cleared that.  My mistake that caused me a lot of confusion.

2 - The pipeline image I was using   (image: node:10.15.0)  was not using .ssh/id_rsa in a regular ssh call.  It was IGNORING IT.  So I had to add -i .ssh/id_rsa to my ssh call and boom, everything started working again.  

Result - lots of learnings about pipelines/ images/ ssh/ bitbucket variables.  A painful reminder not to assume things like ssh automatically reading .ssh/id_rsa is always true.