# flag Published articles for flag. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## CAA DNS Issuer-Critical Flags Are Confusing to Configure DevFeed: [CAA DNS Issuer-Critical Flags Are Confusing to Configure]() Original publisher: [Read original article]() Author: Remy Porter Published: 2026-09-10T06:30:00Z Content type: opinion Language: en Sources: [The Daily WTF]() Topics: [certificates](), [domain]() Tags: [bits](), [boolean](), [certificates](), [documentation](), [feature-articles](), [flag](), [https](), [readability]() ### AI overview The article examines confusion around the issuer-critical flag in DNS CAA records. It explains that the flag is defined as a bitmask, while many users interpret the documentation as requiring the integer 1 instead of the value representing the specified bit, creating a dilemma for certificate issuers such as LetsEncrypt. ### Source excerpt I'm not a DNS person, in that I appreciate that it exists but am not up on the inner workings. It solves a lot of problems with dark magic I don't fully understand, and fortunately don't need to. But Lucio noticed something that I do think is interesting, within the scope of the CAA record type. The CAA record started with RFC6844, which was obsoleted by RFC8659. Both RFCs lay out the same core idea: you can add a CAA record to your DNS entries to say, "hey, this domain over here is allowed to issue certificates for me". That's the sort of thing that enables LetsEncrypt to hand out certs, and is an important part of why we can run HTTPS everywhere these days. Now, RFC6844 has this in it: Issuer Critical: If set to '1', indicates that the corresponding property tag MUST be understood if the semantics of the CAA record are to be correctly interpreted by an issuer. Issuers MUST NOT issue certificates for a domain if the relevant CAA Resource Record set contains unknown property tags that have the Critical bit set. The issuer critical flag means that the certificate issuer needs to validate your CAA record before it issues a certificate for you. There's more in the RFC about what exactly that means, but we don't care about those details for right now. The rule here is "set a flag to 1". A little later in the RFC, the flag is described in more detail- as a bitmask. Specifically, bit 0 is the issuer critical flag. Bits 1-7 are reserved for future use. Now, here's where we get into trouble, because programmers don't understand bits, and because the CAA record expects you to put an integer in this field. So, if you want issuer critical enabled, what value to you put in this field? 128, obviously. That's 10000000. Except, if you don't understand bits, that's not obvious. A lot of people read this and decided that the documentation meant they needed to put 1 in the field- aka 00000001. This is wrong. The updated RFC tries to explain it a bit more clearly: Bit 0, Issuer Critic ## 【kube-apiserver】运维与升级：HA、flags、graceful shutdown 与 etcd 联检 DevFeed: [【kube-apiserver】运维与升级：HA、flags、graceful shutdown 与 etcd 联检]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-28T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [Kubernetes](), [Encryption]() Tags: [api](), [apiserver](), [audit](), [backend](), [config](), [distributed](), [encryption](), [etcd](), [flag](), [graceful-shutdown](), [ha](), [kubernetes](), [leader-election](), [load-balancer](), [operations](), [retry](), [servers](), [upgrade](), [v1-30-3]() ### AI overview This Chinese-language operations tutorial explains kube-apiserver high availability and upgrades for Kubernetes v1.30.3. It clarifies that multiple apiserver instances run concurrently without internal leader election, sharing an etcd cluster, and covers key flags, graceful shutdown, encryption configuration, audit webhooks, upgrade checks, and version-skew guidance. ### Source excerpt kube-apiserver 高可用模式：多实例共享 etcd、无需内部 leader election；核心 flag 语义（--etcd-servers、--etcd-servers-overrides、--shutdown-delay-duration、encryption-provider-config）；与 etcd/14 的联合升级检查单；Kubernetes 版本偏差策略与 etcd 矩阵指针。 ## Rerun Only the Jobs That Failed DevFeed: [Rerun Only the Jobs That Failed]() Original publisher: [Read original article]() Author: Pete Miloravac Published: 2026-08-12T10:31:39Z Content type: release Language: en Sources: [Semaphore Engineering]() Topics: [ci](), [jobs](), [Development]() Tags: [2026](), [ci](), [cost](), [flag](), [jobs](), [pipeline](), [product-news](), [rebuilds](), [run](), [workflow]() ### AI overview Semaphore now reruns only failed jobs in a pipeline, carrying over successful jobs and preserving the workflow topology. This reduces rerun time and billable usage, while a YAML flag preserves the previous full-block rebuild behavior. ### Source excerpt Your pipeline fails on one job, and until now you had to rebuild the entire block to recover. Not anymore. Semaphore now reruns only the jobs that actually failed, so you get feedback faster and pay less to get it. What Shipped: Job Rerun When a pipeline failed, the old behavior rebuilt every job inside [...] The post Rerun Only the Jobs That Failed appeared first on Semaphore. ## How the Frontend CTF was created and what its first game involved DevFeed: [How the Frontend CTF was created and what its first game involved]() Original publisher: [Read original article]() Author: DarkMeFoDy (Яндекс) Published: 2026-07-09T07:02:50Z Content type: article Language: ru Sources: [Яндекс - Как мы делаем Яндекс / Статьи]() Topics: [ctf](), [Front end](), [.NET Conf]() Tags: [ctf](), [flag](), [frontend](), [tag-2c039dce53be](), [tag-2cee1cb23725](), [tag-44d9110ce940](), [tag-caea14e49da5]() ### AI overview The article describes the creation and development of the Frontend CTF competition held as part of the "Я 💛 Фронтенд" conference. It explains the format, the first game's origins, its challenges and flags, and the frontend, networking, and developer-tool knowledge used to solve tasks. ### Source excerpt Привет, Хабр! Меня зовут Никита, и я один из тех, кто каждый год делает Frontend CTF в рамках конференции "Я 💛 Фронтенд". Сегодня хочу с вами поделиться, как и зачем мы ежегодно делаем соревнование для тех, кто любит пробираться сквозь загадки, секреты и спрятанные подсказки в браузерной игре. Читать далее ## Lint Me: Test Sources 🖇 DevFeed: [Lint Me: Test Sources 🖇]() Original publisher: [Read original article]() Author: Zarah Dominguez Published: 2025-12-02T00:00:00Z Content type: tutorial Language: en Sources: [Zarah Dominguez]() Topics: [Testing](), [configuration](), [Unit testing]() Tags: [android](), [configuration](), [files](), [flag](), [lint](), [test](), [testing](), [unit-testing]() ### AI overview This tutorial explains how to configure an Android Lint TODO Detector to inspect test sources without enabling every normal Lint rule for those files. It covers the relevant scope configuration and adding unit-test coverage for the change. ### Source excerpt It has been a year, which means it is once again time to re-examine our TODO Lint rule. ## Native Subresource Support in Kubectl DevFeed: [Native Subresource Support in Kubectl]() Original publisher: [Read original article]() Author: Abhimanyu Saharan Published: 2025-06-29T00:00:00Z Content type: tutorial Language: en Sources: [Abhimanyu Saharan]() Topics: [Kubernetes]() Tags: [flag](), [kubectl](), [kubernetes](), [scale]() ### AI overview The article introduces native kubectl support for interacting with Kubernetes subresources such as status and scale through the new --subresource flag, eliminating the need for raw HTTP calls. ### Source excerpt Interact with Kubernetes subresources like `status` and `scale` using `kubectl` natively with the new `--subresource` flag, no more raw HTTP calls. ## netlab: Execute a Command on Multiple Devices DevFeed: [netlab: Execute a Command on Multiple Devices]() Original publisher: [Read original article]() Published: 2025-04-16T05:47:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [Command-line interface](), [Network](), [BGP](), [Bash](), [Shell](), [Cisco]() Tags: [bash](), [bgp](), [cisco](), [command-line](), [filter](), [flag](), [netlab](), [network]() ### AI overview A tutorial on using netlab exec to run the same command across multiple network devices. It explains how to quote shell metacharacters, filter Cisco IOS output, reduce connection-status noise, and handle an unresolved trailing connection message. ### Source excerpt When I was updating the Network Migration with BGP Local-AS Feature blog post, I wanted to execute the same command (show ip bgp) on all routers in my network. Not a problem: since Dan Partelly added the netlab exec command, it's as simple as netlab exec * show ip bgp. Well, not exactly; there are still a few quirks. Read more ... ## Limit the Scope of Git Diff DevFeed: [Limit the Scope of Git Diff]() Original publisher: [Read original article]() Published: 2025-02-17T06:41:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [Git](), [YAML](), [Regular expression](), [BGP]() Tags: [display](), [expression](), [files](), [flag](), [git](), [netlab](), [parameter](), [tests](), [time](), [worth-reading](), [yaml]() ### AI overview This article explains how to use Git diff options to identify meaningful changes in YAML-based netlab integration test results when timestamps and version metadata make ordinary diffs noisy. It discusses filtering diffs with a regular expression and limiting output to files or test suites containing relevant changes. ### Source excerpt The results of netlab integration tests are stored in YAML files, making it easy to track changes improvements with Git. However, once I added the time of test and netlab version to the test results, I could no longer use git diff to figure out which test results changed after a test run - everything changed. For example, these are partial test results from the OSPFv2 tests: Read more ... ## Selectively running Android UI tests DevFeed: [Selectively running Android UI tests]() Original publisher: [Read original article]() Author: Segun Famisa Published: 2024-12-14T00:00:00Z Content type: tutorial Language: en Sources: [Segun Famisa]() Topics: [Android](), [Instrumentation](), [Gradle](), [Command-line interface]() Tags: [adb](), [android](), [ci](), [flag](), [gradle](), [instrumentation](), [junit](), [property](), [pull-request](), [test-lab](), [tests]() ### AI overview This tutorial explains how to selectively run additional checks in Android UI tests. It uses a custom annotation and AndroidJUnitRunner filters to target specific tests, then passes arguments through adb or Gradle so the checks can be enabled only under chosen conditions, such as CI runs. ### Source excerpt Intro This is really a note for my future self. Recently, I had a situation where I wanted to perform some extra checks after a test has been run. These additional checks are done after each test is run via a Junit rule SpecialRule which is applied to a test suite. For the purpose of illustration, let's say our SpecialRule looks like this: class SpecialRule : TestRule { override fun apply(statement: Statement, desc: Description): Statement { return object : Statement() { override fun evaluate() { try { // Run the test. statement.evaluate() } finally { // Perform extra checks after the test. Log.d("SpecialRule", "performing extra checks") } } } } } However, we were concerned about the run duration of the tests being extended significantly by the extra checks, so we wanted a bit more control. That led to some constraints. We wanted to: be able to selectively perform those checks on specific tests perform those checks only under certain conditions. Constraint #1 - Selectively perform additional checks on specific tests The immediate approach that came to mind was to use a custom annotation - @SpecialTest, and then somehow find a way to target the tests that are annotated with this. Luckily, the AndroidJunitRunner provides various filters to target specific annotations. For example, to run all the tests annotated with @SpecialTest , we will use something like: adb shell am instrument -w -e annotation com.mypackage.SpecialTest com.android.foo/androidx.test.runner.AndroidJUnitRunner If you use Flank to run your tests on Firebase Test Lab, then you can use: --test-targets: "annotation com.mypackage.SpecialTest" Now that we can selectively target the tests, we need to extend our test rule to only perform these checks if the test is annotated with @SpecialTest annotation. Our SpecialRule then becomes something like: class SpecialRule : TestRule { override fun apply(statement: Statement, desc: Description): Statement { return object : Statement() { override fun evaluate() { t ## Safer migrations of fields using progressive rollouts DevFeed: [Safer migrations of fields using progressive rollouts]() Original publisher: [Read original article]() Author: Michael Watson Published: 2024-04-16T09:21:08Z Content type: tutorial Language: en Sources: [Apollo Blog]() Topics: [migration](), [Development](), [developer tooling]() Tags: [announcement](), [apollo-federation](), [external](), [flag](), [graph](), [implementation](), [migrations](), [performance](), [production]() ### AI overview This article explains how Apollo Federation 2.7's progressive feature supports safer field migrations between subgraphs. It describes gradually shifting traffic to a new service, updating the rollout percentage through the schema, and using external coprocessors or Rhai scripts to resolve labels for feature-flag-based routing. ### Source excerpt In the realm of software development, evolution is not just desirable; it's inevitable. Technologies advance, methodologies shift, and systems need to adapt to meet changing demands. In this ever-evolving landscape, Apollo Federation 2.7 introduces a groundbreaking feature: progressive ✨ Rolling out any change to a production subgraph, including field migration, risks degrading the performance of your graph. ## Interfaces 101 : Parsing Command Flags Ep. 9 DevFeed: [Interfaces 101 : Parsing Command Flags Ep. 9]() Original publisher: [Read original article]() Published: 2023-03-27T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Go Language](), [interfaces](), [Command-line interface](), [Code](), [client](), [HTTP](), [API]() Tags: [cli](), [command-line](), [data-transformation](), [flag](), [go](), [golang](), [how-to](), [http](), [implementation](), [interfaces](), [learn](), [unmarshalling](), [validation]() ### AI overview A video tutorial explains how to decode a command-line flag representing an address into a user-defined Go struct. It covers the interface methods involved and validates the supplied flag value. ### Source excerpt Introduction In episode 8, Miki developed a Go HTTP client that had a method to check the health of a theoretical API. The method would construct the request URL and return an error based on the response code received from the server. Miki then created a type that would mock Go's http.RoundTripper interface and replace his client's transport with said type to test it. To improve the efficacy, Miki's stub will simulate an erroneous response to see if his client's Health method is working as intended. ## When to ship it, when to kill it DevFeed: [When to ship it, when to kill it]() Original publisher: [Read original article]() Author: Map Published: 2014-08-13T20:55:56Z Content type: opinion Language: en Sources: [Craig Kerstiens]() Topics: [Heroku](), [Users](), [Testing]() Tags: [beta](), [feature](), [flag](), [heroku](), [philosophies](), [product](), [testing]() ### AI overview The article presents a product-shipping framework based on alpha or beta testing with users. It recommends gradually rolling out a feature, temporarily removing it or disabling its feature flag, and using immediate user feedback to decide whether to improve or kill the feature. ### Source excerpt A few weeks ago at lunch I had the opportunity to catch up with a company in the current YC batch, building something very similar to dataclips. While we talked about a lot of things from what we've learned from dataclips, marketing, and other areas. One area we talked about was product and when to ship vs. when to kill things and I realized I hadn't talked on my fairly simple but clear view on this publicly, so here it is. A large credit to Adam Wiggins for giving this model early on in Heroku and his approach to shipping product. A precursor to shipping First a little background on shipping, in shipping something I'm going to assume you have some process of alpha/beta testing with users. This is actually fairly key, if you're not testing it with users then well the rest of this is all moot. Alpha and beta testing is pretty simple, you need some early users. These can be friends, people within a network, or random users you select from. There's different value to how you select these but that's a topic for another time and place. On to shipping So how do you know it's ready. The basic idea is super simple. Give it to some users in alpha/beta testing. Or start to roll it out following a one -> some -> many all principle (maybe to 5% or 10% of your userbase). Then take that brand new feature away. There's a couple of ways to do this as far as mechanics. If you're in contact with users such as alpha/beta users that you were higher touch with just email them. Tell them you're removing the feature, or if you want to approach it more softly ask them how much they'd miss it if it were gone tomorrow. If you're rolling it out more broadly perhaps behind a feature flag, flip it off and watch for feedback. Once you take the feature away or threaten to if you don't have users with pitchforks almost immediately then it's not ready to ship. Go back to the drawing board and work more on it or simply kill it. As @james_heroku would say: "So you're saying the reason to ship the shi ## Capture The Flag DevFeed: [Capture The Flag]() Original publisher: [Read original article]() Author: Square Engineering Published: 2014-01-17T17:05:00Z Content type: release Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [ctf](), [Embedded Software Dev](), [Vulnerabilities](), [Exploit](), [Assembly](), [debug](), [Security](), [Programming]() Tags: [announce](), [assembly](), [capture](), [ctf](), [debugging](), [engineering](), [exploit](), [firmware](), [flag](), [programming](), [security]() ### AI overview Square and Matasano launched a Capture the Flag challenge based on finding and exploiting vulnerabilities in firmware running on an MSP430 chip. Participants use a debugging interface and progress through levels covering assembly, buffer overflows, and DRM cracking. ### Source excerpt A Square/Matasano firmware challenge.