{"id":34018059,"url":"https://github.com/podaac/poetry-cicd-example","last_synced_at":"2026-03-11T05:32:03.641Z","repository":{"id":64742019,"uuid":"572298138","full_name":"podaac/poetry-cicd-example","owner":"podaac","description":"Bare bones repository demonstrating a python poetry project using GitHub actions","archived":false,"fork":false,"pushed_at":"2026-02-13T22:43:29.000Z","size":150,"stargazers_count":2,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"develop","last_synced_at":"2026-02-14T04:48:18.562Z","etag":null,"topics":["development"],"latest_commit_sha":null,"homepage":"","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/podaac.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2022-11-30T00:58:27.000Z","updated_at":"2026-02-13T22:43:33.000Z","dependencies_parsed_at":"2022-12-14T10:32:04.655Z","dependency_job_id":null,"html_url":"https://github.com/podaac/poetry-cicd-example","commit_stats":null,"previous_names":[],"tags_count":5,"template":false,"template_full_name":null,"purl":"pkg:github/podaac/poetry-cicd-example","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/podaac%2Fpoetry-cicd-example","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/podaac%2Fpoetry-cicd-example/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/podaac%2Fpoetry-cicd-example/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/podaac%2Fpoetry-cicd-example/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/podaac","download_url":"https://codeload.github.com/podaac/poetry-cicd-example/tar.gz/refs/heads/develop","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/podaac%2Fpoetry-cicd-example/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":30372170,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-03-10T21:41:54.280Z","status":"online","status_checked_at":"2026-03-11T02:00:07.027Z","response_time":84,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["development"],"created_at":"2025-12-13T14:54:57.371Z","updated_at":"2026-03-11T05:32:03.625Z","avatar_url":"https://github.com/podaac.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"# poetry-cicd-example\nBare bones repository demonstrating a python [poetry](https://python-poetry.org/) project using GitHub actions\n\nAssumptions:\n\n* Project is hosted on github.com \n* Project uses an organization-scoped GitHub App for CICD operations\n* Project built using [poetry](https://python-poetry.org/)\n* Docker images will be published to ghcr.io\n* Credentials stored in GitHub Secrets\n  * CICD_APP_ID\n  * CICD_APP_PRIVATE_KEY\n  * SONAR_TOKEN\n  * GITHUB_TOKEN\n* Branch names: `main`, `develop`, `issues/*`\n* Project is using [semantic versioning](https://semver.org/)\n\n## Important Notes\n\n* After merging to `master`, a new change request should be opened to merge `master`\nback in to `develop` so that the version in `develop` is at least one minor version \nahead of `master`. This can't be automated because development likely will have continued while\nthe release was being evaluated and will cause merge conflicts since both branches will have\nmodified the version number. \n* Changes made in release branches should also be pushed back to `develop` if they are critical. Otherwise, the\nmerge from `master` to `develop` after release will incorporate the changes.\n* It is recommended that only one change request targeting `master` should be open at any given time. \n\n## Stages Overview\n\nThe main unit of work for Jenkins pipelines are Stages. Stages can contain sub-stages and can be conditionally run. At a high-level, this template defines the following\nstages listed below. In general, the stages are executed in order from top to bottom. However, some stages can be skipped for any particular run of the pipeline. \n\n* **Checkout**  \n  This stage checks out the code as triggered by the server event.  \n\n## Git Branching Strategy\n\nThe template is built with the assumption that the project follows the [git-workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) branching\nstrategy. A lot of the functionality is conditional on matching against branch naming conventions. Therefore, it is important that the project conform to this workflow.\n\n## Software Versioning\n\nThis template assumes the use of [semantic versioning](https://semver.org/) for the project being built. The strategy can be summarized as:\n\n* The `develop` branch always contains a [prerelease](https://semver.org/#spec-item-9) version of the project\n* The `develop` branch will always be at least 1 minor version ahead of `master`\n* Feature branches (prefixed with `issues/`) are branched from `develop`. When a feature branch is built, [build metadata](https://semver.org/#spec-item-10) is appended to the prerelease version \n* Every merge to develop increments the prerelease version number by one\n* Release branches are branched from `develop` and are named as `release/\u003csemver\u003e` where `\u003csemver\u003e` is a valid 'major.minor.patch' semantic version string.\n* The `\u003csemver\u003e` part of the branch name is used as the version for the release. See [Releasing](#Releasing) for details\n* As soon as a release branch is created, the minor version in the `develop` branch is bumped automatically by the `release-created.yml` workflow\n* Release candidates are created once a change request is created from a `release/*` branch that targets `master`\n* When a release candidate is created, the prerelease identifier is set to `rc` and the prerelease version is reset to 1\n* Any change (commit) to a release candidate change request results in a bump to the prerelease version\n* Merges to master remove the prerelease version and identifier but leave the remaining 'major.minor.patch' version\n* Tags using the version as the tag name are created for every new prerelease, release candidate, and release\n\n## Releasing\n\nWhen it is time to cut a release from the develop branch, a decision must be made. Is the release a major, minor, or patch release?\nThere are rules that should be followed when determining if the release is [minor](https://semver.org/#spec-item-7) or [major](https://semver.org/#spec-item-8).\n\nIf it is minor, create a branch prefixed with `release/` and followed by the development version without prerelease version or identifier. \nFor example, if `0.2.0-alpha.4` is the current develop version, then create a branch called `release/0.2.0`\n\nIf it is major, create a branch prefixed with `release/` and followed by the development major version incremented by 1 and using 0 for minor and patch number. \nFor example, if `0.2.0-alpha.4` is the current develop version, then create a branch called `release/1.0.0`\n\n## Reviews\n\nThere are two points of review in this workflow:\n\n1. When a change request is initiated from a feature branch to develop. This is a chance for developers to review the code that was developed as part of the feature request\nand suggest changes. The assumption is that code that makes it to develop is eligible for release and it will be deployed to a system integration testing (SIT) environment.\n2. When a change request is initiated from a release branch to `master`. This is a chance for other stakeholders to review the proposed changed that will be released \nto operations (OPS). As soon as a change request is initiated, the software will be deployed to a user acceptance testing (UAT) environment so that functionality can be tested.\nIt is recommended that only one change request targeting `master` should be open at any given time. \n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpodaac%2Fpoetry-cicd-example","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fpodaac%2Fpoetry-cicd-example","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpodaac%2Fpoetry-cicd-example/lists"}