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

[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.

[Patrik S]

Hi @Grant Starkman ,

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 (this include 1/2x steps).

To access the full list of IP’s, you can use this endpoint 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.

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 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 or global 

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

Thank you, @Grant Starkman !

Patrik S

[Steve Annett]

‎