Merge branch 'main' into clarify_approved_vs_mergeable

.circleci/config.yml

@@ -9,7 +9,7 @@ jobs:
         # that flag starts the download asynchronously so we'd have a race
         # condition.
         # renovate: datasource=github-releases depName=hashicorp/terraform versioning=hashicorp
-        TERRAFORM_VERSION: 1.6.5
+        TERRAFORM_VERSION: 1.6.6
     steps:
     - checkout
     - run: make build-service

.github/workflows/atlantis-image.yml

@@ -21,7 +21,7 @@ concurrency:
 jobs:
   changes:
     outputs:
-      should-run-build: ${{ steps.changes.outputs.src == 'true' }}
+      should-run-build: ${{ steps.changes.outputs.src == 'true' || startsWith(github.ref, 'refs/tags/') }}
     if: github.event.pull_request.draft == false
     runs-on: ubuntu-22.04
     steps:
@@ -152,4 +152,4 @@ jobs:
         image_type: [alpine, debian]
     runs-on: ubuntu-22.04
     steps:
-      - run: 'echo "No build required"'
+      - run: 'echo "No build required"'

.github/workflows/codeql.yml

@@ -71,7 +71,7 @@ jobs:
 
     # Initializes the CodeQL tools for scanning.
     - name: Initialize CodeQL
-      uses: github/codeql-action/init@v2
+      uses: github/codeql-action/init@v3
       with:
         languages: ${{ matrix.language }}
         # If you wish to specify custom queries, you can do so here or in a config file.
@@ -85,7 +85,7 @@ jobs:
     # Autobuild attempts to build any compiled languages  (C/C++, C#, Go, or Java).
     # If this step fails, then you should remove it and run the build manually (see below)
     - name: Autobuild
-      uses: github/codeql-action/autobuild@v2
+      uses: github/codeql-action/autobuild@v3
 
     # ℹ️ Command-line programs to run using the OS shell.
     # 📚 See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun
@@ -98,7 +98,7 @@ jobs:
     #   ./location_of_script_within_repo/buildscript.sh
 
     - name: Perform CodeQL Analysis
-      uses: github/codeql-action/analyze@v2
+      uses: github/codeql-action/analyze@v3
       with:
         category: "/language:${{matrix.language}}"
 

.github/workflows/release.yml

@@ -17,7 +17,7 @@ jobs:
         submodules: true
 
     - name: Set up Go
-      uses: actions/setup-go@v4
+      uses: actions/setup-go@v5
       with:
         go-version-file: go.mod
 

.github/workflows/stale.yml

@@ -6,7 +6,7 @@ jobs:
   stale:
     runs-on: ubuntu-22.04
     steps:
-      - uses: actions/stale@v8
+      - uses: actions/stale@v9
         with:
           stale-pr-message: 'This issue is stale because it has been open for 1 month with no activity. Remove stale label or comment or this will be closed in 1 month.'
           stale-issue-message: This issue is stale because it has been open for 1 month with no activity. Remove stale label or comment or this will be closed in 1 month.'

.github/workflows/website.yml

@@ -14,7 +14,7 @@ on:
     branches:
       - 'main'
       - 'release-**'
- 
+
 concurrency:
   group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
   cancel-in-progress: true
@@ -55,16 +55,18 @@ jobs:
       - name: run http-server
         env:
           # renovate: datasource=github-releases depName=raviqqe/muffet
-          MUFFET_VERSION: 2.6.3
+          MUFFET_VERSION: 2.9.3
         run: |
           npm install -g yarn
-          # http-server is used to serve the website locally as muffet checks it.
-          yarn global add http-server
+
           # install raviqqe/muffet to check for broken links.
-          curl -L https://github.com/raviqqe/muffet/releases/download/v${MUFFET_VERSION}/muffet_${MUFFET_VERSION}_Linux_x86_64.tar.gz | tar -xz
-          yarn install
-          yarn website:build
-          http-server runatlantis.io/.vuepress/dist &
+          curl -Ls https://github.com/raviqqe/muffet/releases/download/v${MUFFET_VERSION}/muffet_linux_amd64.tar.gz | tar -xz
+
+          # build the site
+          yarn && yarn website:build
+
+          # run http-server for muffet to check the links
+          npx http-server runatlantis.io/.vuepress/dist &
 
       - name: wait until server listened
         run: curl --retry-delay 1 --retry 30 --retry-all-error http://localhost:8080
@@ -86,4 +88,4 @@ jobs:
     name: Website Link Check
     runs-on: ubuntu-latest
     steps:
-      - run: 'echo "No build required"' 
+      - run: 'echo "No build required"'

.golangci.yml

@@ -7,22 +7,26 @@ linters-settings:
     ignore-words:
       # for gitlab notes api
       - noteable
+  revive:
+    rules:
+      - name: dot-imports
+        disabled: true
 
 linters:
   enable:
-  - errcheck
-  - gochecknoinits
-  - gofmt
-  - gosec
-  - gosimple
-  - ineffassign
-  - misspell
-  - revive
-  - staticcheck
-  - typecheck
-  - unconvert
-  - unused
-  - vet
-  - vetshadow
+    - errcheck
+    - gochecknoinits
+    - gofmt
+    - gosec
+    - gosimple
+    - ineffassign
+    - misspell
+    - revive
+    - staticcheck
+    - typecheck
+    - unconvert
+    - unused
+    - vet
+    - vetshadow
 run:
   timeout: 10m

CODEOWNERS

@@ -1,3 +1,3 @@
 # https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
 # These owners will be the default owners for everything in the repo.
-*    @runatlantis/maintainers
+*    @runatlantis/maintainers @runatlantis/core-contributors

CONTRIBUTING.md

@@ -160,18 +160,35 @@ If you get an error about `pegomock` not being available, install it:
 go get github.com/petergtz/pegomock/...
 ```
 
+# Backporting Fixes
+
+Atlantis now uses a [cherry-pick-bot](https://github.com/googleapis/repo-automation-bots/tree/main/packages/cherry-pick-bot) from Google. The bot assists in maintaining changes across releases branches by easily cherry-picking changes via pull requests.
+
+Maintainers and Core Contributors can add a comment to a pull request:
+
+```
+/cherry-pick target-branch-name
+```
+
+target-branch-name is the branch to cherry-pick to. cherry-pick-bot will cherry-pick the merged commit to a new branch (created from the target branch) and open a new pull request to the target branch.
+
+The bot will immediately try to cherry-pick a merged PR. On unmerged pull request, it will not do anything immediately, but wait until merge. You can comment multiple times on a PR for multiple release branches.
+
+## Manual Backporting Fixes
+
+The bot will fail to cherry-pick if the feature branches' git history is not linear (merge commits instead of rebase). In that case, you will need to manually cherry-pick the squashed merged commit from main to the release branch
+
+1. Switch to the release branch intended for the fix.
+1. Run `git cherry-pick <sha>` with the commit hash from the main branch.
+1. Push the newly cherry-picked commit up to the remote release branch.
+
 # Creating a New Release
-1. Update version number in `main.go`.
-1. Update image tag version in the [kustomize/bundle.yaml](kustomize/bundle.yaml).
-1. Update `CHANGELOG.md` with latest release number and information (this URL might be useful: https://github.com/runatlantis/atlantis/compare/v0.3.5...main)
-1. Create a pull request and merge to main
-1. Check out main and fetch latest
-1. Run `make release`
-    1. If you get `signal: killed` errors, bump up your Docker resources to have more memory, e.g. 6 G.B.
+1. (Major/Minor release only) Create a new release branch `release-x.y`
 1. Go to https://github.com/runatlantis/atlantis/releases and click "Draft a new release"
-    1. Prefix version with `v`
+    1. Prefix version with `v` and increment based on last release.
     1. The title of the release is the same as the tag (ex. v0.2.2)
-    1. Fill in description by copying from the CHANGELOG just without the Downloads section
-    1. Drag in binaries made with `make release`
-1. Re-run main branch build to ensure tag gets pushed to Github: https://github.com/runatlantis/atlantis/pkgs/container/atlantis
-1. Update the default version in `Chart.yaml` in [the official Helm chart](https://github.com/runatlantis/helm-charts/blob/main/charts/atlantis/values.yaml).
+    1. Fill in description by clicking on the "Generate Release Notes" button.
+        1. You may have to manually move around some commit titles as they are determined by PR labels (see .github/labeler.yml & .github/release.yml)
+    1. (Latest Major/Minor branches only) Make sure the release is set as latest
+        1. Don't set "latest release" for patches on older release branches.
+1. Check and update the default version in `Chart.yaml` in [the official Helm chart](https://github.com/runatlantis/helm-charts/blob/main/charts/atlantis/values.yaml) as needed.

Dockerfile

@@ -1,7 +1,7 @@
 # syntax=docker/dockerfile:1
 # what distro is the image being built for
-ARG ALPINE_TAG=3.18.5
-ARG DEBIAN_TAG=12.2-slim
+ARG ALPINE_TAG=3.19.0
+ARG DEBIAN_TAG=12.4-slim
 
 ARG DEFAULT_TERRAFORM_VERSION=1.6.3
 ARG DEFAULT_CONFTEST_VERSION=0.46.0
@@ -90,7 +90,7 @@ RUN AVAILABLE_CONFTEST_VERSIONS=${DEFAULT_CONFTEST_VERSION} && \
 
 # install git-lfs
 # renovate: datasource=github-releases depName=git-lfs/git-lfs
-ENV GIT_LFS_VERSION=3.4.0
+ENV GIT_LFS_VERSION=3.4.1
 
 RUN case ${TARGETPLATFORM} in \
         "linux/amd64") GIT_LFS_ARCH=amd64 ;; \
@@ -158,13 +158,13 @@ COPY docker-entrypoint.sh /usr/local/bin/docker-entrypoint.sh
 # We place this last as it will bust less docker layer caches when packages update
 RUN apk add --no-cache \
         ca-certificates~=20230506 \
-        curl~=8.5 \
-        git~=2.40 \
-        unzip~=6.0 \
-        bash~=5.2 \
-        openssh~=9.3_p2 \
-        dumb-init~=1.2 \
-        gcompat~=1.1
+        curl~=8 \
+        git~=2 \
+        unzip~=6 \
+        bash~=5 \
+        openssh~=9 \
+        dumb-init~=1 \
+        gcompat~=1
 
 
 # Set the entry point to the atlantis user and run the atlantis command

GOVERNANCE.md

@@ -0,0 +1,116 @@
+# Atlantis Governance
+
+This document defines the project governance for Atlantis.
+
+## Overview
+
+**Atlantis** is committed to building an open, inclusive, productive and self-governing open source
+community focused on building a high-quality infrastructure orchestration system. The
+community is governed by this document with the goal of defining how community
+should work together to achieve this goal.
+
+## Code Repositories
+
+The following code repositories are governed by Atlantis community and
+maintained under the `runatlantis` organization.
+
+* **[atlantis](https://github.com/runatlantis/atlantis):** Main Atlantis codebase.
+* **[atlantis-helm-charts](https://github.com/runatlantis/helm-charts):** Helm chart for easy deployment of Atlantis.
+* **[atlantis-tests](https://github.com/runatlantis/atlantis-tests):** A set of terraform projects that atlantis e2e tests run on.
+* **[atlantis-example](https://github.com/runatlantis/atlantis-example):** A simple terraform project to use along with atlantis bootstrap mode.
+
+## Community Roles
+
+* **Users:** Members that engage with the Atlantis community via any medium (Slack, GitHub, mailing lists, etc.).
+* **Contributors:** Regular contributions to projects (documentation, code reviews, responding to issues, participation in proposal discussions, contributing code, etc.). 
+* **Core Contributors:** Contributors who drive certain subprojects within Atlantis. They are responsible for the direction and work done within that subproject, providing enhancements and support for the Atlantis project as a whole. Core Contributors are expected to contribute code and documentation, review PRs including ensuring quality of code, triage issues, proactively fix bugs, and perform maintenance tasks for the subprojects they are responsible for.
+* **Maintainers:** The Atlantis project leaders. They are responsible for the overall health and direction of the project; final reviewers of PRs and responsible for releases. Some Maintainers are responsible for one or more components within a project, acting as technical leads for that component. Maintainers are expected to contribute code and documentation, review PRs including ensuring quality of code, triage issues, proactively fix bugs, and perform maintenance tasks for these components.
+
+### Maintainers
+
+New maintainers and subproject maintainers must be nominated by an existing maintainer and must be elected by a supermajority of existing maintainers. Likewise, maintainers can be removed by a supermajority of the existing maintainers or can resign by notifying one of the maintainers.
+
+### Supermajority
+
+A supermajority is defined as two-thirds of members in the group.
+A supermajority of [Maintainers](#maintainers) is required for certain
+decisions as outlined above. Voting on decisions can happen on the mailing list, GitHub, Slack, email, or via a voting service, when appropriate. Maintainers can either vote "agree, yes, +1", "disagree, no, -1", or "abstain". A vote passes when supermajority is met. An abstain vote equals not voting at all.
+
+### Decision Making
+
+Ideally, all project decisions are resolved by consensus. If impossible, any
+maintainer may call a vote. Unless otherwise specified in this document, any
+vote will be decided by a supermajority of maintainers.
+
+Votes by maintainers belonging to the same company
+will count as one vote; e.g., 4 maintainers employed by fictional company **Fictiousum** will
+only have **one** combined vote. If voting members from a given company do not
+agree, the company's vote is determined by a supermajority of voters from that
+company. If no supermajority is achieved, the company is considered to have
+abstained.
+
+## Proposal Process
+
+One of the most important aspects in any open source community is the concept
+of proposals. Large changes to the codebase and/or new features should be
+preceded by a proposal as an ADR or GH issue in the main Atlantis repo. This process allows for all
+members of the community to weigh in on the concept (including the technical
+details), share their comments and ideas, and offer to help. It also ensures
+that members are not duplicating work or inadvertently stepping on toes by
+making large conflicting changes.
+
+The project roadmap is defined by accepted proposals.
+
+Proposals should cover the high-level objectives, use cases, and technical
+recommendations on how to implement. In general, the community member(s)
+interested in implementing the proposal should be either deeply engaged in the
+proposal process or be an author of the proposal.
+
+The proposal should be documented as a separated markdown file pushed to the root of the 
+`docs/adr` folder in the [atlantis](https://github.com/runatlantis/atlantis)
+repository via PR. The name of the file should follow the name pattern set by the ADR process `<####-short
+meaningful words joined by '-'>.md`, e.g:
+`0002-adr-proposal.md`.
+
+Use the [ADR Tools](https://github.com/npryce/adr-tools) and run `adr new <title>`
+
+### Proposal Lifecycle
+
+The proposal PR can be marked with different status labels to represent the
+status of the proposal:
+
+* **New**: Proposal is just created.
+* **Reviewing**: Proposal is under review and discussion.
+* **Accepted**: Proposal is reviewed and accepted (either by consensus or vote).
+* **Rejected**: Proposal is reviewed and rejected (either by consensus or vote).
+
+## Lazy Consensus
+
+To maintain velocity in a project as busy as Atlantis, the concept of [Lazy
+Consensus](http://en.osswiki.info/concepts/lazy_consensus) is practiced. Ideas
+and/or proposals should be shared by maintainers via
+GitHub with the appropriate maintainer groups (e.g.,
+`@atlantis/all-maintainers`) tagged. Out of respect for other contributors,
+major changes should also be accompanied by a ping on Slack in the 
+[#contributors](https://atlantis-community.slack.com/archives/C04ES70Q6E8) channel or a note on the
+Atlantis google mailing list as appropriate. Author(s) of proposal, Pull Requests,
+issues, etc.  will give a time period of no less than five (5) working days for
+comment and remain cognizant of popular observed world holidays.
+
+Other maintainers may chime in and request additional time for review, but
+should remain cognizant of blocking progress and abstain from delaying
+progress unless absolutely needed. The expectation is that blocking progress
+is accompanied by a guarantee to review and respond to the relevant action(s)
+(proposals, PRs, issues, etc.) in short order.
+
+Lazy Consensus is practiced for all projects in the `runatlantis` org, including
+the main project repository, community-driven sub-projects, and the community
+repo that includes proposals and governing documents.
+
+Lazy consensus does _not_ apply to the process of:
+
+* Removal of maintainers from Atlantis
+
+## Updating Governance
+
+All substantive changes in Governance require a supermajority agreement by all maintainers.

MAINTAINERS.md

@@ -5,4 +5,4 @@ The current Maintainers Group for the [Atlantis] Project consists of:
 | Dylan Page    | [GenPage](https://github.com/GenPage) | Autodesk |    Maintainer    |
 | PePe Amengual | [jamengual](https://github.com/jamengual) | Slalom   |    Maintainer    |
 | Rui Chen      | [chenrui333](https://github.com/chenrui333) | Meetup   |    Maintainer    |
-| Ronak         | [nitrocode](https://github.com/nitrocode) |RB Consulting LLC | Contributor, Reviewer |
+| Ronak         | [nitrocode](https://github.com/nitrocode) | RB Consulting LLC | Core Contributor |