From 137e15d20f89dec042d78082fec15fa35cf7d841 Mon Sep 17 00:00:00 2001 From: Cody Maffucci <46459665+Maffooch@users.noreply.github.com> Date: Thu, 24 Sep 2026 14:46:20 -0600 Subject: [PATCH 1/3] chore(release): retire the bugfix branch; release from dev -> master Every release, the weekly patch (x.y.100, x.y.200, ...) and the monthly minor (x.y.0), is now cut from dev and merged into master. There is no separate bugfix line and no hotfix path off master. All PRs target dev. Workflows: - release-1: from_branch keeps its input for existing callers but only offers dev; one version check accepts x.y.0 and x.y.100; drop the dead release/ guard on the push step; reword the chart -dev strip messages. - release-3: remove the master-into-bugfix merge-back job. - Drop bugfix from branch filters and conditions in test-helm-chart, unit-tests, ci-warm-caches, migration-graph, ruff, detect-merge-conflicts and renovate. - gh-pages: publish on pushes to master and dev, with a concurrency group so the two deploys queue instead of racing. - release_drafter_valentijn: the previous release tag is now the normal changeset start; update the input help text. Docs and agent guidance: - PR template, CONTRIBUTING and RELEASING describe the single dev line. - branching-model page and its 7 translations: dev -> release -> master diagram, patch releases from dev, fixed workflow links. - AGENTS.md, branch-guard.sh and the repo skills: all work on dev, master stays gated behind explicit confirmation, one milestone query. Co-Authored-By: Claude Opus 5.5 --- .claude/hooks/branch-guard.sh | 43 +++++----- .claude/skills/defectdojo-dev/SKILL.md | 6 +- .claude/skills/defectdojo-parser/SKILL.md | 2 +- .github/pull_request_template.md | 3 +- .github/workflows/ci-warm-caches.yml | 9 +- .github/workflows/detect-merge-conflicts.yaml | 1 - .github/workflows/gh-pages.yml | 8 +- .github/workflows/migration-graph.yml | 1 - .github/workflows/release-1-create-pr.yml | 28 +++---- .../workflows/release-3-master-into-dev.yml | 82 ------------------- .../workflows/release_drafter_valentijn.yml | 6 +- .github/workflows/renovate.yaml | 1 - .github/workflows/ruff.yml | 1 - .github/workflows/test-helm-chart.yml | 5 +- .github/workflows/unit-tests.yml | 5 +- AGENTS.md | 69 ++++++---------- .../contributing/branching-model.de.md | 35 +++----- .../contributing/branching-model.es.md | 35 +++----- .../contributing/branching-model.fr.md | 35 +++----- .../contributing/branching-model.it.md | 35 +++----- .../contributing/branching-model.ja.md | 35 +++----- .../contributing/branching-model.md | 35 +++----- .../contributing/branching-model.pt-br.md | 35 +++----- .../contributing/branching-model.zh-hans.md | 35 +++----- readme-docs/CONTRIBUTING.md | 4 +- readme-docs/RELEASING.md | 77 +++++------------ 26 files changed, 204 insertions(+), 427 deletions(-) diff --git a/.claude/hooks/branch-guard.sh b/.claude/hooks/branch-guard.sh index 4d3cbc20998..701b6ffb559 100755 --- a/.claude/hooks/branch-guard.sh +++ b/.claude/hooks/branch-guard.sh @@ -1,15 +1,14 @@ #!/usr/bin/env bash # Branch guard — makes the target release line explicit before any code lands. # -# DefectDojo ships from three long-lived branches (see the "Branch Check" section -# of AGENTS.md): -# bugfix -> next PATCH release (fastest timeline) <- bug fixes, regressions -# dev -> next MINOR release <- features, refactors -# master -> already released <- release / backport only +# DefectDojo has two long-lived branches (see the "Branch Check" section of +# AGENTS.md): +# dev -> next release, weekly patch or monthly minor <- all work: fixes, features +# master -> already released <- release tasks only # -# A fix based on `dev` cannot ship until the next minor release, which is the most -# common way an urgent fix quietly misses the patch line. This hook reports the -# branch before work starts, and hard-blocks edits while on `master`. +# Every release is cut from `dev` and merged into `master`; there is no separate +# patch branch and no hotfix path off `master`. This hook reports the branch before +# work starts, and hard-blocks edits while on `master`. # # Three modes, all wired in .claude/settings.json: # session SessionStart: report the branch and its release line into context. @@ -54,13 +53,12 @@ g rev-parse --git-dir >/dev/null || exit 0 # not a checkout, nothing to guard BRANCH="$(g symbolic-ref --quiet --short HEAD)" -# Release line: patch | minor | released | detached | unknown. Topic branches are -# classified by what they contain, not by their name — dev is checked first, -# because dev contains bugfix once bugfix has been merged forward. +# Release line: working | released | detached | unknown. Topic branches are +# classified by what they contain, not by their name: a branch that contains +# origin/dev is on the working line. line_of() { case "$BRANCH" in - bugfix) echo patch; return ;; - dev) echo minor; return ;; + dev) echo working; return ;; master) echo released; return ;; esac if [ -z "$BRANCH" ]; then @@ -71,9 +69,7 @@ line_of() { return fi if g merge-base --is-ancestor origin/dev HEAD; then - echo minor - elif g merge-base --is-ancestor origin/bugfix HEAD; then - echo patch + echo working else echo unknown fi @@ -84,11 +80,10 @@ LINE="$(line_of)" if [ "$MODE" = "session" ]; then [ -z "$PY" ] && exit 0 # informational only; nothing to report without python3 case "$LINE" in - patch) DESC="ships in the next PATCH release (the fast line): bug fixes and regressions belong here, features do not" ;; - minor) DESC="ships in the next MINOR release: features and refactors belong here, and a BUG FIX based here will NOT ship until that minor release" ;; - released) DESC="is already-released code: nothing belongs here except a release or backport task, and edits are BLOCKED until a human confirms" ;; + working) DESC="is on the working line (dev) and ships in the next release, weekly patch or monthly minor: bug fixes and features both belong here" ;; + released) DESC="is already-released code: nothing belongs here except a release task, and edits are BLOCKED until a human confirms" ;; detached) DESC="is a detached HEAD, so the release line is unclear" ;; - *) DESC="contains neither origin/bugfix nor origin/dev, so its base is stale or unmerged: run 'git fetch' and check the base before editing" ;; + *) DESC="does not contain origin/dev, so its base is stale or unmerged: run 'git fetch' and check the base before editing" ;; esac "$PY" -c ' import json, sys @@ -98,7 +93,7 @@ print(json.dumps({"hookSpecificOutput": { "additionalContext": ( "Branch check: this checkout is on branch " + branch + ", which " + desc + ". " "State the branch and its release line back to the user before editing files. " - "If the task is a bug fix sitting on the minor line, say so and offer to move it onto bugfix first." + "All work targets dev. If the branch is not on dev (or a topic branch containing origin/dev), say so and offer to move the work onto origin/dev first." ), }})) ' "${BRANCH:-detached HEAD}" "$DESC" @@ -120,14 +115,14 @@ ACK_FILE="${ACK_DIR:-/nonexistent}/claude-branch-ack-${SESSION_ID}" if [ "$MODE" = "commit" ]; then ACTION="Committing"; else ACTION="Editing files"; fi -REASON="BLOCKED: ${ACTION} is not allowed right now, because this checkout is on ${WHERE}, which holds already-released code. Bug fixes belong on \`bugfix\` (next patch release) and features on \`dev\` (next minor). +REASON="BLOCKED: ${ACTION} is not allowed right now, because this checkout is on ${WHERE}, which holds already-released code. All work, bug fixes and features alike, belongs on \`dev\` (the next release). Do NOT retry, and do NOT work around this. Instead: 1. Tell the user the checkout is on master and the change is blocked. - 2. Ask them to confirm this work is genuinely intended for master (a release or a backport), and WAIT for their reply. + 2. Ask them to confirm this work is genuinely intended for master (a release task), and WAIT for their reply. 3. If they confirm, record it with: touch '${ACK_FILE}' (that command prompts them for approval, which IS the confirmation) then continue. - 4. If they do not confirm, move the work first: git switch -c origin/bugfix + 4. If they do not confirm, move the work first: git switch -c origin/dev The ack lasts for this session only." diff --git a/.claude/skills/defectdojo-dev/SKILL.md b/.claude/skills/defectdojo-dev/SKILL.md index 4824a4a1fa8..860329afb07 100644 --- a/.claude/skills/defectdojo-dev/SKILL.md +++ b/.claude/skills/defectdojo-dev/SKILL.md @@ -11,8 +11,8 @@ templates, not a SPA) run via Docker Compose, with a Postgres DB and a Valkey br the loop below against a **running local stack** — do not reason about behavior from the code alone when you can exercise it. -Read `AGENTS.md` first for the branch/release-line policy: bug fixes target `bugfix`, -features target `dev`, and `master` is off-limits without explicit confirmation (the +Read `AGENTS.md` first for the branch/release-line policy: bug fixes and features both +target `dev`, and `master` is off-limits without explicit confirmation (the `.claude/hooks/branch-guard.sh` hook enforces this). Put the work on the right branch before editing. @@ -153,7 +153,7 @@ A recurring PR category touches the Helm chart (`helm/defectdojo/`), nginx confi still apply (security defaults, backward compatibility), but the checks are different: - **The branch/release-line policy applies to chart and docker PRs too** — they are not - exempt. A fix still targets `bugfix`, a feature `dev`, never `master`. Defer to `AGENTS.md`. + exempt. Fixes and features both target `dev`, never `master`. Defer to `AGENTS.md`. - **Know the three Helm CI jobs** (`.github/workflows/test-helm-chart.yml`) — each is an automatic blocker when it fails: - **`Lint chart (version)`** includes an **`artifacthub.io/changes` annotation check**: it diff --git a/.claude/skills/defectdojo-parser/SKILL.md b/.claude/skills/defectdojo-parser/SKILL.md index 6213637472b..e3bab92dfd5 100644 --- a/.claude/skills/defectdojo-parser/SKILL.md +++ b/.claude/skills/defectdojo-parser/SKILL.md @@ -227,7 +227,7 @@ table** — they drift and get rejected in review. ## Notes -- **New parser = a feature → targets `dev`**; a parser bugfix targets `bugfix`. Label the PR +- **New parsers and parser fixes both target `dev`.** Label the PR `Import Scans`. Defer to `AGENTS.md` for the branch/milestone policy. - **New API parsers from the community are currently not accepted** (supportability) — flag this in review of an inbound API parser. diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 10e6126fbf4..f769ebf82d3 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -22,8 +22,7 @@ Please update any documentation when needed in the [documentation folder](https: This checklist is for your information. - [ ] Make sure to rebase your PR against the very latest `dev`. -- [ ] Features/Changes should be submitted against the `dev`. -- [ ] Bugfixes should be submitted against the `bugfix` branch. +- [ ] Submit all PRs, features and bug fixes alike, against the `dev` branch. - [ ] Give a meaningful name to your PR, as it may end up being used in the release notes. - [ ] Your code is Ruff compliant (see [ruff.toml](../ruff.toml)). - [ ] Your code is python 3.13 compliant. diff --git a/.github/workflows/ci-warm-caches.yml b/.github/workflows/ci-warm-caches.yml index fcc2dccec9a..c266cf34c9d 100644 --- a/.github/workflows/ci-warm-caches.yml +++ b/.github/workflows/ci-warm-caches.yml @@ -11,13 +11,13 @@ name: "CI: Warm Caches" # Without a workflow like this one, caching the migrated database would therefore # do nothing at all for the first push of a new branch, which is most branches # most of the time. Something has to save an entry into a scope pull requests are -# allowed to read, and only a run triggered from a release line can do that. +# allowed to read, and only a run triggered from the dev branch can do that. # # Note what is deliberately absent: a `schedule:` trigger. Scheduled workflows # only ever run against the default branch, so a cron here would run with ref -# refs/heads/master and warm the master scope -- not the release-line scopes this -# is for. Eviction is handled instead by reads: GitHub drops an entry it has not -# seen used for 7 days, and every pull request based on a release line reads this +# refs/heads/master and warm the master scope -- not the dev scope this is +# for. Eviction is handled instead by reads: GitHub drops an entry it has not +# seen used for 7 days, and every pull request based on dev reads this # one, which keeps it alive without a timer. # # Warming the default-branch scope is worth doing too, since every run can read @@ -27,7 +27,6 @@ name: "CI: Warm Caches" on: push: branches: - - bugfix - dev # Exactly the paths the snapshot key hashes -- anything else leaves the key # unchanged, so there would be nothing to warm. diff --git a/.github/workflows/detect-merge-conflicts.yaml b/.github/workflows/detect-merge-conflicts.yaml index c5c07df38e3..e1595d83bb1 100644 --- a/.github/workflows/detect-merge-conflicts.yaml +++ b/.github/workflows/detect-merge-conflicts.yaml @@ -5,7 +5,6 @@ on: branches: - dev - master - - bugfix - release/* pull_request_target: diff --git a/.github/workflows/gh-pages.yml b/.github/workflows/gh-pages.yml index d78e23f1f06..47cfa71130f 100644 --- a/.github/workflows/gh-pages.yml +++ b/.github/workflows/gh-pages.yml @@ -7,7 +7,13 @@ on: - 'docs/**' branches: - master - - bugfix + - dev + +# A master deploy and a dev deploy both publish to the gh-pages branch. +# Queue them instead of letting them race. +concurrency: + group: gh-pages-deploy + cancel-in-progress: false # Taken from https://github.com/marketplace/actions/hugo-setup#%EF%B8%8F-workflow-for-autoprefixer-and-postcss-cli # Both builds have to be one worflow as otherwise one publish will overwrite the other diff --git a/.github/workflows/migration-graph.yml b/.github/workflows/migration-graph.yml index 2216912f814..6eb4f1835ad 100644 --- a/.github/workflows/migration-graph.yml +++ b/.github/workflows/migration-graph.yml @@ -32,7 +32,6 @@ on: branches: - master - dev - - bugfix - release/** - hotfix/** pull_request: diff --git a/.github/workflows/release-1-create-pr.yml b/.github/workflows/release-1-create-pr.yml index d1abed9c079..554c0e4009e 100644 --- a/.github/workflows/release-1-create-pr.yml +++ b/.github/workflows/release-1-create-pr.yml @@ -6,15 +6,14 @@ env: on: workflow_dispatch: inputs: - # the actual branch that can be chosen on the UI is made irrelevant by further steps - # because someone will forget one day to change it. + # Every release (weekly patch and monthly minor) is cut from dev. The input is kept + # so existing callers that pass `-f from_branch=dev` keep working. from_branch: - description: "Select branch to release from. Dev branch releases happen the first monday of the month. Otherwise, use bugfix." + description: "Branch to release from. All releases, weekly patches and monthly minors, come from dev." required: true type: choice - default: 'bugfix' + default: 'dev' options: - - bugfix - dev release_number: description: "Release version (x.y.z format)" @@ -24,17 +23,11 @@ jobs: create_pr: runs-on: ubuntu-latest steps: - - name: Validate proper bugfix branch release_number format is being used - if: ${{ inputs.from_branch == 'bugfix' }} + - name: Validate release_number format run: | - # Expect a valid x.y.z release_number with a 1-3 digit last octet - echo "${{ inputs.release_number }}" | grep "^[0-9]*\.[0-9]*\.[0-9]\{1,3\}$" - - - name: Validate proper dev branch release_number format is being used - if: ${{ inputs.from_branch == 'dev' }} - run: | - # Expect the last octet in release_number to not be 1-9 - echo "${{ inputs.release_number }}" | grep "^[0-9]*\.[0-9]*\.0$" + # Expect x.y.z with a 1-3 digit last octet: x.y.0 for a monthly minor, + # x.y.100 / x.y.200 / ... for a weekly patch + echo "${{ inputs.release_number }}" | grep -E '^[0-9]+\.[0-9]+\.[0-9]{1,3}$' - id: Set-GitHub-org run: echo "GITHUB_ORG=${GITHUB_REPOSITORY%%/*}" >> $GITHUB_ENV @@ -54,7 +47,6 @@ jobs: git config --global user.email "${{ env.GIT_EMAIL }}" - name: Push branch - if: "!startsWith('${{ inputs.from_branch }}', 'release/')" run: git push origin HEAD:${NEW_BRANCH} - name: Checkout release branch @@ -69,11 +61,11 @@ jobs: sed -ri 's/appVersion: ".*"/appVersion: "${{ inputs.release_number }}"/' helm/defectdojo/Chart.yaml if grep "\-dev" helm/defectdojo/Chart.yaml; then - echo "x.y.z-dev found in Chart.yaml, probably releasing a new minor version" + echo "x.y.z-dev found in Chart.yaml (the normal case for a release from dev)" echo "removing the -dev suffix" sed -e "s/\-dev//" -i helm/defectdojo/Chart.yaml else - echo "x.y.z without -dev found in Chart.yaml, probably releasing a new bug fix version" + echo "x.y.z without -dev found in Chart.yaml: the chart was already stripped, probably a manual re-release" CURRENT_CHART_VERSION=$(grep -oP 'version: (\K\S*)?' helm/defectdojo/Chart.yaml | head -1) NEW_CHART_VERSION=$(echo "version: $CURRENT_CHART_VERSION" | awk -F. -v OFS=. 'NF==1{print ++$NF}; NF>1{$NF=sprintf("%0*d", length($NF), ($NF+1)); print}') echo "bumping the chart version from $CURRENT_CHART_VERSION to $NEW_CHART_VERSION" diff --git a/.github/workflows/release-3-master-into-dev.yml b/.github/workflows/release-3-master-into-dev.yml index 209447d0c06..a3521d18a33 100644 --- a/.github/workflows/release-3-master-into-dev.yml +++ b/.github/workflows/release-3-master-into-dev.yml @@ -113,85 +113,3 @@ jobs: issue_number: pr.data.number, labels: ['release-management'] }) - - create_pr_for_merge_back_into_bugfix: - runs-on: ubuntu-latest - steps: - - id: Set-GitHub-org - run: echo "GITHUB_ORG=${GITHUB_REPOSITORY%%/*}" >> $GITHUB_ENV - - - name: Checkout master - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 - with: - ref: master - - - name: Create merge back branch - run: | - echo "NEW_BRANCH=master-into-bugfix/${{ inputs.release_number_new }}-${{ inputs.release_number_dev }}" >> $GITHUB_ENV - - - name: Configure git - run: | - git config --global user.name "${{ env.GIT_USERNAME }}" - git config --global user.email "${{ env.GIT_EMAIL }}" - - - name: Push new branch - run: git push origin HEAD:${NEW_BRANCH} - - - name: Checkout new branch - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 - with: - ref: ${{ env.NEW_BRANCH }} - - - name: Update version numbers in key files - run: | - sed -ri "s/__version__ = '.*'/__version__ = '${{ inputs.release_number_dev }}'/" dojo/__init__.py - sed -ri "s/appVersion: \".*\"/appVersion: \"${{ inputs.release_number_dev }}\"/" helm/defectdojo/Chart.yaml - sed -ri "s/\"version\": \".*\"/\"version\": \"${{ inputs.release_number_dev }}\"/" components/package.json - CURRENT_CHART_VERSION=$(grep -oP 'version: (\K\S*)?' helm/defectdojo/Chart.yaml | head -1) - sed -ri "0,/version/s/version: \S+/$(echo "version: $CURRENT_CHART_VERSION" | awk -F. -v OFS=. 'NF==1{print ++$NF}; NF>1{$NF=sprintf("%0*d", length($NF), ($NF+1)); print}')-dev/" helm/defectdojo/Chart.yaml - - - name: Check numbers - run: | - grep version dojo/__init__.py - grep appVersion helm/defectdojo/Chart.yaml - grep version components/package.json - - - name: Update values in HELM chart - run: | - yq -i '.annotations = {}' helm/defectdojo/Chart.yaml - yq -i '.annotations."artifacthub.io/prerelease" = "true"' helm/defectdojo/Chart.yaml - yq -i '.annotations."artifacthub.io/changes" = ""' helm/defectdojo/Chart.yaml - - - name: Run helm-docs - uses: losisin/helm-docs-github-action@9e0787c426fdec38be6288bb5c0559dcb388412c # v2 - with: - chart-search-root: "helm/defectdojo" - - - name: Push version changes - uses: stefanzweifel/git-auto-commit-action@4a55954c782fc1ea30b9056cd3e7a2b40ca8887d # v7.2.0 - with: - commit_user_name: "${{ env.GIT_USERNAME }}" - commit_user_email: "${{ env.GIT_EMAIL }}" - commit_author: "${{ env.GIT_USERNAME }} <${{ env.GIT_EMAIL }}>" - commit_message: "Update versions in application files" - branch: ${{ env.NEW_BRANCH }} - - - name: Create Pull Request - uses: actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3 # v9.0.0 - with: - github-token: ${{ secrets.GITHUB_TOKEN }} - script: | - const pr = await github.rest.pulls.create({ - owner: '${{ env.GITHUB_ORG }}', - repo: 'django-DefectDojo', - title: 'Release: Merge back ${{ inputs.release_number_new }} into bugfix from: ${{ env.NEW_BRANCH }}', - body: `Release triggered by \`${ process.env.GITHUB_ACTOR }\``, - head: '${{ env.NEW_BRANCH }}', - base: 'bugfix' - }) - await github.rest.issues.addLabels({ - owner: '${{ env.GITHUB_ORG }}', - repo: 'django-DefectDojo', - issue_number: pr.data.number, - labels: ['release-management'] - }) diff --git a/.github/workflows/release_drafter_valentijn.yml b/.github/workflows/release_drafter_valentijn.yml index af427384086..1df18e19d5c 100644 --- a/.github/workflows/release_drafter_valentijn.yml +++ b/.github/workflows/release_drafter_valentijn.yml @@ -12,9 +12,9 @@ on: description: | Semver range limiting which past releases may be picked as the previous release, i.e. where the changeset starts. Evaluated per tag with node's semver.satisfies(). - For a minor-to-minor changeset, pass the previous minor tag exactly, e.g. '3.1.0'. - For changes since the last patch of the previous minor, pass a range, e.g. '>=3.1.0 <3.2.0'. - Leave empty to start from the most recent release. + Every release, patch or minor, is cut from dev, so the previous release tag is + the natural start: leave this empty for the normal case. + Set it only to start somewhere else, e.g. '3.1.0' for a changeset since 3.1.0. required: false dry-run: description: | diff --git a/.github/workflows/renovate.yaml b/.github/workflows/renovate.yaml index e3806c9ff60..7c6537de596 100644 --- a/.github/workflows/renovate.yaml +++ b/.github/workflows/renovate.yaml @@ -5,7 +5,6 @@ on: branches: - dev - master - - bugfix - release/* jobs: diff --git a/.github/workflows/ruff.yml b/.github/workflows/ruff.yml index 70306846501..aa5fc8631a7 100644 --- a/.github/workflows/ruff.yml +++ b/.github/workflows/ruff.yml @@ -11,7 +11,6 @@ on: branches: - master - dev - - bugfix - release/** - hotfix/** pull_request: diff --git a/.github/workflows/test-helm-chart.yml b/.github/workflows/test-helm-chart.yml index 74bb6327339..07c757a2c07 100644 --- a/.github/workflows/test-helm-chart.yml +++ b/.github/workflows/test-helm-chart.yml @@ -4,7 +4,6 @@ on: branches: - master - dev - - bugfix - release/** - hotfix/** @@ -66,7 +65,7 @@ jobs: # x.y.z gets bumped automatically when doing a release - name: Run chart-testing (lint) run: ct lint --config ct.yaml --target-branch ${{ env.ct-branch }} --check-version-increment=true - if: ${{ steps.list_changed.outputs.changed == 'true' && env.ct-branch != 'dev' && env.ct-branch != 'bugfix' }} + if: ${{ steps.list_changed.outputs.changed == 'true' && env.ct-branch != 'dev' }} # run all checks but version increment always when something changed - name: Run chart-testing (lint) @@ -74,7 +73,7 @@ jobs: if: steps.list_changed.outputs.changed == 'true' - name: Check update of "artifacthub.io/changes" HELM annotation - if: ${{ steps.list_changed.outputs.changed == 'true' && !(startsWith(github.head_ref, 'master-into-dev/') || startsWith(github.head_ref, 'master-into-bugfix/')) }} + if: ${{ steps.list_changed.outputs.changed == 'true' && !startsWith(github.head_ref, 'master-into-dev/') }} run: | # fast fail if `git show` fails set -e diff --git a/.github/workflows/unit-tests.yml b/.github/workflows/unit-tests.yml index 7bcacf37654..8043a3472a8 100644 --- a/.github/workflows/unit-tests.yml +++ b/.github/workflows/unit-tests.yml @@ -6,11 +6,10 @@ on: branches: - master - dev - - bugfix - release/** - hotfix/** # No paths/paths-ignore here, ever. `Unit Tests Complete` below is a required - # check on bugfix, and a required check whose workflow never triggers sits as + # check on dev, and a required check whose workflow never triggers sits as # "Expected -- waiting for status to be reported" forever. A PR must pass its # required checks BEFORE it can enter the merge queue, so a trigger-level # docs/** filter left docs-only PRs unqueueable for anyone without ruleset @@ -22,7 +21,7 @@ on: # point ever evaluates their union. # # The queue that emits these events is the "Merge Queue" ruleset (id 20466211), - # active on bugfix: SQUASH, ALLGREEN grouping, max 3 entries building, and it + # active on dev: SQUASH, ALLGREEN grouping, max 3 entries building, and it # requires `ruff-linting` and `Unit Tests Complete` on the merge group. Two # operational notes recorded here so they survive the people who know them: # diff --git a/AGENTS.md b/AGENTS.md index 46d9601ee29..140a6a4da37 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -5,31 +5,29 @@ Establish the current branch and its release line *before* editing files, and state both back to the user. This applies to every change, including one-line fixes. +All work targets `dev`. Every release, the weekly patch (`X.Y.100`, `X.Y.200`, ...) and +the monthly minor (`X.Y.0`), is cut from `dev` and merged into `master`. There is no +separate patch branch and no hotfix path off `master`. + | Branch | Ships in | Base work here when | |--------|----------|---------------------| -| `bugfix` | the next **patch** release (fastest timeline) | bug fixes, regressions, anything that should not wait | -| `dev` | the next **minor** release | new features, refactors, schema/model changes | -| `master` | already released | never, except an explicit release or backport task | +| `dev` | the next release, patch or minor, whichever the schedule puts first | always: bug fixes, regressions, features, refactors, schema/model changes | +| `master` | already released | never, except an explicit release task | ```bash git branch --show-current -# Which line was a topic branch cut from? Ancestry, not the branch name: -for b in dev bugfix master; do - git merge-base --is-ancestor "origin/$b" HEAD 2>/dev/null && echo "contains origin/$b" -done +# Is a topic branch on the working line? Ancestry, not the branch name: +git merge-base --is-ancestor origin/dev HEAD 2>/dev/null && echo "contains origin/dev" ``` Rules: -- **A fix based on `dev` does not ship until the next minor release.** If the task is a - bug or regression and the branch is `dev` (or was cut from `dev`), say so before - starting and offer to move the work onto `bugfix`: `git switch -c origin/bugfix`. - This is the most common way an urgent fix quietly misses the patch line. -- **A feature based on `bugfix` inflates a patch release.** Same treatment in reverse: - point it out and offer `git switch -c origin/dev`. -- Judge a branch by what it was *cut from*, not by its name. A branch called - `fix/whatever` sitting on top of `dev` still ships with the minor release. -- The PR base branch must match the line the work was cut from. +- **Base every change on `dev`.** Bug fixes and features both go there, and ship in the + next release from `dev`. +- Judge a topic branch by whether it *contains* `origin/dev`, not by its name. A branch + cut from `master` or an old release branch is not on the working line: say so and offer + `git switch -c origin/dev`. +- The PR base branch is `dev`. ### On `master`, stop and get explicit confirmation @@ -37,10 +35,10 @@ Rules: and on `git commit`, and denies them while the checkout is on `master` (or a detached HEAD at `origin/master`). When it fires, do not retry and do not work around it. Tell the user the checkout is on `master`, ask them to confirm the change is genuinely intended -for the released line (a release or backport task), and wait for the answer. On -confirmation, run the `touch` command the hook prints; that command is deliberately not -allowlisted, so approving its prompt *is* the confirmation. Without confirmation, move -the work to `bugfix` first. +for the released line (a release task), and wait for the answer. On confirmation, run +the `touch` command the hook prints; that command is deliberately not allowlisted, so +approving its prompt *is* the confirmation. Without confirmation, move +the work to `dev` first: `git switch -c origin/dev`. The ack covers one session. A `SessionStart` hook reports the branch and its release line at startup so the branch is settled before the first edit. @@ -49,28 +47,15 @@ at startup so the branch is settled before the first edit. ### Every new PR gets a milestone, and that milestone already exists -Set the milestone in the same step that opens the PR, not in a later cleanup pass. Which -milestone follows from the PR's **base branch**, for the same reason the Branch Check -above matters: a `dev` PR cannot ship in a patch release, so it must not carry a patch -milestone. - -| Base branch | Milestone to attach | Example, for a PR opened 2026-08-03 | -|-------------|---------------------|-------------------------------------| -| `bugfix` | next weekly patch, `X.Y.` | `3.2.100` | -| `dev` | next monthly minor, `X.Y.0` | `3.3.0` | -| `master` | the version actually being released or backported into — ask, do not guess | `3.2.0` | - -"Next" means the earliest **open** milestone of that kind whose due date is still in the -future. A milestone due today or overdue is usually a release already cut, so a PR opened -now will not make it. Read the answer out of the repo instead of from memory: +Set the milestone in the same step that opens the PR, not in a later cleanup pass. Every +PR targets `dev`, and the next release from `dev` is whichever release the schedule puts +first, patch (`X.Y.`) or minor (`X.Y.0`). So the milestone is the earliest +**open** milestone of either kind whose due date is still in the future. A milestone due +today or overdue is usually a release already cut, so a PR opened now will not make it. +Read the answer out of the repo instead of from memory: ```bash -# base bugfix -> next weekly patch milestone -gh api repos/DefectDojo/django-DefectDojo/milestones --paginate --jq \ - '[.[] | select(.state=="open" and (.title|test("\\.[1-9]00$")) and .due_on > (now|todate))] | sort_by(.due_on)[0].title' -# base dev -> next monthly minor milestone -gh api repos/DefectDojo/django-DefectDojo/milestones --paginate --jq \ - '[.[] | select(.state=="open" and (.title|test("\\.0$")) and .due_on > (now|todate))] | sort_by(.due_on)[0].title' +gh api repos/DefectDojo/django-DefectDojo/milestones --paginate --jq '[.[] | select(.state=="open" and .due_on > (now|todate))] | sort_by(.due_on)[0].title' ``` Attach it on creation, or immediately after if the body is written in a second step: @@ -85,10 +70,6 @@ milestone invented at PR time is a release that does not exist. If the query ret `null`, the schedule has not been extended that far: say so and leave the PR unmilestoned. -**Retargeting the base changes the milestone.** Moving a PR between `bugfix` and `dev` -moves which release it ships in, so re-run the query for the new base and `gh pr edit ---milestone` to match. - ## Skills Repo-scoped skills live under `.claude/skills//SKILL.md` (each with helper scripts diff --git a/docs/content/get_started/contributing/branching-model.de.md b/docs/content/get_started/contributing/branching-model.de.md index 57edbaedc65..6f939a1d8c5 100644 --- a/docs/content/get_started/contributing/branching-model.de.md +++ b/docs/content/get_started/contributing/branching-model.de.md @@ -10,23 +10,25 @@ aliases: ## Reguläre Releases -Das DefectDojo-Team strebt folgenden Rhythmus an: +Alle Releases entstehen aus dem Branch `dev`. Das DefectDojo-Team strebt folgenden Rhythmus an: - Minor-Releases: mindestens einmal pro Monat, am ersten Montag des Monats. -- Patch/Bugfix: Releases jede Woche am Montag. -- Security-Releases: erfolgen je nach Schweregrad außerhalb unseres regulären Rhythmus. +- Patch-Releases: jede Woche am Montag. +- Security-Releases: können je nach Schweregrad außerhalb unseres regulären Rhythmus erfolgen. Auch sie entstehen aus `dev`. -GitHub Actions sind die maßgebliche Quelle. Die Releases sind teilautomatisiert. Die Schritte für ein reguläres Release sind: -1. Den Release-Branch aus `dev` oder `bugfix` erstellen und einen PR gegen `master` vorbereiten ([Details](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/new-release-pr.yml)) +Es gibt keinen separaten Branch für Fehlerbehebungen und keinen Hotfix-Branch von `master`. Jeder Pull Request, ob Fehlerbehebung oder Feature, richtet sich gegen `dev`. + +GitHub Actions sind die maßgebliche Quelle. Die Releases sind teilautomatisiert. Die Schritte für jedes Release sind: +1. Den Release-Branch aus `dev` erstellen und einen PR gegen `master` vorbereiten ([Details](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/release-1-create-pr.yml)) --> Ein Maintainer prüft den PR und merged ihn manuell -1. Tag setzen, Draft-Release anlegen und Docker-Image bauen und pushen ([Details](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/new-release-tag-docker.yml)) +1. Tag setzen, Draft-Release anlegen und Docker-Image bauen und pushen ([Details](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/release-2-tag-docker-push.yml)) --> Ein Maintainer überarbeitet die Notizen des Release-Drafters und veröffentlicht das Release -1. Es wird ein PR erstellt, der `master` zurück in `dev` und `bugfix` merged, um die Branches wieder abzugleichen ([Details](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/new-release-master-into-dev.yml)) +1. Es wird ein PR erstellt, der `master` zurück in `dev` merged, um die Branches wieder abzugleichen ([Details](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/release-3-master-into-dev.yml)) ## Security-Releases PRs zu Sicherheitsproblemen werden über [Security Advisories](https://github.com/DefectDojo/django-DefectDojo/security/advisories) abgewickelt. Diese bieten die Möglichkeit, nicht öffentlich am Code zu arbeiten, ohne Schwachstellen vorzeitig offenzulegen. -## Release- und Hotfix-Modell +## Release-Modell Die Diagramme wurden mit [plantUML](https://plantuml.com) erstellt. Einen webbasierten Editor für PlantUML finden Sie unter https://www.planttext.com. @@ -38,7 +40,6 @@ Die Diagramme wurden mit [plantUML](https://plantuml.com) erstellt. Einen webbas @startuml participant "Dev Branch" as dev #LightBlue -participant "BugFix Branch" as bugfix #LightGreen participant "Release Branch" as release #LightGoldenRodYellow participant "Master Branch" as master #LightSalmon @@ -47,24 +48,14 @@ participant "Master Branch" as master #LightSalmon dev -> release: Create branch "release/2.x.0" release -> master: Merge note right: Official Release\n - Tag 2.x.0\n - Push 2.x.0 to DockerHub -master --> bugfix: Merge master into bugfix to realign master --> dev: Merge master back into dev -== Patch/BugFix Release (Weekly) == - -bugfix -> release: Create branch "release/2.x.y" -release -> master: Merge -note right: Official Release\n - Tag 2.x.y\n - Push 2.x.y to DockerHub -master -> bugfix: Merge master back into bugfix to realign -master --> dev: Merge master into dev to realign - -== Security Release (As Needed) == +== Patch Release (Weekly) == -master -> release: Create branch "release/2.x.y" +dev -> release: Create branch "release/2.x.y" release -> master: Merge note right: Official Release\n - Tag 2.x.y\n - Push 2.x.y to DockerHub -master --> bugfix: Merge master into bugfix to realign -master --> dev: Merge master into dev to realign +master --> dev: Merge master back into dev @enduml ``` diff --git a/docs/content/get_started/contributing/branching-model.es.md b/docs/content/get_started/contributing/branching-model.es.md index c10947bda48..c16cf60b821 100644 --- a/docs/content/get_started/contributing/branching-model.es.md +++ b/docs/content/get_started/contributing/branching-model.es.md @@ -10,23 +10,25 @@ aliases: ## Versiones regulares -El equipo de DefectDojo se propone mantener la siguiente cadencia: +Todas las versiones salen de la rama `dev`. El equipo de DefectDojo se propone mantener la siguiente cadencia: - Versiones menores: al menos una vez al mes, el primer lunes del mes. -- Parche/Corrección de errores: versiones cada semana, los lunes. -- Versiones de seguridad: se realizarán fuera de nuestra cadencia habitual según la gravedad. +- Parches: versiones cada semana, los lunes. +- Versiones de seguridad: pueden realizarse fuera de nuestra cadencia habitual según la gravedad. También salen de `dev`. -Las GitHub Actions son la fuente de verdad. Las versiones están semiautomatizadas. Los pasos para una versión regular son: -1. Crear la rama de versión a partir de `dev` o `bugfix` y preparar un PR contra `master` ([detalles](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/new-release-pr.yml)) +No hay una rama separada para correcciones de errores ni una rama de hotfix a partir de `master`. Todo pull request, sea una corrección o una funcionalidad, se dirige a `dev`. + +Las GitHub Actions son la fuente de verdad. Las versiones están semiautomatizadas. Los pasos para cada versión son: +1. Crear la rama de versión a partir de `dev` y preparar un PR contra `master` ([detalles](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/release-1-create-pr.yml)) --> Un mantenedor verifica y fusiona manualmente el PR -1. Etiquetar, emitir un borrador de versión y compilar+publicar la imagen docker ([detalles](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/new-release-tag-docker.yml)) +1. Etiquetar, emitir un borrador de versión y compilar+publicar la imagen docker ([detalles](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/release-2-tag-docker-push.yml)) --> Un mantenedor pule las notas de release-drafter y publica la versión -1. Se crea un PR para fusionar `master` de nuevo en `dev` y `bugfix` con el fin de realinear las ramas ([detalles](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/new-release-master-into-dev.yml)) +1. Se crea un PR para fusionar `master` de nuevo en `dev` con el fin de realinear las ramas ([detalles](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/release-3-master-into-dev.yml)) ## Versiones de seguridad Los PR relacionados con problemas de seguridad se gestionan mediante [avisos de seguridad](https://github.com/DefectDojo/django-DefectDojo/security/advisories) que ofrecen una forma de trabajar en el código de forma privada sin divulgar prematuramente las vulnerabilidades. -## Modelo de versión y hotfix +## Modelo de versiones Diagramas creados con [plantUML](https://plantuml.com). Encuentre un editor web para PlantUML en https://www.planttext.com. @@ -38,7 +40,6 @@ Diagramas creados con [plantUML](https://plantuml.com). Encuentre un editor web @startuml participant "Dev Branch" as dev #LightBlue -participant "BugFix Branch" as bugfix #LightGreen participant "Release Branch" as release #LightGoldenRodYellow participant "Master Branch" as master #LightSalmon @@ -47,24 +48,14 @@ participant "Master Branch" as master #LightSalmon dev -> release: Create branch "release/2.x.0" release -> master: Merge note right: Official Release\n - Tag 2.x.0\n - Push 2.x.0 to DockerHub -master --> bugfix: Merge master into bugfix to realign master --> dev: Merge master back into dev -== Patch/BugFix Release (Weekly) == - -bugfix -> release: Create branch "release/2.x.y" -release -> master: Merge -note right: Official Release\n - Tag 2.x.y\n - Push 2.x.y to DockerHub -master -> bugfix: Merge master back into bugfix to realign -master --> dev: Merge master into dev to realign - -== Security Release (As Needed) == +== Patch Release (Weekly) == -master -> release: Create branch "release/2.x.y" +dev -> release: Create branch "release/2.x.y" release -> master: Merge note right: Official Release\n - Tag 2.x.y\n - Push 2.x.y to DockerHub -master --> bugfix: Merge master into bugfix to realign -master --> dev: Merge master into dev to realign +master --> dev: Merge master back into dev @enduml ``` diff --git a/docs/content/get_started/contributing/branching-model.fr.md b/docs/content/get_started/contributing/branching-model.fr.md index 46a1537c0ca..9587fd56827 100644 --- a/docs/content/get_started/contributing/branching-model.fr.md +++ b/docs/content/get_started/contributing/branching-model.fr.md @@ -10,23 +10,25 @@ aliases: ## Versions régulières -L'équipe DefectDojo vise à maintenir la cadence suivante : +Toutes les versions sont issues de la branche `dev`. L'équipe DefectDojo vise à maintenir la cadence suivante : - Versions mineures : au moins une fois par mois, le premier lundi du mois. -- Correctifs/Bugfix : versions chaque semaine, le lundi. -- Versions de sécurité : réalisées en dehors de notre cadence habituelle, selon la gravité. +- Correctifs : versions chaque semaine, le lundi. +- Versions de sécurité : peuvent être réalisées en dehors de notre cadence habituelle, selon la gravité. Elles sont aussi issues de `dev`. -Les GitHub Actions font foi. Les versions sont semi-automatisées. Les étapes d'une version régulière sont les suivantes : -1. Créer la branche de version à partir de `dev` ou `bugfix` et préparer une PR vers `master` ([détails](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/new-release-pr.yml)) +Il n'y a pas de branche séparée pour les corrections de bugs, ni de branche de correctif d'urgence à partir de `master`. Toute PR, correction ou fonctionnalité, cible `dev`. + +Les GitHub Actions font foi. Les versions sont semi-automatisées. Les étapes de chaque version sont les suivantes : +1. Créer la branche de version à partir de `dev` et préparer une PR vers `master` ([détails](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/release-1-create-pr.yml)) --> Un mainteneur vérifie et fusionne manuellement la PR -1. Créer le tag, publier la version brouillon (draft release) et effectuer le build+push Docker ([détails](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/new-release-tag-docker.yml)) +1. Créer le tag, publier la version brouillon (draft release) et effectuer le build+push Docker ([détails](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/release-2-tag-docker-push.yml)) --> Un mainteneur retravaille les notes du release-drafter et publie la version -1. Une PR pour fusionner `master` vers `dev` et `bugfix` est créée afin de réaligner les branches ([détails](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/new-release-master-into-dev.yml)) +1. Une PR pour fusionner `master` vers `dev` est créée afin de réaligner les branches ([détails](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/release-3-master-into-dev.yml)) ## Versions de sécurité Les PR liées à des problèmes de sécurité sont traitées via des [avis de sécurité](https://github.com/DefectDojo/django-DefectDojo/security/advisories) qui permettent de travailler en privé sur le code sans divulguer prématurément les vulnérabilités. -## Modèle de version et de correctif d'urgence +## Modèle de version Les diagrammes sont créés avec [plantUML](https://plantuml.com). Vous trouverez un éditeur web pour PlantUML à l'adresse https://www.planttext.com. @@ -38,7 +40,6 @@ Les diagrammes sont créés avec [plantUML](https://plantuml.com). Vous trouvere @startuml participant "Dev Branch" as dev #LightBlue -participant "BugFix Branch" as bugfix #LightGreen participant "Release Branch" as release #LightGoldenRodYellow participant "Master Branch" as master #LightSalmon @@ -47,24 +48,14 @@ participant "Master Branch" as master #LightSalmon dev -> release: Create branch "release/2.x.0" release -> master: Merge note right: Official Release\n - Tag 2.x.0\n - Push 2.x.0 to DockerHub -master --> bugfix: Merge master into bugfix to realign master --> dev: Merge master back into dev -== Patch/BugFix Release (Weekly) == - -bugfix -> release: Create branch "release/2.x.y" -release -> master: Merge -note right: Official Release\n - Tag 2.x.y\n - Push 2.x.y to DockerHub -master -> bugfix: Merge master back into bugfix to realign -master --> dev: Merge master into dev to realign - -== Security Release (As Needed) == +== Patch Release (Weekly) == -master -> release: Create branch "release/2.x.y" +dev -> release: Create branch "release/2.x.y" release -> master: Merge note right: Official Release\n - Tag 2.x.y\n - Push 2.x.y to DockerHub -master --> bugfix: Merge master into bugfix to realign -master --> dev: Merge master into dev to realign +master --> dev: Merge master back into dev @enduml ``` diff --git a/docs/content/get_started/contributing/branching-model.it.md b/docs/content/get_started/contributing/branching-model.it.md index 9a97009ff07..86fb4ea63f1 100644 --- a/docs/content/get_started/contributing/branching-model.it.md +++ b/docs/content/get_started/contributing/branching-model.it.md @@ -10,23 +10,25 @@ aliases: ## Release regolari -Il team di DefectDojo punta a mantenere il seguente ritmo: +Tutte le release partono dal branch `dev`. Il team di DefectDojo punta a mantenere il seguente ritmo: - Release minori: almeno una volta al mese, il primo lunedì del mese. -- Patch/Bugfix: release ogni settimana di lunedì. -- Release di sicurezza: verranno eseguite al di fuori del nostro ritmo regolare, a seconda della gravità. +- Patch: release ogni settimana di lunedì. +- Release di sicurezza: possono essere eseguite al di fuori del nostro ritmo regolare, a seconda della gravità. Anche queste partono da `dev`. -GitHub Actions è la fonte autorevole. Le release sono semi-automatizzate. I passaggi per una release regolare sono: -1. Crea il branch di release da `dev` o `bugfix` e prepara una PR verso `master` ([dettagli](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/new-release-pr.yml)) +Non esiste un branch separato per le correzioni di bug né un branch di hotfix da `master`. Ogni pull request, correzione o funzionalità, punta a `dev`. + +GitHub Actions è la fonte autorevole. Le release sono semi-automatizzate. I passaggi per ogni release sono: +1. Crea il branch di release da `dev` e prepara una PR verso `master` ([dettagli](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/release-1-create-pr.yml)) --> Un maintainer verifica e unisce manualmente la PR -1. Tag, creazione della release in bozza e build+push Docker ([dettagli](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/new-release-tag-docker.yml)) +1. Tag, creazione della release in bozza e build+push Docker ([dettagli](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/release-2-tag-docker-push.yml)) --> Un maintainer rifinisce le note del release-drafter e pubblica la release -1. Viene creata una PR per unire `master` di nuovo in `dev` e `bugfix`, per riallineare i branch ([dettagli](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/new-release-master-into-dev.yml)) +1. Viene creata una PR per unire `master` di nuovo in `dev`, per riallineare i branch ([dettagli](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/release-3-master-into-dev.yml)) ## Release di sicurezza Le PR relative a problemi di sicurezza vengono gestite tramite [security advisory](https://github.com/DefectDojo/django-DefectDojo/security/advisories), che offrono un modo per lavorare privatamente sul codice senza divulgare prematuramente le vulnerabilità. -## Modello di release e hotfix +## Modello di release Diagrammi creati con [plantUML](https://plantuml.com). Trovi un editor web per PlantUML su https://www.planttext.com. @@ -38,7 +40,6 @@ Diagrammi creati con [plantUML](https://plantuml.com). Trovi un editor web per P @startuml participant "Dev Branch" as dev #LightBlue -participant "BugFix Branch" as bugfix #LightGreen participant "Release Branch" as release #LightGoldenRodYellow participant "Master Branch" as master #LightSalmon @@ -47,24 +48,14 @@ participant "Master Branch" as master #LightSalmon dev -> release: Create branch "release/2.x.0" release -> master: Merge note right: Official Release\n - Tag 2.x.0\n - Push 2.x.0 to DockerHub -master --> bugfix: Merge master into bugfix to realign master --> dev: Merge master back into dev -== Patch/BugFix Release (Weekly) == - -bugfix -> release: Create branch "release/2.x.y" -release -> master: Merge -note right: Official Release\n - Tag 2.x.y\n - Push 2.x.y to DockerHub -master -> bugfix: Merge master back into bugfix to realign -master --> dev: Merge master into dev to realign - -== Security Release (As Needed) == +== Patch Release (Weekly) == -master -> release: Create branch "release/2.x.y" +dev -> release: Create branch "release/2.x.y" release -> master: Merge note right: Official Release\n - Tag 2.x.y\n - Push 2.x.y to DockerHub -master --> bugfix: Merge master into bugfix to realign -master --> dev: Merge master into dev to realign +master --> dev: Merge master back into dev @enduml ``` diff --git a/docs/content/get_started/contributing/branching-model.ja.md b/docs/content/get_started/contributing/branching-model.ja.md index 82b3149ea45..567209e893c 100644 --- a/docs/content/get_started/contributing/branching-model.ja.md +++ b/docs/content/get_started/contributing/branching-model.ja.md @@ -10,23 +10,25 @@ aliases: ## 定期リリース -DefectDojoチームは、以下のケイデンスを維持することを目指しています。 +すべてのリリースは`dev`ブランチから作成されます。DefectDojoチームは、以下のケイデンスを維持することを目指しています。 - マイナーリリース: 毎月第1月曜日に少なくとも月1回。 -- パッチ/バグフィックス: 毎週月曜日にリリース。 -- セキュリティリリース: 深刻度に応じて、通常のケイデンスとは別に実施されます。 +- パッチ: 毎週月曜日にリリース。 +- セキュリティリリース: 深刻度に応じて、通常のケイデンスとは別に実施されることがあります。これも`dev`から作成されます。 -GitHub Actionsが正となります。リリースは半自動化されています。定期リリースの手順は以下のとおりです。 -1. `dev`または`bugfix`からリリースブランチを作成し、`master`に対するPRを準備します([詳細](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/new-release-pr.yml)) +バグ修正用の独立したブランチや、`master`から分岐するホットフィックスブランチはありません。バグ修正も機能追加も、すべてのプルリクエストは`dev`を対象とします。 + +GitHub Actionsが正となります。リリースは半自動化されています。リリースの手順は以下のとおりです。 +1. `dev`からリリースブランチを作成し、`master`に対するPRを準備します([詳細](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/release-1-create-pr.yml)) --> メンテナーがPRを検証し、手動でマージします -1. タグ付け、ドラフトリリースの発行、Dockerのビルド+プッシュを行います([詳細](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/new-release-tag-docker.yml)) +1. タグ付け、ドラフトリリースの発行、Dockerのビルド+プッシュを行います([詳細](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/release-2-tag-docker-push.yml)) --> メンテナーがrelease-drafterのノートを整えてリリースを公開します -1. ブランチを再整合させるため、`master`を`dev`と`bugfix`にマージし直すPRが作成されます([詳細](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/new-release-master-into-dev.yml)) +1. ブランチを再整合させるため、`master`を`dev`にマージし直すPRが作成されます([詳細](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/release-3-master-into-dev.yml)) ## セキュリティリリース セキュリティ問題に関連するPRは、[セキュリティアドバイザリ](https://github.com/DefectDojo/django-DefectDojo/security/advisories)を通じて行われます。これにより、脆弱性を早期に公開することなく非公開でコードに取り組むことができます。 -## リリースおよびホットフィックスのモデル +## リリースモデル 図は[plantUML](https://plantuml.com)で作成されています。PlantUML用のWebベースエディタはhttps://www.planttext.com で見つかります。 @@ -38,7 +40,6 @@ GitHub Actionsが正となります。リリースは半自動化されていま @startuml participant "Dev Branch" as dev #LightBlue -participant "BugFix Branch" as bugfix #LightGreen participant "Release Branch" as release #LightGoldenRodYellow participant "Master Branch" as master #LightSalmon @@ -47,24 +48,14 @@ participant "Master Branch" as master #LightSalmon dev -> release: Create branch "release/2.x.0" release -> master: Merge note right: Official Release\n - Tag 2.x.0\n - Push 2.x.0 to DockerHub -master --> bugfix: Merge master into bugfix to realign master --> dev: Merge master back into dev -== Patch/BugFix Release (Weekly) == - -bugfix -> release: Create branch "release/2.x.y" -release -> master: Merge -note right: Official Release\n - Tag 2.x.y\n - Push 2.x.y to DockerHub -master -> bugfix: Merge master back into bugfix to realign -master --> dev: Merge master into dev to realign - -== Security Release (As Needed) == +== Patch Release (Weekly) == -master -> release: Create branch "release/2.x.y" +dev -> release: Create branch "release/2.x.y" release -> master: Merge note right: Official Release\n - Tag 2.x.y\n - Push 2.x.y to DockerHub -master --> bugfix: Merge master into bugfix to realign -master --> dev: Merge master into dev to realign +master --> dev: Merge master back into dev @enduml ``` diff --git a/docs/content/get_started/contributing/branching-model.md b/docs/content/get_started/contributing/branching-model.md index 374725e3306..cc96498f4ca 100644 --- a/docs/content/get_started/contributing/branching-model.md +++ b/docs/content/get_started/contributing/branching-model.md @@ -10,23 +10,25 @@ aliases: --- ## Regular releases -The DefectDojo team aims to maintain the following cadence: +All releases come from the `dev` branch. The DefectDojo team aims to maintain the following cadence: - Minor releases: at least once a month on the first Monday of the month. -- Patch/Bugfix: releases every week on Monday. -- Security releases: will be performed outside of our regular cadence depending on severity. +- Patch releases: every week on Monday. +- Security releases: may be cut outside of our regular cadence depending on severity. They also come from `dev`. -GitHub Actions are the source of truth. The releases are semi-automated. The steps for a regular release are: -1. Create the release branch from `dev` or `bugfix` and prepare a PR against `master` ([details](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/new-release-pr.yml)) +There is no separate branch for bug fixes and no hotfix branch off `master`. Every pull request, bug fix or feature, targets `dev`. + +GitHub Actions are the source of truth. The releases are semi-automated. The steps for every release are: +1. Create the release branch from `dev` and prepare a PR against `master` ([details](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/release-1-create-pr.yml)) --> A maintainer verifies and manually merges the PR -1. Tag, issue draft release and docker build+push ([details](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/new-release-tag-docker.yml)) +1. Tag, issue draft release and docker build+push ([details](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/release-2-tag-docker-push.yml)) --> A maintainer massages the release-drafter notes and publishes the release -1. A PR to merge `master` back to `dev` and `bugfix` is created to re-align the branches ([details](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/new-release-master-into-dev.yml)) +1. A PR to merge `master` back to `dev` is created to re-align the branches ([details](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/release-3-master-into-dev.yml)) ## Security releases PRs that relate to security issues are done through [security advisories](https://github.com/DefectDojo/django-DefectDojo/security/advisories) which provide a way to work privately on code without prematurely disclosing vulnerabilities. -## Release and hotfix model +## Release model Diagrams created with [plantUML](https://plantuml.com). Find a web-based editor for PlantUML at https://www.planttext.com. @@ -38,7 +40,6 @@ Diagrams created with [plantUML](https://plantuml.com). Find a web-based editor @startuml participant "Dev Branch" as dev #LightBlue -participant "BugFix Branch" as bugfix #LightGreen participant "Release Branch" as release #LightGoldenRodYellow participant "Master Branch" as master #LightSalmon @@ -47,24 +48,14 @@ participant "Master Branch" as master #LightSalmon dev -> release: Create branch "release/2.x.0" release -> master: Merge note right: Official Release\n - Tag 2.x.0\n - Push 2.x.0 to DockerHub -master --> bugfix: Merge master into bugfix to realign master --> dev: Merge master back into dev -== Patch/BugFix Release (Weekly) == - -bugfix -> release: Create branch "release/2.x.y" -release -> master: Merge -note right: Official Release\n - Tag 2.x.y\n - Push 2.x.y to DockerHub -master -> bugfix: Merge master back into bugfix to realign -master --> dev: Merge master into dev to realign - -== Security Release (As Needed) == +== Patch Release (Weekly) == -master -> release: Create branch "release/2.x.y" +dev -> release: Create branch "release/2.x.y" release -> master: Merge note right: Official Release\n - Tag 2.x.y\n - Push 2.x.y to DockerHub -master --> bugfix: Merge master into bugfix to realign -master --> dev: Merge master into dev to realign +master --> dev: Merge master back into dev @enduml ``` diff --git a/docs/content/get_started/contributing/branching-model.pt-br.md b/docs/content/get_started/contributing/branching-model.pt-br.md index b42962a7458..cdd9229a03d 100644 --- a/docs/content/get_started/contributing/branching-model.pt-br.md +++ b/docs/content/get_started/contributing/branching-model.pt-br.md @@ -10,23 +10,25 @@ aliases: ## Releases regulares -A equipe do DefectDojo busca manter a seguinte cadência: +Todos os releases saem do branch `dev`. A equipe do DefectDojo busca manter a seguinte cadência: - Releases menores (minor): pelo menos uma vez por mês, na primeira segunda-feira do mês. -- Patch/Bugfix: releases toda semana, às segundas-feiras. -- Releases de segurança: serão realizadas fora da nossa cadência regular, dependendo da severidade. +- Patch: releases toda semana, às segundas-feiras. +- Releases de segurança: podem ser realizadas fora da nossa cadência regular, dependendo da severidade. Elas também saem de `dev`. -As GitHub Actions são a fonte da verdade. Os releases são semiautomatizados. As etapas de um release regular são: -1. Criar o branch de release a partir de `dev` ou `bugfix` e preparar um PR contra `master` ([detalhes](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/new-release-pr.yml)) +Não existe um branch separado para correções de bugs nem um branch de hotfix a partir de `master`. Todo pull request, seja correção ou funcionalidade, é direcionado a `dev`. + +As GitHub Actions são a fonte da verdade. Os releases são semiautomatizados. As etapas de cada release são: +1. Criar o branch de release a partir de `dev` e preparar um PR contra `master` ([detalhes](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/release-1-create-pr.yml)) --> Um mantenedor verifica e faz o merge manual do PR -1. Criar a tag, emitir o draft release e fazer o build+push do docker ([detalhes](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/new-release-tag-docker.yml)) +1. Criar a tag, emitir o draft release e fazer o build+push do docker ([detalhes](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/release-2-tag-docker-push.yml)) --> Um mantenedor ajusta as notas do release-drafter e publica o release -1. É criado um PR para fazer o merge de `master` de volta para `dev` e `bugfix`, realinhando os branches ([detalhes](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/new-release-master-into-dev.yml)) +1. É criado um PR para fazer o merge de `master` de volta para `dev`, realinhando os branches ([detalhes](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/release-3-master-into-dev.yml)) ## Releases de segurança PRs relacionados a questões de segurança são feitos por meio de [security advisories](https://github.com/DefectDojo/django-DefectDojo/security/advisories), que oferecem uma forma de trabalhar de modo privado no código sem divulgar prematuramente as vulnerabilidades. -## Modelo de release e hotfix +## Modelo de release Diagramas criados com [plantUML](https://plantuml.com). Encontre um editor web para PlantUML em https://www.planttext.com. @@ -38,7 +40,6 @@ Diagramas criados com [plantUML](https://plantuml.com). Encontre um editor web p @startuml participant "Dev Branch" as dev #LightBlue -participant "BugFix Branch" as bugfix #LightGreen participant "Release Branch" as release #LightGoldenRodYellow participant "Master Branch" as master #LightSalmon @@ -47,24 +48,14 @@ participant "Master Branch" as master #LightSalmon dev -> release: Create branch "release/2.x.0" release -> master: Merge note right: Official Release\n - Tag 2.x.0\n - Push 2.x.0 to DockerHub -master --> bugfix: Merge master into bugfix to realign master --> dev: Merge master back into dev -== Patch/BugFix Release (Weekly) == - -bugfix -> release: Create branch "release/2.x.y" -release -> master: Merge -note right: Official Release\n - Tag 2.x.y\n - Push 2.x.y to DockerHub -master -> bugfix: Merge master back into bugfix to realign -master --> dev: Merge master into dev to realign - -== Security Release (As Needed) == +== Patch Release (Weekly) == -master -> release: Create branch "release/2.x.y" +dev -> release: Create branch "release/2.x.y" release -> master: Merge note right: Official Release\n - Tag 2.x.y\n - Push 2.x.y to DockerHub -master --> bugfix: Merge master into bugfix to realign -master --> dev: Merge master into dev to realign +master --> dev: Merge master back into dev @enduml ``` diff --git a/docs/content/get_started/contributing/branching-model.zh-hans.md b/docs/content/get_started/contributing/branching-model.zh-hans.md index e73849a3ebb..2b4ebbab3b0 100644 --- a/docs/content/get_started/contributing/branching-model.zh-hans.md +++ b/docs/content/get_started/contributing/branching-model.zh-hans.md @@ -10,23 +10,25 @@ aliases: ## 常规发布 -DefectDojo 团队致力于保持以下发布节奏： +所有版本都从 `dev` 分支发布。DefectDojo 团队致力于保持以下发布节奏： - 次要版本（Minor）：每月至少一次，于每月的第一个星期一发布。 -- 补丁/缺陷修复（Patch/Bugfix）：每周一发布。 -- 安全发布（Security）：根据严重程度，在常规节奏之外发布。 +- 补丁（Patch）：每周一发布。 +- 安全发布（Security）：可能根据严重程度在常规节奏之外发布，同样从 `dev` 发布。 -GitHub Actions 是权威依据。发布流程是半自动化的。常规发布的步骤如下： -1. 从 `dev` 或 `bugfix` 创建发布分支，并准备一个针对 `master` 的 PR（[详情](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/new-release-pr.yml)） +没有单独的缺陷修复分支，也没有从 `master` 分出的热修复分支。所有 PR，无论是缺陷修复还是新功能，都以 `dev` 为目标分支。 + +GitHub Actions 是权威依据。发布流程是半自动化的。每次发布的步骤如下： +1. 从 `dev` 创建发布分支，并准备一个针对 `master` 的 PR（[详情](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/release-1-create-pr.yml)） --> 维护者验证并手动合并该 PR -1. 打标签、发布草稿版本并构建/推送 Docker 镜像（[详情](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/new-release-tag-docker.yml)） +1. 打标签、发布草稿版本并构建/推送 Docker 镜像（[详情](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/release-2-tag-docker-push.yml)） --> 维护者整理 release-drafter 生成的发布说明并发布该版本 -1. 创建一个将 `master` 合并回 `dev` 和 `bugfix` 的 PR，以重新对齐各分支（[详情](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/new-release-master-into-dev.yml)） +1. 创建一个将 `master` 合并回 `dev` 的 PR，以重新对齐各分支（[详情](https://github.com/DefectDojo/django-DefectDojo/blob/master/.github/workflows/release-3-master-into-dev.yml)） ## 安全发布 与安全问题相关的 PR 通过[安全公告](https://github.com/DefectDojo/django-DefectDojo/security/advisories)完成，该机制可让团队私下处理代码，而不会过早披露漏洞。 -## 发布与热修复模型 +## 发布模型 图表使用 [plantUML](https://plantuml.com) 创建。可在 https://www.planttext.com 找到基于网页的 PlantUML 编辑器。 @@ -38,7 +40,6 @@ GitHub Actions 是权威依据。发布流程是半自动化的。常规发布 @startuml participant "Dev Branch" as dev #LightBlue -participant "BugFix Branch" as bugfix #LightGreen participant "Release Branch" as release #LightGoldenRodYellow participant "Master Branch" as master #LightSalmon @@ -47,24 +48,14 @@ participant "Master Branch" as master #LightSalmon dev -> release: Create branch "release/2.x.0" release -> master: Merge note right: Official Release\n - Tag 2.x.0\n - Push 2.x.0 to DockerHub -master --> bugfix: Merge master into bugfix to realign master --> dev: Merge master back into dev -== Patch/BugFix Release (Weekly) == - -bugfix -> release: Create branch "release/2.x.y" -release -> master: Merge -note right: Official Release\n - Tag 2.x.y\n - Push 2.x.y to DockerHub -master -> bugfix: Merge master back into bugfix to realign -master --> dev: Merge master into dev to realign - -== Security Release (As Needed) == +== Patch Release (Weekly) == -master -> release: Create branch "release/2.x.y" +dev -> release: Create branch "release/2.x.y" release -> master: Merge note right: Official Release\n - Tag 2.x.y\n - Push 2.x.y to DockerHub -master --> bugfix: Merge master into bugfix to realign -master --> dev: Merge master into dev to realign +master --> dev: Merge master back into dev @enduml ``` diff --git a/readme-docs/CONTRIBUTING.md b/readme-docs/CONTRIBUTING.md index 39992f7f772..e1a5e1b59b3 100644 --- a/readme-docs/CONTRIBUTING.md +++ b/readme-docs/CONTRIBUTING.md @@ -101,7 +101,7 @@ If you encounter a conflict in `dojo/db_migrations/max_migration.txt` during a r The following are things to consider before submitting a pull request to DefectDojo. -0. Base your PR against the `dev` or `bugfix` branch, unless discussed otherwise with the maintainers +0. Base your PR against the `dev` branch, unless discussed otherwise with the maintainers 0. Make sure that the install is working properly. @@ -111,7 +111,7 @@ DefectDojo. 0. See [flake8 built-in commit hooks] on how to easily check for for pep8 with flake8 before comitting. -0. Pull requests should be submitted to the `dev` or `bugfix` branch. +0. Pull requests should be submitted to the `dev` branch. Bug fixes and features both go there. 0. In dev branch, the code should be python 3.13 compliant. diff --git a/readme-docs/RELEASING.md b/readme-docs/RELEASING.md index c1b7d94ef79..0fcd3a30bdc 100644 --- a/readme-docs/RELEASING.md +++ b/readme-docs/RELEASING.md @@ -2,42 +2,26 @@ ### Summary -We have two types of releases: +Every release is cut from the `dev` branch. There are two kinds, and they follow the same procedure: -1. **Feature releases** - These are monthly releases created from the `dev` branch, via a new release branch, i.e. `release/x.y.z`. -2. **Bugfix releases** - These are weekly created from the `bugfix` branch, via a new release branch, i.e. `release/x.y.z`. +1. **Monthly minor releases** (`x.y.0`) +2. **Weekly patch releases** (`x.y.100`, `x.y.200`, ...) -Dependency updates and security patches go into the monthly releases. Urgent crirtical security patches will go into the bugfix releases. +The release schedule decides which one is next. Dependency updates, bug fixes and security patches, urgent ones included, go into the next release from `dev`. There is no separate branch for bug fixes and no hotfix branch off `master`. The release process will then: -- Create a PR to merge that release branch into `master` -- Tag the release, Build the dockers images and Push them to Docker Hub -- Merge the changes in `master` "back into dev" to make sure `dev` and `bugfix` is in sync again with `master` +- Create a `release/x.y.z` branch from `dev` and a PR to merge it into `master` (`Release-1`) +- Tag the release, build the docker images and push them to Docker Hub (`Release-2`) +- Merge the changes in `master` back into `dev` so the two stay in sync (`Release-3`) -The steps are identical for both release types, unless specified otherwise below. +# Before you start -# Creating and preparing the release branch - -### Feature release -- Make sure the `dev` branch contains exactly that what you want to release. -- Create a new release branch from the `dev` branch: - -![image](https://user-images.githubusercontent.com/4426050/149572033-49a6c2a7-6c5b-4272-84e5-040c661598b4.png) - -### Bugfix release -- Create a new branch from `master` which will receive the bugfix PRs for the release, i.e. `release/x.y.z`. - -![image](https://user-images.githubusercontent.com/4426050/149616927-d26b3812-f5ce-4bd3-a196-a72293dd9377.png) - -- Create bugfix PRs against the new release branch: -- Merge the PRs - -### Always +- Make sure the `dev` branch contains exactly what you want to release. - Make sure there's a section in [os_upgrading](../docs/content/releases/os_upgrading) about any specific instructions when upgrading to this new release. - Remove existing draft releases with the same version number -Due to the release drafter being a non-perfect match for our git flow based release process, we have to delete any draft that has already been created by the release drafter if it has the same versio number. This is probably not needed if you're doing a bugfix release. +The release drafter is not a perfect match for our release process, so delete any draft it has already created with the same version number. - Go to [Releases](https://github.com/DefectDojo/django-DefectDojo/releases) and delete any draft release that has the same version number as the release you are planning to release today. @@ -49,10 +33,12 @@ If you do not delete any existing draft release, you will end up with multiple d # Creating the PR to merge into `master` -Run the `Release-1: Create PR for master` action: +Run the `Release-1: Create PR for master` action. Leave `from_branch` on `dev` (the only option) and enter the release version: `x.y.0` for a minor release, `x.y.100` / `x.y.200` / ... for a patch release. ![image](https://user-images.githubusercontent.com/4426050/149574288-a4056fb9-859c-413e-9f60-bc59894b0528.png) +The action creates the `release/x.y.z` branch from `dev`, updates the version numbers in it, removes the `-dev` suffix from the helm chart version, and opens the PR against `master`. + Verify the PR is created, and check if the commits in it make sense: ![image](https://user-images.githubusercontent.com/4426050/149576847-df4d8347-af08-49dc-ab21-ad19ea37b3cd.png) @@ -66,13 +52,13 @@ Go to the bottom of the lists of commits, click on the `Update versions in appli ![image](https://user-images.githubusercontent.com/4426050/149577123-572cc6dd-7bf3-44ad-af58-ab6e46905558.png) -Ideally we wait until the test suite becomes green. If you're feeling brace, you can skip the waiting and instead wait for the tests to become green after merging into `master`. +Ideally we wait until the test suite becomes green. If you're feeling brave, you can skip the waiting and instead wait for the tests to become green after merging into `master`. Merge into `master` by *creating a merge commit*. Do NOT squash the commits! ![image](https://user-images.githubusercontent.com/4426050/149577269-d51fe1ee-ba0d-4a9b-94e7-ec286954b5e2.png) -Go to [GitHub Actions](https://github.com/DefectDojo/django-DefectDojo/actions) and pray for them to become green. +Go to [GitHub Actions](https://github.com/DefectDojo/django-DefectDojo/actions) and check that the runs become green. # Make the release and push docker images @@ -105,17 +91,17 @@ Verify the results: # Bring `dev` in sync with `master` -To avoid merge conflicts and drigts between branches, we have to get `dev` back into sync with `master`. This step also bumps the version numbers if needed. +To avoid merge conflicts and drift between branches, we have to get `dev` back into sync with `master`. This step also sets `dev` to the version of the next scheduled release, with a `-dev` suffix. -Run the `Release-3: PR for merging master into dev` action. +Run the `Release-3: PR for merging master into dev` action. Enter the version you just released and the next version for `dev` (`x.y.z-dev`). ![image](https://user-images.githubusercontent.com/4426050/149618563-05707161-7111-4ba9-ad18-6239f66c3aa5.png) -Check the PR and versio number updates. For a fix version problably the version numbers are already correct on `dev`. +Check the PR and the version number updates. ![image](https://user-images.githubusercontent.com/4426050/149618605-fd94b6a8-d348-4fc5-8eaf-92f23b1b54b7.png) -Wait for the tests to complete. +Wait for the tests to complete. You can work on the release notes in the next step while waiting. @@ -132,32 +118,11 @@ Because we have merged the release PR into master, the release draft has been tr ![image](https://user-images.githubusercontent.com/4426050/149619614-728736a4-e58f-4792-9b27-ead24ec07fc4.png) -### Bugfix releases -For bugfix releases the release drafter generates the correct release notes. These will contain the merged PRs since the previous release. +Every release comes from `dev`, so the previous release is the right starting point for the notes: they list the PRs merged since then. ![image](https://user-images.githubusercontent.com/4426050/149619779-1d065baf-be09-41b7-a54c-b2676948a6cb.png) - -### Feature releases -For features releases the release drafter will mess up if the **previous release was a bugfix release**. If the previous release was a feature release (x.y.0), the release notes will be generated correctly. - -For when the previous release was a bugfix release, i.e. 2.6.2: - -The release drafter does not look at releases or tags or branches. It just looks as the _date_ of the previous release and it will list all PRs merged since that date. So it will list all PRs merged since for example 2.6.2. This might miss PRs that have been merged _into dev_ between the release date of 2.6.0 and 2.6.2. To correct that, we have a fork of the release drafter that allows you to specify which release to use as the previous release. In this case we want all PRs listed that have been merged since 2.6.0. - -Run the `Release Drafter Valentijn` and specify the desired previous (feature) release to use: - -![image](https://user-images.githubusercontent.com/4426050/149619852-dc1dad77-b7b6-479d-8d9f-4ac1571ea92c.png) - -Output: - -![image](https://user-images.githubusercontent.com/4426050/149619893-3f8ce398-aec2-467e-bb66-e8efc8dc66d6.png) - -Release notes: - -![image](https://user-images.githubusercontent.com/4426050/149619906-f80b805a-67b2-4b3b-9ffb-8edfcf4b7e16.png) - -A tiny downside of this is that it will also lists PRs releases in 2.6.1 and 2.6.2, but I think that is acceptable. +If the notes need to start from a different release, run the `Release Drafter (custom range)` action and set `filter-by-range` to that release, e.g. `3.1.0`. Use `dry-run` first to confirm where the changeset starts. As a finishing touch make sure the emoji in the release name is present. We have special emoji for security releases, see a previous security release: From 0aa784fbca8978d29f4c8ad774944d7b9febebb9 Mon Sep 17 00:00:00 2001 From: Cody Maffucci <46459665+Maffooch@users.noreply.github.com> Date: Thu, 24 Sep 2026 23:27:27 -0600 Subject: [PATCH 2/3] ci: skip CI on release PRs and merge-backs Release PRs (release/) and merge-backs (master-into-dev/-) are merged as soon as they are conflict-free, without waiting for CI. Guard the root jobs of the test, lint and verification workflows so they skip on those PRs when the release-management label is present, and on pushes of such branches or of GitHub's merge commit for such a PR. Unit Tests Complete skips with them instead of reporting a failure. RELEASING.md drops the "wait for the tests" steps. Co-Authored-By: Claude Opus 5.5 --- .github/workflows/detect-merge-conflicts.yaml | 3 +++ .github/workflows/migration-graph.yml | 9 +++++++++ .github/workflows/renovate.yaml | 3 +++ .github/workflows/ruff.yml | 9 +++++++++ .github/workflows/shellcheck.yml | 3 +++ .github/workflows/test-helm-chart.yml | 15 +++++++++++++++ .github/workflows/unit-tests.yml | 11 ++++++++++- .github/workflows/validate_docs_build.yml | 3 +++ readme-docs/RELEASING.md | 8 ++------ 9 files changed, 57 insertions(+), 7 deletions(-) diff --git a/.github/workflows/detect-merge-conflicts.yaml b/.github/workflows/detect-merge-conflicts.yaml index e1595d83bb1..52ed7593b60 100644 --- a/.github/workflows/detect-merge-conflicts.yaml +++ b/.github/workflows/detect-merge-conflicts.yaml @@ -12,6 +12,9 @@ on: jobs: main: + # Release PRs and merge-backs are merged without waiting for CI. Skip when the + # head is release/* or master-into-dev/* AND the PR has release-management. + if: ${{ !((startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) }} runs-on: ubuntu-latest steps: - name: check if prs are conflicted diff --git a/.github/workflows/migration-graph.yml b/.github/workflows/migration-graph.yml index 6eb4f1835ad..6d6108ec6d0 100644 --- a/.github/workflows/migration-graph.yml +++ b/.github/workflows/migration-graph.yml @@ -38,6 +38,15 @@ on: jobs: migration-graph: + # Release PRs and merge-backs are merged without waiting for CI. PR: a + # release/* or master-into-dev/* head AND the release-management label. + # Push: such a branch, or GitHub's merge commit for such a PR (a push has + # no labels, so the branch name is the only signal). + if: >- + ${{ !( + (startsWith(github.event_name, 'pull_request') && (startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) + || (github.event_name == 'push' && (startsWith(github.ref_name, 'release/') || startsWith(github.ref_name, 'master-into-dev/') || (startsWith(github.event.head_commit.message, 'Merge pull request') && (contains(github.event.head_commit.message, '/release/') || contains(github.event.head_commit.message, '/master-into-dev/'))))) + ) }} name: Migration Graph Check runs-on: ubuntu-latest steps: diff --git a/.github/workflows/renovate.yaml b/.github/workflows/renovate.yaml index 7c6537de596..92cbdc0a118 100644 --- a/.github/workflows/renovate.yaml +++ b/.github/workflows/renovate.yaml @@ -9,6 +9,9 @@ on: jobs: main: + # Release PRs and merge-backs are merged without waiting for CI. Skip when the + # head is release/* or master-into-dev/* AND the PR has release-management. + if: ${{ !((startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) }} runs-on: ubuntu-latest steps: - name: Checkout diff --git a/.github/workflows/ruff.yml b/.github/workflows/ruff.yml index aa5fc8631a7..9c92cac282e 100644 --- a/.github/workflows/ruff.yml +++ b/.github/workflows/ruff.yml @@ -26,6 +26,15 @@ on: merge_group: jobs: ruff-linting: + # Release PRs and merge-backs are merged without waiting for CI. PR: a + # release/* or master-into-dev/* head AND the release-management label. + # Push: such a branch, or GitHub's merge commit for such a PR (a push has + # no labels, so the branch name is the only signal). + if: >- + ${{ !( + (startsWith(github.event_name, 'pull_request') && (startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) + || (github.event_name == 'push' && (startsWith(github.ref_name, 'release/') || startsWith(github.ref_name, 'master-into-dev/') || (startsWith(github.event.head_commit.message, 'Merge pull request') && (contains(github.event.head_commit.message, '/release/') || contains(github.event.head_commit.message, '/master-into-dev/'))))) + ) }} runs-on: ubuntu-latest steps: - name: Checkout diff --git a/.github/workflows/shellcheck.yml b/.github/workflows/shellcheck.yml index 691697fe902..b57b406de85 100644 --- a/.github/workflows/shellcheck.yml +++ b/.github/workflows/shellcheck.yml @@ -5,6 +5,9 @@ on: jobs: shellcheck: + # Release PRs and merge-backs are merged without waiting for CI. Skip when the + # head is release/* or master-into-dev/* AND the PR has release-management. + if: ${{ !((startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) }} runs-on: ubuntu-latest steps: - name: Checkout diff --git a/.github/workflows/test-helm-chart.yml b/.github/workflows/test-helm-chart.yml index 07c757a2c07..16fc28467e1 100644 --- a/.github/workflows/test-helm-chart.yml +++ b/.github/workflows/test-helm-chart.yml @@ -12,6 +12,9 @@ permissions: jobs: lint: + # Release PRs and merge-backs are merged without waiting for CI. Skip when the + # head is release/* or master-into-dev/* AND the PR has release-management. + if: ${{ !((startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) }} name: Lint chart (version) runs-on: ubuntu-latest steps: @@ -109,6 +112,9 @@ jobs: # if: steps.list_changed.outputs.changed == 'true' docs_generation: + # Release PRs and merge-backs are merged without waiting for CI. Skip when the + # head is release/* or master-into-dev/* AND the PR has release-management. + if: ${{ !((startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) }} name: Update documentation runs-on: ubuntu-latest permissions: @@ -152,6 +158,9 @@ jobs: echo "Your HELM chart changed but you haven't adjusted documentation. Check https://github.com/defectdojo/django-DefectDojo/tree/master/helm/defectdojo#helm-docs-update for more information." generate_schema: + # Release PRs and merge-backs are merged without waiting for CI. Skip when the + # head is release/* or master-into-dev/* AND the PR has release-management. + if: ${{ !((startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) }} name: Update schema runs-on: ubuntu-latest steps: @@ -172,6 +181,9 @@ jobs: echo "Your HELM chart changed but you haven't adjusted schema. Check https://github.com/defectdojo/django-DefectDojo/tree/master/helm/defectdojo#helm-schema-update for more information." lint_format: + # Release PRs and merge-backs are merged without waiting for CI. Skip when the + # head is release/* or master-into-dev/* AND the PR has release-management. + if: ${{ !((startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) }} name: Lint chart (format) runs-on: ubuntu-latest steps: @@ -194,6 +206,9 @@ jobs: helm lint ./helm/defectdojo --strict artifacthub_linter: + # Release PRs and merge-backs are merged without waiting for CI. Skip when the + # head is release/* or master-into-dev/* AND the PR has release-management. + if: ${{ !((startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) }} name: Artifacthub Lint runs-on: ubuntu-latest steps: diff --git a/.github/workflows/unit-tests.yml b/.github/workflows/unit-tests.yml index 8043a3472a8..8cbbc61983e 100644 --- a/.github/workflows/unit-tests.yml +++ b/.github/workflows/unit-tests.yml @@ -43,6 +43,9 @@ on: jobs: # hard gate: linting must pass before we spend any time building images or running tests ruff: + # Release PRs and merge-backs are merged without waiting for CI. Skip when the + # head is release/* or master-into-dev/* AND the PR has release-management. + if: ${{ !((startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) }} uses: ./.github/workflows/ruff.yml secrets: inherit @@ -52,6 +55,9 @@ jobs: # output stays empty, and every `!= 'true'` guard runs the full suite -- the # queue always tests the complete matrix on the speculative merge commit. changes: + # Release PRs and merge-backs are merged without waiting for CI. Skip when the + # head is release/* or master-into-dev/* AND the PR has release-management. + if: ${{ !((startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) }} runs-on: ubuntu-latest outputs: docs_only: ${{ steps.filter.outputs.docs_only }} @@ -153,7 +159,10 @@ jobs: # always() so this still reports when something upstream fails -- without it # the job would be skipped, and a skipped required check blocks the queue # instead of failing it. - if: always() + # `changes` is skipped only by the release guard above. Skip this job too, + # so a release PR does not report a failure. Release PRs are admin-merged, + # so the skipped required check does not block them. + if: ${{ always() && needs.changes.result != 'skipped' }} needs: - changes - ruff diff --git a/.github/workflows/validate_docs_build.yml b/.github/workflows/validate_docs_build.yml index cacdf51f4cd..2a2fca2b8da 100644 --- a/.github/workflows/validate_docs_build.yml +++ b/.github/workflows/validate_docs_build.yml @@ -8,6 +8,9 @@ on: jobs: deploy: + # Release PRs and merge-backs are merged without waiting for CI. Skip when the + # head is release/* or master-into-dev/* AND the PR has release-management. + if: ${{ !((startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) }} runs-on: ubuntu-latest steps: - name: Setup Hugo diff --git a/readme-docs/RELEASING.md b/readme-docs/RELEASING.md index 0fcd3a30bdc..e1bead2f9b5 100644 --- a/readme-docs/RELEASING.md +++ b/readme-docs/RELEASING.md @@ -52,14 +52,12 @@ Go to the bottom of the lists of commits, click on the `Update versions in appli ![image](https://user-images.githubusercontent.com/4426050/149577123-572cc6dd-7bf3-44ad-af58-ab6e46905558.png) -Ideally we wait until the test suite becomes green. If you're feeling brave, you can skip the waiting and instead wait for the tests to become green after merging into `master`. +Do not wait for CI. The release PR and the merge-back PR are merged as soon as they are conflict-free, to save time and runner cost. CI skips them on purpose: a pull request is skipped when its head branch starts with `release/` or `master-into-dev/` and it has the `release-management` label (both release actions add it), and a push is skipped when the branch has one of those prefixes or the commit is GitHub's merge commit for such a PR. Merge into `master` by *creating a merge commit*. Do NOT squash the commits! ![image](https://user-images.githubusercontent.com/4426050/149577269-d51fe1ee-ba0d-4a9b-94e7-ec286954b5e2.png) -Go to [GitHub Actions](https://github.com/DefectDojo/django-DefectDojo/actions) and check that the runs become green. - # Make the release and push docker images Run the `Release-2: Tag, Release, Push` action: @@ -101,9 +99,7 @@ Check the PR and the version number updates. ![image](https://user-images.githubusercontent.com/4426050/149618605-fd94b6a8-d348-4fc5-8eaf-92f23b1b54b7.png) -Wait for the tests to complete. - -You can work on the release notes in the next step while waiting. +No tests run on this PR (see above), so merge it as soon as it is conflict-free. Merge the `Release: Merge back x.y.z into dev from: master-into-dev/x.y.z-a.b.c-dev` PR by using a *Merge Commit*. Do NOT squash the commits. From 1d183cf8c7c0c8b58752f1767207aa5543ab9786 Mon Sep 17 00:00:00 2001 From: Cody Maffucci <46459665+Maffooch@users.noreply.github.com> Date: Thu, 24 Sep 2026 23:51:12 -0600 Subject: [PATCH 3/3] ci(release): name release branches release/merge-* like the other repos The release PR head is now release/merge-dev-into-master- (was release/) and the merge-back head is release/merge-master-into-dev- (was master-into-dev/-). The version suffix keeps each release's branches unique. CI now skips on the same rule as the other DefectDojo repositories: a pull request whose head starts with release/merge- AND that has the release-management label, or on push a release/merge-* branch or GitHub's merge commit for such a PR. RELEASING.md and the branching-model pages use the new names. Co-Authored-By: Claude Opus 5.5 --- .github/workflows/detect-merge-conflicts.yaml | 4 ++-- .github/workflows/migration-graph.yml | 6 ++--- .github/workflows/release-1-create-pr.yml | 2 +- .../workflows/release-3-master-into-dev.yml | 2 +- .github/workflows/renovate.yaml | 4 ++-- .github/workflows/ruff.yml | 6 ++--- .github/workflows/shellcheck.yml | 4 ++-- .github/workflows/test-helm-chart.yml | 22 +++++++++---------- .github/workflows/unit-tests.yml | 8 +++---- .github/workflows/validate_docs_build.yml | 4 ++-- .../contributing/branching-model.de.md | 4 ++-- .../contributing/branching-model.es.md | 4 ++-- .../contributing/branching-model.fr.md | 4 ++-- .../contributing/branching-model.it.md | 4 ++-- .../contributing/branching-model.ja.md | 4 ++-- .../contributing/branching-model.md | 4 ++-- .../contributing/branching-model.pt-br.md | 4 ++-- .../contributing/branching-model.zh-hans.md | 4 ++-- readme-docs/RELEASING.md | 8 +++---- 19 files changed, 51 insertions(+), 51 deletions(-) diff --git a/.github/workflows/detect-merge-conflicts.yaml b/.github/workflows/detect-merge-conflicts.yaml index 52ed7593b60..2c6330ea64d 100644 --- a/.github/workflows/detect-merge-conflicts.yaml +++ b/.github/workflows/detect-merge-conflicts.yaml @@ -13,8 +13,8 @@ on: jobs: main: # Release PRs and merge-backs are merged without waiting for CI. Skip when the - # head is release/* or master-into-dev/* AND the PR has release-management. - if: ${{ !((startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) }} + # head is release/merge-* AND the PR has release-management. + if: ${{ !(startsWith(github.head_ref, 'release/merge-') && contains(github.event.pull_request.labels.*.name, 'release-management')) }} runs-on: ubuntu-latest steps: - name: check if prs are conflicted diff --git a/.github/workflows/migration-graph.yml b/.github/workflows/migration-graph.yml index 6d6108ec6d0..be6f651f509 100644 --- a/.github/workflows/migration-graph.yml +++ b/.github/workflows/migration-graph.yml @@ -39,13 +39,13 @@ on: jobs: migration-graph: # Release PRs and merge-backs are merged without waiting for CI. PR: a - # release/* or master-into-dev/* head AND the release-management label. + # release/merge-* head AND the release-management label. # Push: such a branch, or GitHub's merge commit for such a PR (a push has # no labels, so the branch name is the only signal). if: >- ${{ !( - (startsWith(github.event_name, 'pull_request') && (startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) - || (github.event_name == 'push' && (startsWith(github.ref_name, 'release/') || startsWith(github.ref_name, 'master-into-dev/') || (startsWith(github.event.head_commit.message, 'Merge pull request') && (contains(github.event.head_commit.message, '/release/') || contains(github.event.head_commit.message, '/master-into-dev/'))))) + (startsWith(github.event_name, 'pull_request') && startsWith(github.head_ref, 'release/merge-') && contains(github.event.pull_request.labels.*.name, 'release-management')) + || (github.event_name == 'push' && (startsWith(github.ref_name, 'release/merge-') || (startsWith(github.event.head_commit.message, 'Merge pull request') && contains(github.event.head_commit.message, '/release/merge-')))) ) }} name: Migration Graph Check runs-on: ubuntu-latest diff --git a/.github/workflows/release-1-create-pr.yml b/.github/workflows/release-1-create-pr.yml index 554c0e4009e..c641ac5b874 100644 --- a/.github/workflows/release-1-create-pr.yml +++ b/.github/workflows/release-1-create-pr.yml @@ -39,7 +39,7 @@ jobs: - name: Create release branch run: | - echo "NEW_BRANCH=release/${{ inputs.release_number }}" >> $GITHUB_ENV + echo "NEW_BRANCH=release/merge-dev-into-master-${{ inputs.release_number }}" >> $GITHUB_ENV - name: Configure git run: | diff --git a/.github/workflows/release-3-master-into-dev.yml b/.github/workflows/release-3-master-into-dev.yml index a3521d18a33..2e3dd4c0794 100644 --- a/.github/workflows/release-3-master-into-dev.yml +++ b/.github/workflows/release-3-master-into-dev.yml @@ -29,7 +29,7 @@ jobs: - name: Create merge back branch run: | - echo "NEW_BRANCH=master-into-dev/${{ inputs.release_number_new }}-${{ inputs.release_number_dev }}" >> $GITHUB_ENV + echo "NEW_BRANCH=release/merge-master-into-dev-${{ inputs.release_number_new }}" >> $GITHUB_ENV - name: Configure git run: | diff --git a/.github/workflows/renovate.yaml b/.github/workflows/renovate.yaml index 92cbdc0a118..a696ed16251 100644 --- a/.github/workflows/renovate.yaml +++ b/.github/workflows/renovate.yaml @@ -10,8 +10,8 @@ on: jobs: main: # Release PRs and merge-backs are merged without waiting for CI. Skip when the - # head is release/* or master-into-dev/* AND the PR has release-management. - if: ${{ !((startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) }} + # head is release/merge-* AND the PR has release-management. + if: ${{ !(startsWith(github.head_ref, 'release/merge-') && contains(github.event.pull_request.labels.*.name, 'release-management')) }} runs-on: ubuntu-latest steps: - name: Checkout diff --git a/.github/workflows/ruff.yml b/.github/workflows/ruff.yml index 9c92cac282e..6caad137545 100644 --- a/.github/workflows/ruff.yml +++ b/.github/workflows/ruff.yml @@ -27,13 +27,13 @@ on: jobs: ruff-linting: # Release PRs and merge-backs are merged without waiting for CI. PR: a - # release/* or master-into-dev/* head AND the release-management label. + # release/merge-* head AND the release-management label. # Push: such a branch, or GitHub's merge commit for such a PR (a push has # no labels, so the branch name is the only signal). if: >- ${{ !( - (startsWith(github.event_name, 'pull_request') && (startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) - || (github.event_name == 'push' && (startsWith(github.ref_name, 'release/') || startsWith(github.ref_name, 'master-into-dev/') || (startsWith(github.event.head_commit.message, 'Merge pull request') && (contains(github.event.head_commit.message, '/release/') || contains(github.event.head_commit.message, '/master-into-dev/'))))) + (startsWith(github.event_name, 'pull_request') && startsWith(github.head_ref, 'release/merge-') && contains(github.event.pull_request.labels.*.name, 'release-management')) + || (github.event_name == 'push' && (startsWith(github.ref_name, 'release/merge-') || (startsWith(github.event.head_commit.message, 'Merge pull request') && contains(github.event.head_commit.message, '/release/merge-')))) ) }} runs-on: ubuntu-latest steps: diff --git a/.github/workflows/shellcheck.yml b/.github/workflows/shellcheck.yml index b57b406de85..d81c02c3c2d 100644 --- a/.github/workflows/shellcheck.yml +++ b/.github/workflows/shellcheck.yml @@ -6,8 +6,8 @@ on: jobs: shellcheck: # Release PRs and merge-backs are merged without waiting for CI. Skip when the - # head is release/* or master-into-dev/* AND the PR has release-management. - if: ${{ !((startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) }} + # head is release/merge-* AND the PR has release-management. + if: ${{ !(startsWith(github.head_ref, 'release/merge-') && contains(github.event.pull_request.labels.*.name, 'release-management')) }} runs-on: ubuntu-latest steps: - name: Checkout diff --git a/.github/workflows/test-helm-chart.yml b/.github/workflows/test-helm-chart.yml index 16fc28467e1..58132b9042d 100644 --- a/.github/workflows/test-helm-chart.yml +++ b/.github/workflows/test-helm-chart.yml @@ -13,8 +13,8 @@ permissions: jobs: lint: # Release PRs and merge-backs are merged without waiting for CI. Skip when the - # head is release/* or master-into-dev/* AND the PR has release-management. - if: ${{ !((startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) }} + # head is release/merge-* AND the PR has release-management. + if: ${{ !(startsWith(github.head_ref, 'release/merge-') && contains(github.event.pull_request.labels.*.name, 'release-management')) }} name: Lint chart (version) runs-on: ubuntu-latest steps: @@ -76,7 +76,7 @@ jobs: if: steps.list_changed.outputs.changed == 'true' - name: Check update of "artifacthub.io/changes" HELM annotation - if: ${{ steps.list_changed.outputs.changed == 'true' && !startsWith(github.head_ref, 'master-into-dev/') }} + if: ${{ steps.list_changed.outputs.changed == 'true' && !startsWith(github.head_ref, 'release/merge-master-into-dev-') }} run: | # fast fail if `git show` fails set -e @@ -113,8 +113,8 @@ jobs: docs_generation: # Release PRs and merge-backs are merged without waiting for CI. Skip when the - # head is release/* or master-into-dev/* AND the PR has release-management. - if: ${{ !((startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) }} + # head is release/merge-* AND the PR has release-management. + if: ${{ !(startsWith(github.head_ref, 'release/merge-') && contains(github.event.pull_request.labels.*.name, 'release-management')) }} name: Update documentation runs-on: ubuntu-latest permissions: @@ -159,8 +159,8 @@ jobs: generate_schema: # Release PRs and merge-backs are merged without waiting for CI. Skip when the - # head is release/* or master-into-dev/* AND the PR has release-management. - if: ${{ !((startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) }} + # head is release/merge-* AND the PR has release-management. + if: ${{ !(startsWith(github.head_ref, 'release/merge-') && contains(github.event.pull_request.labels.*.name, 'release-management')) }} name: Update schema runs-on: ubuntu-latest steps: @@ -182,8 +182,8 @@ jobs: lint_format: # Release PRs and merge-backs are merged without waiting for CI. Skip when the - # head is release/* or master-into-dev/* AND the PR has release-management. - if: ${{ !((startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) }} + # head is release/merge-* AND the PR has release-management. + if: ${{ !(startsWith(github.head_ref, 'release/merge-') && contains(github.event.pull_request.labels.*.name, 'release-management')) }} name: Lint chart (format) runs-on: ubuntu-latest steps: @@ -207,8 +207,8 @@ jobs: artifacthub_linter: # Release PRs and merge-backs are merged without waiting for CI. Skip when the - # head is release/* or master-into-dev/* AND the PR has release-management. - if: ${{ !((startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) }} + # head is release/merge-* AND the PR has release-management. + if: ${{ !(startsWith(github.head_ref, 'release/merge-') && contains(github.event.pull_request.labels.*.name, 'release-management')) }} name: Artifacthub Lint runs-on: ubuntu-latest steps: diff --git a/.github/workflows/unit-tests.yml b/.github/workflows/unit-tests.yml index 8cbbc61983e..e6dc411d950 100644 --- a/.github/workflows/unit-tests.yml +++ b/.github/workflows/unit-tests.yml @@ -44,8 +44,8 @@ jobs: # hard gate: linting must pass before we spend any time building images or running tests ruff: # Release PRs and merge-backs are merged without waiting for CI. Skip when the - # head is release/* or master-into-dev/* AND the PR has release-management. - if: ${{ !((startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) }} + # head is release/merge-* AND the PR has release-management. + if: ${{ !(startsWith(github.head_ref, 'release/merge-') && contains(github.event.pull_request.labels.*.name, 'release-management')) }} uses: ./.github/workflows/ruff.yml secrets: inherit @@ -56,8 +56,8 @@ jobs: # queue always tests the complete matrix on the speculative merge commit. changes: # Release PRs and merge-backs are merged without waiting for CI. Skip when the - # head is release/* or master-into-dev/* AND the PR has release-management. - if: ${{ !((startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) }} + # head is release/merge-* AND the PR has release-management. + if: ${{ !(startsWith(github.head_ref, 'release/merge-') && contains(github.event.pull_request.labels.*.name, 'release-management')) }} runs-on: ubuntu-latest outputs: docs_only: ${{ steps.filter.outputs.docs_only }} diff --git a/.github/workflows/validate_docs_build.yml b/.github/workflows/validate_docs_build.yml index 2a2fca2b8da..730bcbdc355 100644 --- a/.github/workflows/validate_docs_build.yml +++ b/.github/workflows/validate_docs_build.yml @@ -9,8 +9,8 @@ on: jobs: deploy: # Release PRs and merge-backs are merged without waiting for CI. Skip when the - # head is release/* or master-into-dev/* AND the PR has release-management. - if: ${{ !((startsWith(github.head_ref, 'release/') || startsWith(github.head_ref, 'master-into-dev/')) && contains(github.event.pull_request.labels.*.name, 'release-management')) }} + # head is release/merge-* AND the PR has release-management. + if: ${{ !(startsWith(github.head_ref, 'release/merge-') && contains(github.event.pull_request.labels.*.name, 'release-management')) }} runs-on: ubuntu-latest steps: - name: Setup Hugo diff --git a/docs/content/get_started/contributing/branching-model.de.md b/docs/content/get_started/contributing/branching-model.de.md index 6f939a1d8c5..3e2fb525f7e 100644 --- a/docs/content/get_started/contributing/branching-model.de.md +++ b/docs/content/get_started/contributing/branching-model.de.md @@ -45,14 +45,14 @@ participant "Master Branch" as master #LightSalmon == Minor Release (Monthly) == -dev -> release: Create branch "release/2.x.0" +dev -> release: Create branch "release/merge-dev-into-master-2.x.0" release -> master: Merge note right: Official Release\n - Tag 2.x.0\n - Push 2.x.0 to DockerHub master --> dev: Merge master back into dev == Patch Release (Weekly) == -dev -> release: Create branch "release/2.x.y" +dev -> release: Create branch "release/merge-dev-into-master-2.x.y" release -> master: Merge note right: Official Release\n - Tag 2.x.y\n - Push 2.x.y to DockerHub master --> dev: Merge master back into dev diff --git a/docs/content/get_started/contributing/branching-model.es.md b/docs/content/get_started/contributing/branching-model.es.md index c16cf60b821..e392e11c685 100644 --- a/docs/content/get_started/contributing/branching-model.es.md +++ b/docs/content/get_started/contributing/branching-model.es.md @@ -45,14 +45,14 @@ participant "Master Branch" as master #LightSalmon == Minor Release (Monthly) == -dev -> release: Create branch "release/2.x.0" +dev -> release: Create branch "release/merge-dev-into-master-2.x.0" release -> master: Merge note right: Official Release\n - Tag 2.x.0\n - Push 2.x.0 to DockerHub master --> dev: Merge master back into dev == Patch Release (Weekly) == -dev -> release: Create branch "release/2.x.y" +dev -> release: Create branch "release/merge-dev-into-master-2.x.y" release -> master: Merge note right: Official Release\n - Tag 2.x.y\n - Push 2.x.y to DockerHub master --> dev: Merge master back into dev diff --git a/docs/content/get_started/contributing/branching-model.fr.md b/docs/content/get_started/contributing/branching-model.fr.md index 9587fd56827..06d22426cc9 100644 --- a/docs/content/get_started/contributing/branching-model.fr.md +++ b/docs/content/get_started/contributing/branching-model.fr.md @@ -45,14 +45,14 @@ participant "Master Branch" as master #LightSalmon == Minor Release (Monthly) == -dev -> release: Create branch "release/2.x.0" +dev -> release: Create branch "release/merge-dev-into-master-2.x.0" release -> master: Merge note right: Official Release\n - Tag 2.x.0\n - Push 2.x.0 to DockerHub master --> dev: Merge master back into dev == Patch Release (Weekly) == -dev -> release: Create branch "release/2.x.y" +dev -> release: Create branch "release/merge-dev-into-master-2.x.y" release -> master: Merge note right: Official Release\n - Tag 2.x.y\n - Push 2.x.y to DockerHub master --> dev: Merge master back into dev diff --git a/docs/content/get_started/contributing/branching-model.it.md b/docs/content/get_started/contributing/branching-model.it.md index 86fb4ea63f1..30ed3031078 100644 --- a/docs/content/get_started/contributing/branching-model.it.md +++ b/docs/content/get_started/contributing/branching-model.it.md @@ -45,14 +45,14 @@ participant "Master Branch" as master #LightSalmon == Minor Release (Monthly) == -dev -> release: Create branch "release/2.x.0" +dev -> release: Create branch "release/merge-dev-into-master-2.x.0" release -> master: Merge note right: Official Release\n - Tag 2.x.0\n - Push 2.x.0 to DockerHub master --> dev: Merge master back into dev == Patch Release (Weekly) == -dev -> release: Create branch "release/2.x.y" +dev -> release: Create branch "release/merge-dev-into-master-2.x.y" release -> master: Merge note right: Official Release\n - Tag 2.x.y\n - Push 2.x.y to DockerHub master --> dev: Merge master back into dev diff --git a/docs/content/get_started/contributing/branching-model.ja.md b/docs/content/get_started/contributing/branching-model.ja.md index 567209e893c..cf505dc2492 100644 --- a/docs/content/get_started/contributing/branching-model.ja.md +++ b/docs/content/get_started/contributing/branching-model.ja.md @@ -45,14 +45,14 @@ participant "Master Branch" as master #LightSalmon == Minor Release (Monthly) == -dev -> release: Create branch "release/2.x.0" +dev -> release: Create branch "release/merge-dev-into-master-2.x.0" release -> master: Merge note right: Official Release\n - Tag 2.x.0\n - Push 2.x.0 to DockerHub master --> dev: Merge master back into dev == Patch Release (Weekly) == -dev -> release: Create branch "release/2.x.y" +dev -> release: Create branch "release/merge-dev-into-master-2.x.y" release -> master: Merge note right: Official Release\n - Tag 2.x.y\n - Push 2.x.y to DockerHub master --> dev: Merge master back into dev diff --git a/docs/content/get_started/contributing/branching-model.md b/docs/content/get_started/contributing/branching-model.md index cc96498f4ca..e2f819d9ddc 100644 --- a/docs/content/get_started/contributing/branching-model.md +++ b/docs/content/get_started/contributing/branching-model.md @@ -45,14 +45,14 @@ participant "Master Branch" as master #LightSalmon == Minor Release (Monthly) == -dev -> release: Create branch "release/2.x.0" +dev -> release: Create branch "release/merge-dev-into-master-2.x.0" release -> master: Merge note right: Official Release\n - Tag 2.x.0\n - Push 2.x.0 to DockerHub master --> dev: Merge master back into dev == Patch Release (Weekly) == -dev -> release: Create branch "release/2.x.y" +dev -> release: Create branch "release/merge-dev-into-master-2.x.y" release -> master: Merge note right: Official Release\n - Tag 2.x.y\n - Push 2.x.y to DockerHub master --> dev: Merge master back into dev diff --git a/docs/content/get_started/contributing/branching-model.pt-br.md b/docs/content/get_started/contributing/branching-model.pt-br.md index cdd9229a03d..fd25f02b693 100644 --- a/docs/content/get_started/contributing/branching-model.pt-br.md +++ b/docs/content/get_started/contributing/branching-model.pt-br.md @@ -45,14 +45,14 @@ participant "Master Branch" as master #LightSalmon == Minor Release (Monthly) == -dev -> release: Create branch "release/2.x.0" +dev -> release: Create branch "release/merge-dev-into-master-2.x.0" release -> master: Merge note right: Official Release\n - Tag 2.x.0\n - Push 2.x.0 to DockerHub master --> dev: Merge master back into dev == Patch Release (Weekly) == -dev -> release: Create branch "release/2.x.y" +dev -> release: Create branch "release/merge-dev-into-master-2.x.y" release -> master: Merge note right: Official Release\n - Tag 2.x.y\n - Push 2.x.y to DockerHub master --> dev: Merge master back into dev diff --git a/docs/content/get_started/contributing/branching-model.zh-hans.md b/docs/content/get_started/contributing/branching-model.zh-hans.md index 2b4ebbab3b0..162cc4ea16f 100644 --- a/docs/content/get_started/contributing/branching-model.zh-hans.md +++ b/docs/content/get_started/contributing/branching-model.zh-hans.md @@ -45,14 +45,14 @@ participant "Master Branch" as master #LightSalmon == Minor Release (Monthly) == -dev -> release: Create branch "release/2.x.0" +dev -> release: Create branch "release/merge-dev-into-master-2.x.0" release -> master: Merge note right: Official Release\n - Tag 2.x.0\n - Push 2.x.0 to DockerHub master --> dev: Merge master back into dev == Patch Release (Weekly) == -dev -> release: Create branch "release/2.x.y" +dev -> release: Create branch "release/merge-dev-into-master-2.x.y" release -> master: Merge note right: Official Release\n - Tag 2.x.y\n - Push 2.x.y to DockerHub master --> dev: Merge master back into dev diff --git a/readme-docs/RELEASING.md b/readme-docs/RELEASING.md index e1bead2f9b5..ff272634caf 100644 --- a/readme-docs/RELEASING.md +++ b/readme-docs/RELEASING.md @@ -11,7 +11,7 @@ The release schedule decides which one is next. Dependency updates, bug fixes an The release process will then: -- Create a `release/x.y.z` branch from `dev` and a PR to merge it into `master` (`Release-1`) +- Create a `release/merge-dev-into-master-x.y.z` branch from `dev` and a PR to merge it into `master` (`Release-1`) - Tag the release, build the docker images and push them to Docker Hub (`Release-2`) - Merge the changes in `master` back into `dev` so the two stay in sync (`Release-3`) @@ -37,7 +37,7 @@ Run the `Release-1: Create PR for master` action. Leave `from_branch` on `dev` ( ![image](https://user-images.githubusercontent.com/4426050/149574288-a4056fb9-859c-413e-9f60-bc59894b0528.png) -The action creates the `release/x.y.z` branch from `dev`, updates the version numbers in it, removes the `-dev` suffix from the helm chart version, and opens the PR against `master`. +The action creates the `release/merge-dev-into-master-x.y.z` branch from `dev`, updates the version numbers in it, removes the `-dev` suffix from the helm chart version, and opens the PR against `master`. Verify the PR is created, and check if the commits in it make sense: @@ -52,7 +52,7 @@ Go to the bottom of the lists of commits, click on the `Update versions in appli ![image](https://user-images.githubusercontent.com/4426050/149577123-572cc6dd-7bf3-44ad-af58-ab6e46905558.png) -Do not wait for CI. The release PR and the merge-back PR are merged as soon as they are conflict-free, to save time and runner cost. CI skips them on purpose: a pull request is skipped when its head branch starts with `release/` or `master-into-dev/` and it has the `release-management` label (both release actions add it), and a push is skipped when the branch has one of those prefixes or the commit is GitHub's merge commit for such a PR. +Do not wait for CI. The release PR and the merge-back PR are merged as soon as they are conflict-free, to save time and runner cost. CI skips them on purpose: a pull request is skipped when its head branch starts with `release/merge-` and it has the `release-management` label (both release actions add it), and a push is skipped when the branch starts with `release/merge-` or the commit is GitHub's merge commit for such a PR. This is the same rule the other DefectDojo repositories use. Merge into `master` by *creating a merge commit*. Do NOT squash the commits! @@ -101,7 +101,7 @@ Check the PR and the version number updates. No tests run on this PR (see above), so merge it as soon as it is conflict-free. -Merge the `Release: Merge back x.y.z into dev from: master-into-dev/x.y.z-a.b.c-dev` PR by using a *Merge Commit*. Do NOT squash the commits. +Merge the `Release: Merge back x.y.z into dev from: release/merge-master-into-dev-x.y.z` PR by using a *Merge Commit*. Do NOT squash the commits. ![image](https://user-images.githubusercontent.com/4426050/149618642-276fffca-7e6f-4c51-bd9b-52bb5628cb7b.png)