From bfd0226cd25d368c64c5a2b3414bd235af56e56d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tom=C3=A1s=20Link?= Date: Thu, 19 Feb 2026 12:14:33 -0300 Subject: [PATCH 1/2] Update git workflow --- GIT-WORKFLOW.md | 70 ------------------------------------------------- GITHUB-FLOW.md | 67 ++++++++++++++++++++++++++++++++++++++++++++++ README.md | 2 +- 3 files changed, 68 insertions(+), 71 deletions(-) delete mode 100644 GIT-WORKFLOW.md create mode 100644 GITHUB-FLOW.md diff --git a/GIT-WORKFLOW.md b/GIT-WORKFLOW.md deleted file mode 100644 index 31cb9c3c..00000000 --- a/GIT-WORKFLOW.md +++ /dev/null @@ -1,70 +0,0 @@ -[Git Flow]: https://nvie.com/posts/a-successful-git-branching-model/ -[Semantic Versioning]: https://semver.org - -> [!IMPORTANT] -In the following, **MAJOR**, **MINOR** and **PATCH** refer to [Semantic Versioning]. - -We use [Git Flow] as our branching strategy, which is well suited for projects with long release cycles. -We add also support for maintanance of previous **MAJOR** versions. -Here we present a summary of the strategy. - -## **Main branches**: - -* **master**: reflects the code in production for the current **MAJOR**. -* **develop**: integrates code for the next release. -* **support/x.y**: reflects code in production for previous **MAJOR**, -allowing for **PATCH** increments. - -## **Feature branches**: - -1. Create a branch from **develop**. -2. Work on the feature. -3. Rebase on-top of **develop**. -3. Merge back to **develop** with a merge commit. - -There is currently no convention about the name of the feature branches, -other than being descriptive and separate the words using hyphens "-". - -To maintain a clear semi-linear history in **develop**, -we rebease on top of **develop** before merging the branch. -The merge should be done **forcing a merge commit**, -otherwise would be a fast-forward merge (because we rebased) -and the history would be linear instead of semi-linear, -losing the context of the branch. -This is enforced in the GitHub UI, -but locally is done with: -```shell -git merge branch --no-ff -``` - -## **Release branches**: - -1. Create a branch named **release/x.y.z** from **develop**. -2. Perform all steps needed to make the release. -3. Merge to **master** and **develop**. -4. Tag **master**. - -If the release its a **MAJOR** release, create a branch **support/x.y**, -where "x" is the previous **MAJOR** and "y" its last **MINOR** release. - -## **Hotfix branches**: - -These are quick **PATCH** increments done only to current **MAJOR** release: - -1. Create a branch named **hotfix/x.y.z** from **master**. -2. Work on the fix. Perform steps needed to make the release. -3. Merge back to **master** and also to **develop**. -4. Tag **master**. - -## **Patch branches**: - -These are **PATCH** increments to previous **MAJOR** releases: - -1. Create a branch named **patch/my-patch** from **support/x.y**. -2. Work on the fix. Perform steps needed to make a release. -3. Merge to **support/x.y**. -4. Tag **support/x.y**. - -If you need also this fix in the current **MAJOR**, -you will have to re-work the fix to be compatible with the new API. -You can work it in a [feature branch](#feature-branches) or make a [hotfix](#hotfix-branches). \ No newline at end of file diff --git a/GITHUB-FLOW.md b/GITHUB-FLOW.md new file mode 100644 index 00000000..111b8559 --- /dev/null +++ b/GITHUB-FLOW.md @@ -0,0 +1,67 @@ +# GitHub Flow + +[GitHub Flow]: https://githubflow.github.io/ + +
+ +[GitHub Flow] is an ideal workflow for teams that deploy frequently +and want to iterate quickly without the overhead of long release cycles or complex branching strategies. +It keeps the process simple and fast, +enabling continuous integration and deployment, +which helps catch issues early and deliver features to users rapidly. + +These are the basic rules of the workflow: +1. **`main` is always deployable** + + The `main` branch must be stable and ready to deploy at all times. Never push untested or broken code. + +2. **Create descriptively named branches from `main`** + + Start every new feature, fix, or idea in a new branch based on `main`, with clear and meaningful names. + +3. **Push to your branch often** + + Push work regularly to the remote to back it up, share progress, and trigger CI. + +4. **Open a Pull Request early** + + Use pull requests for code review, discussion, or help—long before the branch is “done.” + +5. **Get reviewed and approved before merging** + + Don’t merge until someone reviews and approves your work (even with just a 👍 or `:shipit:`). + +6. **Deploy right after merging to `main`** + + Once merged, deploy immediately or soon—everything in `main` should be safe and shippable. + +--- + +This flow emphasizes **simplicity, speed, and collaboration**, especially for teams that deploy frequently. + +### Additional team conventions + +- If you plan to make a release immediately after merging, + bump the version directly in your feature branch. + This avoids the need to create a separate release branch just for the version bump. + +- Always rebase feature branches on top of `main` before merging them. + This, combined with enforcing **merge commits** in GitHub repository settings, + results in a semi-linear history on the `main` branch, + which is very helpful when using `git log`.[^1] + If **merge commits** are not enforced, + Git will perform a **fast-forward merge** after rebasing, + creating a linear history + and losing the context of the feature branch. + If merging locally, avoid fast-forward merges with: + ```shell + git checkout main + git pull + git merge branch_name --no-ff + ``` + +[^1]: When performing a rebase, it's acceptable to `push --force` to your own feature branch, + but **never** on shared branches. + Protect `main` and/or `develop` from force pushes via GitHub settings. + +
diff --git a/README.md b/README.md index 76d82dfa..17a26155 100644 --- a/README.md +++ b/README.md @@ -23,7 +23,7 @@ which are broadcasting using the same MMSI at the same time. [docker compose plugin]: https://docs.docker.com/compose/install/linux/ [examples]: examples/ [git installed]: https://git-scm.com/downloads -[git workflow documentation]: GIT-WORKFLOW.md +[git workflow documentation]: GITHUB-FLOW.md [Makefile]: Makefile [pip-tools]: https://pip-tools.readthedocs.io/en/stable/ [requirements.txt]: requirements.txt From a10cffe30dea0da717cac0c05c9109f5a688399f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tom=C3=A1s=20Link?= Date: Thu, 19 Feb 2026 12:16:47 -0300 Subject: [PATCH 2/2] Add terraform cloudbuild trigger --- .gitignore | 4 ++++ cloudbuild.yaml | 38 -------------------------------------- cloudbuild/backend.tf | 6 ++++++ cloudbuild/main.tf | 17 +++++++++++++++++ pipe_segment/version.py | 2 +- 5 files changed, 28 insertions(+), 39 deletions(-) delete mode 100644 cloudbuild.yaml create mode 100644 cloudbuild/backend.tf create mode 100644 cloudbuild/main.tf diff --git a/.gitignore b/.gitignore index cc29f1fd..ac2435b4 100644 --- a/.gitignore +++ b/.gitignore @@ -115,3 +115,7 @@ output/ #osx .DS_Store + +# Terraform +.terraform +.terraform.lock.hcl \ No newline at end of file diff --git a/cloudbuild.yaml b/cloudbuild.yaml deleted file mode 100644 index 0b82c13d..00000000 --- a/cloudbuild.yaml +++ /dev/null @@ -1,38 +0,0 @@ -steps: -- name: 'gcr.io/cloud-builders/docker' - args: [ - 'build', - '-t', '${_IMAGE_NAME}:test', - '-f', 'Dockerfile', - '--target', 'dev', - '.', - ] - -- name: 'gcr.io/cloud-builders/docker' - args: [ - 'run', - '--rm', - '--entrypoint', 'py.test', - '${_IMAGE_NAME}:test', - ] - -- name: 'gcr.io/cloud-builders/docker' - args: [ - 'build', - '-t', '${_IMAGE_NAME}:${TAG_NAME}', - '-t', '${_IMAGE_NAME}:latest', - '-f', 'Dockerfile', - '--target', 'prod', - '.', - ] - -images: - - '${_IMAGE_NAME}:${TAG_NAME}' - - '${_IMAGE_NAME}:latest' - -timeout: 600s -substitutions: - _IMAGE_NAME: 'gcr.io/${PROJECT_ID}/github.com/globalfishingwatch/pipe-segment' -options: - dynamic_substitutions: true - diff --git a/cloudbuild/backend.tf b/cloudbuild/backend.tf new file mode 100644 index 00000000..d89cbd9a --- /dev/null +++ b/cloudbuild/backend.tf @@ -0,0 +1,6 @@ +terraform { + backend "gcs" { + bucket = "gfw-int-infrastructure-tfstate-us-central1" + prefix = "cloudbuild-pipe-segment" + } +} \ No newline at end of file diff --git a/cloudbuild/main.tf b/cloudbuild/main.tf new file mode 100644 index 00000000..a8d7585f --- /dev/null +++ b/cloudbuild/main.tf @@ -0,0 +1,17 @@ +module "trigger_push_to_tag" { + source = "git::https://github.com/GlobalFishingWatch/gfw-terraform-modules.git//modules/cloudbuild-trigger?ref=v0.2.0" + registry_artifact = "core" + repo_name = "pipe-segment" + tag = ".*" + trigger_description = "Builds and publishes a Docker image on every tag push." +} + +module "trigger_push_to_main" { + source = "git::https://github.com/GlobalFishingWatch/gfw-terraform-modules.git//modules/cloudbuild-trigger?ref=v0.2.0" + registry_artifact = "core" + repo_name = "pipe-segment" + branch = "main" + trigger_description = "Builds and publishes a Docker image on every push to the main branch." +} + + diff --git a/pipe_segment/version.py b/pipe_segment/version.py index 3d96b276..6a92b244 100644 --- a/pipe_segment/version.py +++ b/pipe_segment/version.py @@ -1 +1 @@ -__version__ = '5.0.1' +__version__ = '5.0.2'