github.com/argoproj/argo-cd/v3@v3.2.1/docs/developer-guide/releasing.md (about)

     1  # Releasing
     2  
     3  ## Introduction
     4  
     5  Argo CD is released in a 2 step automated fashion using GitHub actions. The release process takes about 60 minutes,
     6  sometimes a little less, depending on the performance of GitHub Actions runners.
     7  
     8  The target release branch must already exist in the GitHub repository. If you for
     9  example want to create a release `v2.7.0`, the corresponding release branch
    10  `release-2.7` needs to exist, otherwise, the release cannot be built. Also,
    11  the trigger tag should always be created in the release branch, checked out
    12  in your local repository clone.
    13  
    14  Before triggering the release automation, the `CHANGELOG.md` should be updated
    15  with the latest information, and this change should be committed and pushed to
    16  the GitHub repository to the release branch. Afterward, the automation can be
    17  triggered. This will be automated in the very near future.
    18  
    19  **Manual steps before release creation:**
    20  
    21  * Update `CHANGELOG.md` with changes for this release
    22  * Commit & push changes to `CHANGELOG.md`
    23  * Update `goreleaser.yaml` with the updated blog post link in the `Release Notes Blog Post` section.
    24  
    25  **The `Init ArgoCD Release` workflow will perform the following steps:**
    26  
    27  * Update `VERSION` file in the release branch
    28  * Update manifests with image tags of the new version in the release branch
    29  * Create a pull request to submit the above changes
    30  
    31  **The `Publish ArgoCD Release` workflow will perform the following steps:**
    32  
    33  * Build, push, and signs the container image to Quay.io
    34  * Generate a provenance for the container image
    35  * Builds the CLI binaries, release-notes, and then creates a GitHub release and attaches the required assets.
    36  * Generate a provenance for the CLI binaries
    37  * Generate and sign a sbom
    38  * Update the stable tag when applicable
    39  * Update `VERSION` file in the master branch when a new release is GA
    40  
    41  ## Steps
    42  
    43  ### Step 1 - Update Version and Manifest
    44  
    45  1. Ensure that the TARGET_BRANCH already exist.
    46  2. Visit the [Release GitHub Action](https://github.com/argoproj/argo-cd/actions/workflows/init-release.yaml)
    47  and choose which branch you would like to work from.
    48  3. Enter the TARGET_BRANCH to checkout.
    49  4. Enter the TARGET_VERSION that will be used to build manifest and `VERSION` file. (e.g `2.7.0-rc1`)
    50  
    51  ![GitHub Release Action](../assets/release-action.png)
    52  
    53  When the action is completed a pull request will be generated that contains the updated manifest and `Version` file.
    54  
    55  5. Merge the pull request and proceed to step 2.
    56  
    57  ### Step 2 - Tag Release Branch
    58  
    59  The steps below need to be executed by someone with write access in Argo CD upstream repo.
    60  
    61  1. Checkout the release branch. Example: `git fetch upstream && git
    62     checkout release-2.7`
    63  2. Run the script found at `hack/trigger-release.sh` as follows:
    64  
    65  ```shell
    66  ./hack/trigger-release.sh <version> <remote name>
    67  ```
    68  
    69  Example: 
    70  ```shell
    71  ./hack/trigger-release.sh v2.7.2 upstream
    72  ```
    73  
    74  !!! tip
    75      The tag must be in one of the following formats to trigger the GH workflow:<br>
    76      * GA: `v<MAJOR>.<MINOR>.<PATCH>`<br>
    77      * Pre-release: `v<MAJOR>.<MINOR>.<PATCH>-rc<RC#>`
    78  
    79  Once the script is executed successfully, a GitHub workflow will start
    80  execution. You can follow its progress under the [Actions](https://github.com/argoproj/argo-cd/actions/workflows/release.yaml) tab, the name of the action is `Publish ArgoCD Release`. 
    81  
    82  !!! warning
    83      You cannot perform more than one release on the same release branch at the
    84      same time.
    85  
    86  ### Verifying automated release
    87  
    88  After the automatic release creation has finished, you should perform manual
    89  checks to see if the release came out correctly:
    90  
    91  * Check status & output of the GitHub action
    92  * Check [https://github.com/argoproj/argo-cd/releases](https://github.com/argoproj/argo-cd/releases)
    93    to see if the release has been correctly created and if all required assets
    94    are attached.
    95  * Check whether the image has been published on Quay.io correctly
    96  
    97  ### If something went wrong
    98  
    99  If something went wrong, damage should be limited. Depending on the steps that
   100  have been performed, you will need to manually clean up.
   101  
   102  * If the container image has been pushed to Quay.io, delete it
   103  * Delete the release (if created) from the `Releases` page on GitHub
   104  
   105  ### Manual releasing
   106  
   107  The release process does not allow a manual release process. Image signatures and provenance need to be created using GitHub Actions.
   108  
   109  ## Notable files that involve the release process.
   110  
   111  | File                               | Description                                            |
   112  |------------------------------------|--------------------------------------------------------|
   113  |goreleaser.yaml                     |Config to build CLI binaries, checksums, release-notes  |
   114  |.github/workflows/image-reuse.yaml  |Reusable workflow used to generate container images     |
   115  |.github/workflows/init-release.yaml |Used to generate manifest and `VERSION` file            |
   116  |.github/workflows/release.yaml      |Build image, CLI binaries, provenances, sbom, post jobs |
   117  |./hack/trigger-release.sh           |Ensures all pre-requistes are met and pushes the tag    |