Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ci: GH actions for goreleaser, changelog reminder, and backport #75

Merged
merged 4 commits into from
Oct 10, 2024
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 38 additions & 0 deletions .github/workflows/backport.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@
# Adapted from https://github.com/marketplace/actions/backporting
#
# Usage:
# - Let's say you want to backport a pull request on a branch named `production`.
# - Then label it with `backport production`.
# - That's it! When the pull request gets merged, it will be backported to
# the `production` branch. If the pull request cannot be backported, a comment
# explaining why will automatically be posted.
#
# Note: multiple backport labels can be added. For example, if a pull request
# has the labels `backport staging` and `backport production` it will be
# backported to both branches: `staging` and `production`.
name: Backport
on:
pull_request_target:
types:
- closed
- labeled

jobs:
backport:
name: Backport
runs-on: ubuntu-latest
# Only react to merged PRs for security reasons.
# See https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target.
if: >
github.event.pull_request.merged
&& (
github.event.action == 'closed'
|| (
github.event.action == 'labeled'
&& contains(github.event.label.name, 'backport')
)
)
steps:
- uses: tibdex/backport@v2
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
8 changes: 6 additions & 2 deletions .github/workflows/ci.yml
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ on:

jobs:
lint_test:
uses: babylonlabs-io/.github/.github/workflows/reusable_go_lint_test.yml@v0.3.1
uses: babylonlabs-io/.github/.github/workflows/reusable_go_lint_test.yml@v0.7.0
with:
go-version: '1.23'
go-lint-version: 'v1.60.2'
Expand All @@ -18,8 +18,12 @@ jobs:
sudo apt-get update
sudo apt-get install -y libzmq3-dev

changelog_reminder:
uses: babylonlabs-io/.github/.github/workflows/[email protected]
secrets: inherit

docker_pipeline:
uses: babylonlabs-io/.github/.github/workflows/reusable_docker_pipeline.yml@v0.3.1
uses: babylonlabs-io/.github/.github/workflows/reusable_docker_pipeline.yml@v0.7.0
secrets: inherit
with:
publish: false
11 changes: 11 additions & 0 deletions .github/workflows/goreleaser.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
name: goreleaser

on:
push:
tags:
- '*'

jobs:
release:
uses: babylonlabs-io/.github/.github/workflows/[email protected]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should each repo owner add .goreleaser.yml to the root of the project? How does the gh action know to build our binaries otherwise?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm good question. This workflow does not upload binaries at the moment. To this end one needs to add stuff like https://github.com/marketplace/actions/goreleaser-action#upload-artifacts to the template. Can do in subsequent PRs

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I think it's also not building them either (how do we check it?), it needs something like this

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

@SebastianElvis SebastianElvis Oct 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I think it's also not building them either (how do we check it?), it needs something like this

Yeah the current workflow is just creating a release corresponding to the tagged version. To fix this one needs to first call make build, and then add a step in the workflow like this to upload the binary. Or add a yml file like this. Need some research there

secrets: inherit
4 changes: 2 additions & 2 deletions .github/workflows/publish.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ on:

jobs:
lint_test:
uses: babylonlabs-io/.github/.github/workflows/reusable_go_lint_test.yml@v0.3.1
uses: babylonlabs-io/.github/.github/workflows/reusable_go_lint_test.yml@v0.7.0
with:
go-version: '1.23'
go-lint-version: 'v1.60.2'
Expand All @@ -23,7 +23,7 @@ jobs:

docker_pipeline:
needs: ["lint_test"]
uses: babylonlabs-io/.github/.github/workflows/reusable_docker_pipeline.yml@v0.3.1
uses: babylonlabs-io/.github/.github/workflows/reusable_docker_pipeline.yml@v0.7.0
secrets: inherit
with:
publish: true
Loading