4 Commits

5 changed files with 52 additions and 128 deletions
+19 -23
View File
@@ -1,4 +1,4 @@
# Project status — fullupgrade
# Project Status — fullupgrade
Last updated: 2026-04-27
@@ -31,38 +31,39 @@ Notes:
Recommendations:
- keep documenting the system impact clearly
- consider whether `pacman -Sc` is the right cache cleanup level for every use case
### 2) `makerelease.sh`
Current behavior:
- takes `VERSION` and `MESSAGE` as arguments
- supports explicit versions like `1.2.3`
- supports version increments with `+0.0.1`, `+0.1`, and `+1`
- supports `--dry-run` to print the computed release version
- checks that the current branch is `dev`
- verifies the working tree is clean
- checks that the target tag does not already exist
- displays the computed release tag before proceeding
- asks for confirmation before any Git action
- checks out `main`
- merges `dev` into `main`
- pushes the branch
- creates an annotated tag
- pushes tags
- returns to `dev`
- attempts to return to the original branch on exit
Notes:
- the script currently does not use `set -euo pipefail`
- there is no check for a clean working tree
- there is no validation of the release message
- there is no guard against duplicate tags
- returning to `dev` is not protected if a command fails
- the script uses `set -euo pipefail`
- the release tag message is automatically generated as `Release <version>`
- the script no longer requires a separate release message argument
- the current increment logic assumes simple dotted numeric tags
- normal releases now require an interactive confirmation after the tag is displayed
Recommendations:
- add `set -euo pipefail`
- verify the Git status before releasing
- validate `VERSION` and `MESSAGE`
- prevent duplicate tags
- use a `trap` to return to the initial branch on failure
- improve the help output
- consider validating the version format more strictly if release rules grow
- keep the dry-run behavior documented and aligned with the script
### 3) `README.md`
Current status:
- the README has a first complete pass in English
- it explains both scripts, their requirements, usage, warnings, and an example release command
- the README documents both scripts in English
- it includes release increments, dry-run usage, and the confirmation step for `makerelease.sh`
Recommendations:
- keep it aligned with the actual script behavior
@@ -75,12 +76,7 @@ This file should be updated whenever:
- new constraints or design decisions are introduced
- release workflow rules evolve
## Current priorities
1. Secure the Bash scripts
2. Keep documentation aligned with the scripts
3. Make the release workflow more robust
## Maintenance notes
- Always keep the README, the scripts, and this file consistent.
- If a script changes, update this note immediately.
- If a script changes, update this note immediately (./continue/rules/project.md).
- If a new usage rule appears, document it here.
+9 -6
View File
@@ -47,12 +47,14 @@ sudo ./fullupgrade
1. checks that the current branch is `dev` for real releases
2. verifies the working tree is clean
3. optionally computes a new version from an increment shortcut
4. switches to `main`
5. merges `dev` into `main`
6. pushes `main`
7. creates an annotated tag
8. pushes tags
9. switches back to the original branch on exit
4. displays the chosen release tag
5. asks for confirmation before any Git action
6. switches to `main`
7. merges `dev` into `main`
8. pushes `main`
9. creates an annotated tag
10. pushes tags
11. switches back to the original branch on exit
### Usage
@@ -81,6 +83,7 @@ sudo ./fullupgrade
- `VERSION` is used directly as the tag name.
- If `VERSION` starts with `+`, it is treated as an increment based on the latest existing tag.
- `--dry-run` can be used from any branch and only prints the computed tag.
- In normal mode, the computed tag is shown and a confirmation is required before Git actions run.
- The script may fail if Git state is unexpected or if a tag already exists.
- The tag message is automatically generated as `Release <version>`.
+13 -13
View File
@@ -5,20 +5,20 @@ show_help() {
cat <<'EOF'
Usage: fullupgrade
Met à jour Arch Linux et effectue un nettoyage:
- mise à jour de archlinux-keyring
- synchronisation complète du système
- suppression des paquets orphelins
- nettoyage du cache pacman
Updates Arch Linux and performs cleanup:
- updates archlinux-keyring
- performs a full system synchronization
- removes orphaned packages
- cleans the pacman cache
Attention: ce script modifie le système et s'exécute sans confirmation.
Warning: this script modifies the system and runs without confirmation.
EOF
}
require_root() {
if [ "${EUID:-$(id -u)}" -ne 0 ]; then
echo "Erreur: ce script doit être exécuté en root." >&2
echo "Error: this script must be run as root." >&2
exit 1
fi
}
@@ -31,7 +31,7 @@ cleanup_orphans() {
if [ "${#orphans[@]}" -gt 0 ]; then
pacman -Rns --noconfirm "${orphans[@]}"
else
echo "Aucun paquet orphelin à supprimer."
echo "No orphaned packages to remove."
fi
}
@@ -43,19 +43,19 @@ main() {
require_root
echo "Mise à jour de archlinux-keyring..."
echo "Updating archlinux-keyring..."
pacman -Sy --noconfirm archlinux-keyring
echo "Mise à jour complète du système..."
echo "Performing full system update..."
pacman -Syu --noconfirm
echo "Recherche des paquets orphelins..."
echo "Searching for orphaned packages..."
cleanup_orphans
echo "Nettoyage du cache pacman..."
echo "Cleaning pacman cache..."
pacman -Sc --noconfirm
echo "Mise à jour terminée avec succès."
echo "Update completed successfully."
}
main "$@"
+11
View File
@@ -114,6 +114,17 @@ if [ "${is_dry_run}" = true ]; then
exit 0
fi
echo "Release tag selected: ${release_tag}"
read -r -p "Proceed with release? [y/N] " confirm
case "${confirm}" in
y|Y)
;;
*)
echo "Release cancelled."
exit 1
;;
esac
git checkout "${TAGBRANCH}"
CURRENTBRANCH="${TAGBRANCH}"
git merge "${ORIGBRANCH}"
-86
View File
@@ -1,86 +0,0 @@
# Project Status — fullupgrade
Last updated: 2026-04-27
## Project goal
This repository contains two Bash scripts for system administration and Git release management:
- `fullupgrade`: Arch Linux maintenance script
- `makerelease.sh`: Git release automation script
The project is intentionally minimal and centered on these two scripts.
## Current structure
- `fullupgrade`: system update and cleanup
- `makerelease.sh`: release workflow from `dev` to `main`
- `README.md`: English documentation with usage, warnings, and examples
- `LICENSE`: GPLv3
## Current analysis
### 1) `fullupgrade`
Current behavior:
- updates `archlinux-keyring`
- runs `pacman -Syu --noconfirm`
- removes orphaned packages only when any are found
- cleans the pacman cache
Notes:
- the script already uses `set -euo pipefail`
- it checks for root privileges before running package operations
- it can have a significant system impact
Recommendations:
- keep documenting the system impact clearly
- consider whether `pacman -Sc` is the right cache cleanup level for every use case
### 2) `makerelease.sh`
Current behavior:
- supports explicit versions like `1.2.3`
- supports version increments with `+0.0.1`, `+0.1`, and `+1`
- supports `--dry-run` to print the computed release version
- checks that the current branch is `dev`
- verifies the working tree is clean
- checks that the target tag does not already exist
- checks out `main`
- merges `dev` into `main`
- pushes the branch
- creates an annotated tag
- pushes tags
- attempts to return to the original branch on exit
Notes:
- the script uses `set -euo pipefail`
- the release tag message is now generated automatically as `Release <version>`
- the script no longer requires a separate release message argument
- the current increment logic assumes simple dotted numeric tags
Recommendations:
- consider whether tags may need a `v` prefix in the future
- consider validating the version format more strictly if release rules grow
- keep the dry-run behavior documented and aligned with the script
### 3) `README.md`
Current status:
- the README documents both scripts in English
- it now includes release increments and dry-run usage for `makerelease.sh`
Recommendations:
- keep it aligned with the actual script behavior
- add more examples only if they improve clarity
## Project tracking rules
This file should be updated whenever:
- script behavior changes
- documentation changes materially
- new constraints or design decisions are introduced
- release workflow rules evolve
## Current priorities
1. Secure the Bash scripts
2. Keep documentation aligned with the scripts
3. Make the release workflow more robust
## Maintenance notes
- Always keep the README, the scripts, and this file consistent.
- If a script changes, update this note immediately.
- If a new usage rule appears, document it here.