Do you have an example screenshot somewhere? I'm wondering what exactly this does that GitLab doesn't, because inherited variables are shown within GitLab UI directly – fairly barebones, though, so I'm curious to see your UI in action. (I work at GitLab, but not on this – just a big CI fan myself.)
Unfortunately environment scopes are only available on premium so I can't demonstrate that, but it solves one of the major issues with the existing UI in that it doesn't give you an environment-centric variable view.
Also, it looks like it's only possible to view inherited variables when viewing the vars for a project. Group's don't show the inherited variables for their parents.
I also much prefer the project tree view to clicking around the gitlab UI so much, and when you're configuring a pipeline its quite tedious.
Thanks, sorry for the late response – busy week. Good point, wasn't even aware that the inherited variable view is only shown in projects but not subgroups. On a quick glance I couldn't find an existing feature proposal to add it at the subgroup level as well… but that might be because the search terms aren't terribly unique.
I'll show your demo to the team handling CI secrets, thanks again for sharing! :)
I'm a Support Engineer at GitLab, and based on my own experience that statement is definitely correct. There's entire classes of problems you simply don't have to deal with at all for SaaS customers.
I get into this argument inside my company, but as alternative point of view is that "hardening" the software for those 'I have seen some shit!' circumstances can be actually good for the overall health of the codebase and user experience. "It works on my machine" is all well and good until something goes off the rails (heh, so to speak), and if the software always assumes the happy path, debugging that is painful for an internal audience just as it is for external ones
Come to think of it, I would have though GitLab's fully-distributed workforce would make this true for you, too, since "I dunno what this error means, lemme just walk over to Jane's desk and ask" becomes expensive in that setup
No, I’m saying that when faced with the choice between comfort and difficulty, many people in the past chose difficulty. To insist that they would trade their religious beliefs, for example, for internet and Uber eats is rather myopic.
Mostly cases where businesses rely on individuals instead of process.
As a simple example, it's very easy, when starting a company, to issue personalized email addresses to early employees and then people communicate using those email addresses. It's perfectly fine to email the CTO at [email protected], because everyone knows everyone else and it works.
As you grow large, it becomes important for people to address roles rather than individuals. This way, if people leave their role, they can (semi-transparently) be replaced by someone else taking that role who will then continue to receive all of the same emails, be able to respond to them, etc. So then it becomes important to have e.g. a [email protected] address. When the CTO takes a vacation, their email gets routed to someone taking over their duties, you don't need to communicate to everyone to start emailing [email protected] instead.
This isn't how any of my workplaces have worked. When someone leaves, they or their boss sends an email announcing the role changes. Which companies practice the role@ method?
As JulianMorrison notes, this is common in finance. The FDIC strongly recommends that banks enforce this[1] – you can't cook the books when you have no access to the systems.
But sometimes it's not just about cooking the books: the last "SSL cert expiration" fire I lived through happened because the person who had credentials to Digicert had to take sick leave. It was never a documented/defined process because "just flip Tim an email" was always sufficient, Tim didn't mind doing the work, and Tim didn't like going on vacation.
Two week lockouts mean there's no chance of shadow IT/back channel work happening, and forces you to document your processes.
IIRC, over here, banks are required to give employees at least one two-week contiguous block of leave, during which they can't get into the office, use work systems, or log in remotely. The idea being that oh-so-clever scams generally require the operator to be there keeping all the balls in the air, and locking them out will reveal their tricks.
Thanks, if that works that would be amazing. I'm most often getting it inside in-app browsers, e.g. when opening a Twitter link in Tweetbot, Apollo or similar apps. Not sure if they share the same central settings/service workers.
I'm afraid that does not solve this particular problem, just happened again on the very first try. I still think this is intentional or at least happily accepted on part of Twitter, with the happy side effect to make it as shitty an experience as possible when you're not using their app.
In theory that is probably true – in my actual scenario I can't run them through ABBYY again because of the limitations of the bundled version. It only accepts PDFs coming from the scanner software, so running these through ABBYY again would give me an error message. I'd have to buy the full version to be able to try out that workaround.
On a totally not entirely unrelated note, I have found ExifTool[0] to be quite useful for many tasks. Especially in combination with a bash alias or simple Automator action, to be used in the services menu, or as a droplet or folder action.
[0]https://exiftool.org/TagNames/PDF.html
This is at least the second time that Apple breaks Preview in this way. I outlined why this bug is something a lot of users could run into, and I even mention that I'm not necessarily holding it against them that it breaks, but specifically that they don't even care to mention it breaking. After the first time, which was a big deal at the time, they should have put safeguards in place so that they could notice it happening. If the fault is with ABBYY, then I'm okay with Apple breaking it for the sake of internally improving Preview, and blame for the breakage lies with ABBYY. But I expect Apple to tell me – because it happened before. That blame lies with Apple.
That is my reasoning, and I don't think that's too high a bar for one of the richest companies on the planet, priding themselves in the details and "it just works". You don't have to agree with that, obviously. Calling me an ass for that is extremely rude and uncalled for, though. I was under the impression that this tone was actually not acceptable here.
> If you're not going to do the work to figure out what the corruption is …
I'm sorry, but last time I checked neither Apple nor ABBYY pay my salary. I really don't understand these takes. If Apple or ABBYY want my PDFs, they should be able to find my email address rather easily. Your tl;dr version of the post is completely unfair. I publicly criticize Apple because they are breaking something that potentially affects a lot of people who are unlikely to even know about it, and they are doing it for at least the second time now. If you don't think that's worthy of criticism, I don't know what is.
I also love how so many people assume I didn't already talk to support and file radars. I guess you had better luck in the past than me, but I can assure you, these options aren't always as useful as you might think they are.
Fair enough, though I'd still argue that a public write-up that might warn a few people and save them the trouble is well worth writing on its own. As this blog is just a hobby, my time for it is limited and it's not like a write-up like this doesn't already take up some time. I did provide plenty of resources in the links, to which I don't think sample PDFs from me would add much value. But point taken, I'll try to attach sample data where applicable in the future.
That's fair, and I honestly didn't enjoy posting the headline here, but as far as I know I have to use the original title? And the original title is from a personal blog where we talk about annoying things. We're not a professional tech blog, or a bug tracker, or… something other than our own little thing. I choose that headline not to be clickbait, but "sensationalist" is probably true because I'm personally really, really angry about this issue. I wanted to do my usual "scan all my documents for the month" routine 30 minutes before going to bed, and instead it turned into a two hour debugging session. And I can't even use my normal workflow now, possibly until March. I find it completely unacceptable that Apple would break Preview that way again. It's not even the first time. Just thinking about it now gets me going again. That's why the headline sounds like it sounds. I would have no problem at all if it was modified here, and as I said – your assessment is absolutely fair.
