Closed joeyAghion closed 10 months ago
I actually did a similar search, but wasn't sure about this one. Do you know why the gravity IAM profile needs access to the development configuration?
I actually did a similar search, but wasn't sure about this one. Do you know why the gravity IAM profile needs access to the development configuration?
Tracked down to https://github.com/artsy/infrastructure/pull/464. I think it may have been needed for a jenkins job.
Since k8s crons and Batch jobs get their config in other ways these days, I'm inclined to drop that Allow
block. Let me know if you think otherwise.
Back in https://github.com/artsy/README/pull/368, I proposed a convention for storing shared configuration for development environments in S3. That convention has been working, but I regret choosing the particular path (
artsy-citadel/dev/.env.<project>
) for a few reasons:aws s3 mv
operation. This misses an opportunity for the file to self-document how it should ultimately be named. It also creates confusion (when it's copied down with its original name, or when a.env.shared
is mistakenly copied up to S3).Instead, I think we should source shared config from paths like
artsy-citadel/<project>/.env.shared
. Projects that depend on multiple files have already started using that pattern, and moving the existing (<40) files should be easy, like:Then each project's setup script would need an update to pull from the new location (also easy, but tedious). Finally, the files under
dev/*
can be cleaned up to minimize confusion.I'll start this process, but wanted to solicit feedback since it's a slight change to our playbook.