gitlab-runner agent is very flexible, with multiple executors
to handle most situations. Similarly, AWS IAM allows one to use “instance
profiles” with EC2 instances, obviating the need for static, long-lived
credentials. In the situation where one is running
gitlab-runner on an EC2
instance, this presents us with a couple interesting challenges – and
GitLab makes a great deal of information available through Prometheus metrics.
But not everything.
At $work, I’ve been using KMS to encrypt s3 bucket contents for some time now. It works rather well, but one thing that had been bugging me is that our IAM policies granted both read permissions on bucket objects and encrypt/decrypt on the relevant KMS key. That is, principals with the policies attached can use the key to encrypt/decrypt anything they otherwise have permission to access, not just objects in the bucket.
git has always(?) allowed for additional configuration files to be unconditionally included:
1 2 [include] path = path/to/gitconfig Each individual git repo has always had the ability to maintain its own configuration at .git/config. However, sometimes on our systems we also have certain locations where we store multiple git projects, which may need different configuration from the global, but still common across that location.
Since … well, for the last year or two at least, git has allowed for the conditional inclusion of configuration files.
…um, kinda. I’m switching over from wordpress to Statocles, and porting my older posts over.
Still, who can resist “first post!” ;)
fzf is a fantastic utility, written by an author with a history of writing useful things. He’s also a vim user, and in addition to his other vim plugins he has created an “enhancement” plugin called fzf.vim.
One of the neat things fzf.vim does is make it easy to create new commands for fuzzy searches. If you’re like me, you probably have some absurd number of project repositories you keep around and jump to, as necessary.