Pipeline fails with 4x instance size and atlassian-ip-ranges: true, works with 1x size
Asked by Grant Starkman:

We're experiencing an unexpected issue with our Bitbucket Pipeline configuration. Our database migration step fails under specific conditions, and we're seeking insight or similar experiences from the community.

1. Configuration causing the issue:

yaml options: size: 4x runtime: cloud: atlassian-ip-ranges: true

2. Symptoms: - The pipeline fails during our database migration step when using the above configuration. - No specific error messages are logged; the step simply fails.

3. What works: - Using a 1x instance size with \`atlassian-ip-ranges: true\` - Using 4x instance size with \`atlassian-ip-ranges: false\` or the option removed entirely

4. What we've tried:

- Verified that the IPs used are whitelisted in our security groups.

- Tested with different pipeline configurations.


Answers:
author: Patrik S
body: Hi [@Grant Starkman](/t5/user/viewprofilepage/user-id/5589193) ,

Using the `atlassian-`ip`-ranges` configuration in 1x/2x should have no effect, as those sizes will continue to operate from the existing limited set of IPs until September 17, 2024.

After this date, ***all*** Pipelines builds will operate from the new, broader IP range as documented [here](https://support.atlassian.com/bitbucket-cloud/docs/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall/#:~:text=0248%20(deprecated)-,Valid%20IP%20addresses%20for%20Bitbucket%20Pipelines%20build%20environments,-The%20machines%20that) (this include `1/2x` steps).

To access the full list of IP's, you can use [this endpoint](https://ip-ranges.amazonaws.com/ip-ranges.json) and filter the results down to ones where `"service"` is `"`EC2`"` just the EC2 resources.

Steps using the new sizes **4x** /**8x** are already executed using the broader IP range by default. If you require your builds to continue running from the more limited set of IP's, you will need to leverage the `atlassian-`ip`-ranges` runtime configuration. The `atlassian-`ip`-ranges` configuration is only available to **4x/8x** steps as documented [here](https://support.atlassian.com/bitbucket-cloud/docs/step-options/#Runtime).

So it's interesting that you mentioned a size 1x step (before Sep 17th) is working, while a size 4x step with `atlassian-`ip`-ranges` is failing, since in theory they should both be running from the same limited set of Atlassian IP addresses.

With that in mind, I would suggest the following:

* Could you double check your firewall/proxy to confirm if all the IP blocks listed in [Pipelines - Atlassian-IP-ranges](https://support.atlassian.com/bitbucket-cloud/docs/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall/#Atlassian-IP-ranges) are allowed ?   
  If you confirm they are, I would suggest adding the following command at the very beginning of the failing step

  ```
  curl ifconfig.me
  ```

  so you can verify which public IP address was assigned to that step and compare if it's not in the Atlassian IP ranges list.
* Could you confirm if you're defining the `atlassian-`ip`-ranges` globally or at the step level ? Can you check if the syntax is correct according to the examples provided in the official documentation: [step](https://support.atlassian.com/bitbucket-cloud/docs/step-options/#Runtime) or [global](https://support.atlassian.com/bitbucket-cloud/docs/global-options/#Runtime)

I hope that helps! Should you have any questions, please let us know.

Thank you, [@Grant Starkman](/t5/user/viewprofilepage/user-id/5589193) !

Patrik S


author: Steve Annett
body: ?


Tags: bitbucket-cloud

cloud