今日已更新 84 条资讯 | 累计 37333 条内容
关于我们

标签：#github

找到 1538 篇相关文章

AI 资讯

Your GitHub Actions cron fires less often than you declared: what we measured and how to design for it

We run an automated publishing pipeline entirely on GitHub Actions cron schedules — no server, no queue, just workflows that wake up, do one thing, and commit the result. It mostly works. But there is one behaviour of scheduled workflows that the docs mention in a single quiet sentence and that will silently halve your job frequency if you design around the cron expression instead of around reality: Scheduled workflows do not fire as often as you declare. What we measured We had a feedback-watcher workflow declared at four runs per hour: on : schedule : - cron : ' 7,22,37,52 * * * *' Measured over days, it actually fired one to two times per hour — not four, and not at the declared minutes. Roughly hourly on most days, at inconsistent offsets from the declared slots. We later redeclared it at two runs per hour ( 7,37 * * * * ) — measured result: still one to two runs per hour. The declared frequency changed by 2x; the delivered frequency barely moved. This is not an outage and not a misconfiguration. GitHub's own documentation says the schedule event can be delayed during periods of high load , and that high load times include the start of every hour — which is precisely where naive cron expressions cluster — and adds: "If the load is sufficiently high enough, some queued jobs may be dropped." What the docs understate is the magnitude: in our observation, on a private repo, "delayed" in practice meant "throttled to a fraction of the declared rate, indefinitely." What this breaks The failure mode is subtle because nothing goes red. Every run that happens succeeds. The runs that don't happen leave no trace — no log, no failure email, nothing. You only notice if something downstream depends on the frequency: We had promised a "reply within 15 minutes" SLA on incoming feedback, initially backed by the 4x/hour schedule. The schedule couldn't hold it, so for a while we ran a local 15-minute scheduler as the primary path and kept the workflow as fallback. When we later rel

2026-08-21 原文 →
开发者

My First GitHub Project: From a Local Folder to GitHub Using Git and SSH

Getting your folder or file to github can be a bit of an off vibe due to the many steps especially if it's your first commit, but getting these steps right will make it easy for the other folders or files you will push afterwards.Let’s dive in CREATING A LOCAL FOLDER Depending on the OS you are using you can use Git Bash or the Terminal. For Linux which is what I am using I will use the Terminal First Step Start by creating a folder in the terminal: mkdir your project folder name . then change directory: cd ~/to the folder you have just created Now we need to format our folder by creating a few files inside it Data file README.md code file if you will be using code. To check if you have created these files inside your folder: run:, ls This calls out all the files that are inside your folder. Let's tackle the files we have just added. Data Folder Run command: mkdir data This creates a data folder. This is where you will add your data e.g Excel or CSV files that you will be using to run your analysis or your project. README.md Run command: touch README.md This where you will give an overview of your work, the reason you are doing the analysis,how you collected your data,the tools you used to run the analysis..Basically README.md is a file that guides anyone who goes through your analysis or project on the steps you took while doing your analysis or project.Think of it as the introduction at the start of your favourite book or novel. To write all of this you will run the command echo "#give your project a name or describe your project" >README.md README.md uses markdown language reason for the # at the beginning of the quotation.When writing the headings or subtitles use capital letters or proper style. For subtitles you need to add two ## at the beginning. If you want to write more content without overwriting what you have previously written inside the README.md file you will need to use double greater signs(>>) at the end of the quotation,run: echo #your message” >>R

2026-08-21 原文 →
← 上一页 下一页 →