feat(build): use ~= and >= package constraints

[nitrocode]

what

• Pin dependencies using ~= and >=
• Add schedules for atlantis-base and atlantis-image gha

why

• Allow builds to install the most recent dependencies
  • alpine's apk supports ~=
  • debian's apt only supports >=
• Prevent having to bump atlantis-base manually

options considered

package install options

1. status-quo: continue to hard pin all dependencies using =
   • pros: explicit dependency updates
   • cons: older packages, have to bump multiple when we only want to bump one due to stale packages
2. Use status-quo and pair it with renovatebot to bump dependencies
3. Use ~= pins in alpine and use = in debian
   • pros:
     • explicit dependency updates in debian and only patch updates in alpine
     • debian packages are not as stale as alpine so this is probably fine
   • cons: older packages in debian
4. Use ~= pins in alpine and use >= in debian
   • current pr
   • pros: latest packages
   • cons: could break tests but if tests break, we can pin down a version

atlantis-base options

1. status-quo: pin to a YYYY-MM-DD tag
   • pros: explicit bumping allows control over the base image
   • cons: have to update atlantis-base dependencies in one pr and use another pr to bump the atlantis image to use the new base
2. use latest
   • current pr
   • pros: no longer have to bump the atlantis-base tag
   • cons: less control over atlantis-base

checklist

• I have tested my changes by building the base image and non-base image locally

docker build -t atlantis-base:alpine - < docker-base/Dockerfile.alpine
docker build -t atlantis-base:debian - < docker-base/Dockerfile.debian
docker build --build-arg ATLANTIS_BASE_TAG_TYPE=alpine -t atlantis:alpine .
docker build --build-arg ATLANTIS_BASE_TAG_TYPE=debian -t atlantis:debian .

references

• Relates to Keep atlantis-base and atlantis docker image dependencies up to date #2890
• Closes Bump openssl version to fix CVE-2022-3996 #2954

[GenPage]

I'm not a fan of using the latest tag for atlantis-base. Could we do something in between, like stable so that instead of manual cutting date releases we have a balance between bump fatigue and efficiency?

I just worry about eroding stability by introducing drifts in packages that would make debugging/tracing errors more difficult.

[nitrocode]

If we introduced a new tag, how would stable be different from latest?

Currently latest tag is the latest stable release for both atlantis-base and atlantis images and dev tag is actually the latest tag version.

[chenrui333]

Actually I think it is a good idea, it should be put into the base flow and trigger this workflow upon success completion.

[GenPage]

@nitrocode Agreed, there is no different between the two, I guess the point I'm trying to make is re-using tags is not ideal for image caching especially if we want atlantis-base to be more automated. If we release a bad version of atlantis-base, rolling back is also no longer an option.

Might I suggest we switch atlantis-base to semvar and have the version bumping be tied in based on commit tags (feat, fix, chore?) I would be happy to hook this up.

[GenPage]

dependency pin changes LGTM, workflow discussion is out-of-scope for this PR

[nitrocode]

If we release a bad version of atlantis-base, rolling back is also no longer an option.

This is not exactly true because you can tag images with multiple names. If your current latest is bad, you can always go back to hard pinning to a YYYY-MM-DD tag.

[nitrocode]

Might I suggest we switch atlantis-base to semvar and have the version bumping be tied in based on commit tags (feat, fix, chore?) I would be happy to hook this up.

I think it might be better to merge the base and real images so we do not have to support 2 different images with 2 different workflows.

[nitrocode]

@GenPage thanks for the suggestion. Please feel free to propose new changes when you have time.

[chenrui333]

Might I suggest we switch atlantis-base to semvar and have the version bumping be tied in based on commit tags (feat, fix, chore?) I would be happy to hook this up.

using calver is intentional and i think it is better for our case.