Improve Linter prod docker release

[gpsaggese]

I have the impression that the linter depends on the code in the client... now that we have removed the horrible layer of pre-commit, we should be able to avoid any dependency of the Python code of the linter from the code inside the repo being linted.

1. The linter container (//helpers in this case) should be a prod release so that all the code inside the container is frozen, and we are "guaranteed" that there is no interaction with the code being linted. Is it already happening?

2. We want to get towards CI/CD as we release the linter continuously any time the tests are passing (like once a week or when we push the release GH action)

@sonniki , @heanhsok does it make sense? @Shayawnn this is also a step towards your proposal.

@heanhsok / @Shayawnn can we start putting a plan together? It shouldn't be too much work.

FYI @causify-ai/dev_system

[heanhsok]

1. The linter container (//helpers in this case) should be a prod release so that all the code inside the container is frozen, and we are "guaranteed" that there is no interaction with the code being linted. Is it already happening?

I think it's not using the code in the image ATM as it searches for the file on the host. One way to solve this is to use the absolute path of file in the container (i.e. /app/linters/base.py)

https://github.com/causify-ai/helpers/blob/876a16ada572547d7cb7d2983e0ee67df3236cc5/helpers/lib_tasks_lint.py#L268-L273

[sonniki]

I think it's not using the code in the image ATM as it searches for the file on the host. One way to solve this is to use the absolute path of file in the container (i.e. /app/linters/base.py)

This is also my understanding of the current situation.

We want to get towards CI/CD as we release the linter continuously any time the tests are passing (like once a week or when we push the release GH action)

I guess if we really have a simple way of releasing quickly and will do it very regularly, then it's fine, but I do appreciate the current situation where if we fix a bug in Linter, then all the users will immediately use the version without the bug... And therefore we don't have to make a new release for every annoying little thing, and we also don't have to wait until enough stuff is piled up for it to be "worth making a release".

[gpsaggese]

I agree that having 2 flows is useful, one that runs the linter from the code (like dev) and one with the code hardwired (like prod). We should just make it clear, documented and well supported.

Let's leave this issue open as a reminder.