did something changes with basepath detection? ```...
# atmos
p
did something changes with basepath detection?
Copy code
export ATMOS_CLI_CONFIG_PATH="./config" export ATMOS_BASE_PATH="./"
pepe.amengual@pepe ~/g/a/pepe-iac (feature/setup-docker-config-json-for-ghcr)> atmos helmfile sync actions-runner-controller -s mgmt-wus3

 Error 

 Error: directory for Atmos stacks does not exist

## Hints

 :bulb: Stacks directory not found:
 /Users/pepe.amengual/github/pepe-iac/config/stacks
pepe.amengual@pepe ~/g/a/pepe-iac (feature/setup-docker-config-json-for-ghcr) [1]> atmos --version

 █████  ████████ ███    ███  ██████  ███████ 
██   ██    ██    ████  ████ ██    ██ ██      
███████    ██    ██ ████ ██ ██    ██ ███████ 
██   ██    ██    ██  ██  ██ ██    ██      ██ 
██   ██    ██    ██      ██  ██████  ███████ 
                                             

:alien: Atmos 1.201.0 on darwin/arm64
m
I ran into a similar issue documented here
p
thanks
a
we are working on a fix, will be in the next release
@PePe Amengual did you switch to
1.201.0
?
(I see you did)
p
yes
e
Now would be a good time to chime in on
docs/prd/base-path-resolution-semantics.md
https://github.com/cloudposse/atmos/pull/1868/changes#diff-82ae6f66377fde5c3397fba8685430459321aa5ac8b48832674a4b21258f2b28
See "FR1: Base Path Resolution"
It might mean you may need to make changes, but the previous behavior is still fully supported just might not be the default.
The gist of it is that if
base_path
is not set the default (null or empty) behavior should be to use the repo-root
If no repo root, fall back to dirname(atmos.yaml)
If you explicitly want the current working directory, then setting
base_path: !cwd
will work
p
to me I need a reliable , backward compatible atmos version every time.
so if you guys change core functionality then I need a simple path of upgrade
I do not want to be down this road again of trying to figure out what changed, I think is atmos offer an upgrade command that check the user configs and offer resolutions that will be great , kinda like what tf did between 0.12 and 0.13
e
Yes pepe, we want that too. We are increasing test coverage and every time we have a regression we add test cases exactly for that issue. In this case, we inadvertently changed the behavior to be semantically correct: relative paths should be relative to the file that imports them. The behavior was never properly defined. We defined it in 1.202.0 formally, after the regression in 1.201.0. And added extensive tests for the behavior.
The underlying problem is there's about 3-4 years worth of code that had 20% test coverage. Another way of looking at that is the remaining 80% behavior was undefined. Over the past year we brought that up to 73% tested, 27% untested. It's that untested (undefined) behavior that is biting us. Unfortunately there's only way for us to know what breaks in the remaining 27% is to get bug reports and promptly fix them.
I know it's know it's no consolation, but hopefully by end of January we are at 80% and the through out 2026 continue to raise the bar.
The next release of atmos will support an atmos version switcher, making it as easy as setting an env to change the atmos version.
This will reduce some of the pain, but is an example of another small way we want to improve it.
Another thing that would help us out is if more people could share their configurations with us so we could create more test scenarios.
The larger our library of fixtures the more comprehensive we can make our tests.
—-
Most importantly, does 1.202.0 work for you or not?
If not, let’s jump on a call so you can show me and we can take a look.
p
I will test it out soon
and Thanks Erik and Team, you guys respond quickly than anybody else in the OSS that I work with
e
again, just really sorry about this - I hate things have been unstable for a few releases now. The light is at the end of the tunnel though!
Also, full transparency, 1.202 has also some regressions, so please hold off on upgrading.
👍🏽 1
more on that in #C07RMALBX7V