Pedantically I think GLCI treats every environment the same, but by review environments I meant "disposable copies of the app such that one could interact with it during merge request review" e.g. https://mr-8675.example.com corresponding to /example/-/merge_request/8675 that would be provisioned when the MR was opened and torn down when the MR was merged or closed
I believe it aligns with this behavior in GitHub: <https://docs.github.com/en/actions/how-tos/deploy/configure-...> with the distinction that it appears from the GH docs that they think of that as "needs administrative approval" whereas GLCI thinks of it as "if the pipeline has permissions to run provisioning, off to the races, because names are free"
GitLab introduced the "deployment tier" I think as a means of communication to other users about the importance of the environment, but control over what credentials were made available to CI/CD was always controlled via <https://docs.gitlab.com/ci/environments/#limit-the-environme...> which partially explains why the only reason to involve a repository administrator would be to install or update a secret needed to deploy successfully
The C2 machine is fine, I use it regularly in a nearby studio besides other training and it's perfect for training. If the studio wouldn't be easily available I would buy a C2. And, by the way, my wife too started to be an avid rower after giving the machine a try.
I was rowing on real boats during my school and university days, but sadly never found the time afterwards to get join a club and row in teams.
Rowing machines with a water container are en vogue, but they are heavier (if filled with water) need regular water maintenance and the training effect isn't better.
I think you might be underselling the C2. I only ever row occasionally, but it is my understanding that it is the BIFL model. The type most gyms will buy - way more utilization hours than you will ever hit at home.
Also regardless of what others say, you can have a go trying to feel how it was to use BASIC in 8 bit computers to do everything their hardware exposed, or even 16 bit systems like MS-DOS, but with Python.
Get a ESP32 board, and have a go at it with MicroPython or CircuitPython,
I apologize this is not directly related to OP, but if you, like myself, get mad at all the "Suggested" posts LinkedIn is pushing on you, you can use the following ublock filter to get rid of these posts:
my problem with the wall isn't like with youtube where it's distracting and inviting to waste my time. it's more that most of the posts are so utterly dumb and self-aggrandising that it just makes me angry. thank god for ublock.
I worked for a medium size company that served, and still is, ~150 clients (some Fortune 500 included) by deploying prod with docker-compose. It can be done.
We use Fernet[1] or Ansible vault[2] with the encrypted secrets committed to the code repositories, but I guess we can do that because the code is not public.
The rest we share over a secure, company approved, channel, and save them into local KeePass-es (KeePassXC)
Also, anytime I put an ansible vault secret into Bitbucket, I get a yelly email back from BB about “detected secreted in repo!”
So general question, is this within security standards or is it very bad and should be using off-the-repo secret infra like Hashicorp vault etc? Downside there is have to manually update the secrets on Hashi vault side (eg they are not in code/repo) and you still have to have some visibility to the hashi key in any case in your CI/CD/code/ansible in any case right?
Commiting the passwords for decrypting Ansible vaults would render the encryption useless and you should consider all secrets already in the vault when committing and pushing the vault password compromised. Makes for a couple of fun days, if it happens.