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

[DEVOPS-1525] swift workflow for package publishing #268

Closed

Conversation

mimartin12
Copy link
Contributor

@mimartin12 mimartin12 commented Oct 5, 2023

Type of change

- [ ] Bug fix
- [ ] New feature development
- [ ] Tech debt (refactoring, code cleanup, dependency upgrades, etc)
- [X] Build/deploy pipeline (DevOps)
- [ ] Other

Objective

Build and deploy workflows for the BitwardenFFI. xcframework package.

Code changes

  • .github/workflows/build-swift.yml: Workflow that builds rc and hotfix-rc-swift branches, creating the versioned BitwardenFFI.xcframework package.
  • .github/workflows/.github/workflows/release-swift.yml Workflow to create a GitHub release from rc or hotfix-rc-swift branches. Creating a GitHub tag and release for BitwardenFFI.xcframework. Included is a job to push changes to the sdk-swift repository and create a release tag.

Screenshots

Before you submit

  • Please add unit tests where it makes sense to do so (encouraged but not required)

@bitwarden-bot
Copy link

bitwarden-bot commented Oct 5, 2023

Logo
Checkmarx One – Scan Summary & Details5c462843-d93a-4970-929d-557c395eeaef

New Issues

Severity Issue Source File / Package Checkmarx Insight
MEDIUM Unpinned Actions Full Length Commit SHA /release-swift.yml: [34](https://github.com/bitwarden/sdk/blob/DEVOPS-1525-swift-workflow-for-package-publishing//.github/workflows/release-swift.yml# L34) Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps...
MEDIUM Unpinned Actions Full Length Commit SHA /release-swift.yml: [76](https://github.com/bitwarden/sdk/blob/DEVOPS-1525-swift-workflow-for-package-publishing//.github/workflows/release-swift.yml# L76) Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps...
MEDIUM Unpinned Actions Full Length Commit SHA /build-swift.yml: [83](https://github.com/bitwarden/sdk/blob/DEVOPS-1525-swift-workflow-for-package-publishing//.github/workflows/build-swift.yml# L83) Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps...

@mimartin12 mimartin12 marked this pull request as ready for review October 9, 2023 15:13
@mimartin12 mimartin12 requested a review from a team as a code owner October 9, 2023 15:13
Comment on lines 7 to 8
- "rc"
- "hotfix-rc-swift"
Copy link
Member

Choose a reason for hiding this comment

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

What about master? We currently don't "release" the swift sdk so the pressing concern is to get master snapshots automated since we have to do those manually currently.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was having a discussion around that in slack, in the CloudOps channel. I want to figure this out as well.

For all GitHub release artifacts, those will need to be sourced from the deployment branch. Which is rc or hotifx-rc-swift. GitHub release artifacts have to come from a tag, and then we create a GitHub release with the artifact attached.

To get master builds into a public place to source them in package.swift. Those would be stored in an Azure storage account.

Or if the idea was to release straight from master automatically, and have every build be a "GitHub Release" we can go that route for hosting the artifact.

Copy link
Member

Choose a reason for hiding this comment

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

We don't want every merge into master to be a new release.

Copy link
Contributor

Choose a reason for hiding this comment

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

My request / feedback in Slack was to get full releases working first with all this, then to look at what master artifacts look like (perhaps in parallel). I understand the GitHub release is noisy for every merge and that's not the path, but I want to keep our maintenance burden as low as possible since GitHub Packages doesn't exist for Swift.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, so releases from merges into master isn't the way we want to go.

Do either of you all like the route of rc or hotfix/hotfix-rc as the release branch, just like how it's currently structured in the workflow?

Copy link
Contributor

Choose a reason for hiding this comment

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

Assuming the need to get artifacts for every master merge is unneeded at the moment, I like the unification of process of using rc or similar to prep and ship a release with artifacts.

Copy link
Member

@Hinton Hinton Nov 2, 2023

Choose a reason for hiding this comment

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

Our requirement today is snapshot releases. I.e. commits on master. We don't have any needs or plans on publishing stable releases for the swift SDK for a fairly long time.

.github/workflows/build-swift.yml Outdated Show resolved Hide resolved
.github/workflows/build-swift.yml Outdated Show resolved Hide resolved
.github/workflows/build-swift.yml Outdated Show resolved Hide resolved
.github/workflows/release-swift.yml Show resolved Hide resolved
@mimartin12 mimartin12 force-pushed the DEVOPS-1525-swift-workflow-for-package-publishing branch from 7da0f4d to b23e9aa Compare October 23, 2023 17:27
@mimartin12 mimartin12 force-pushed the DEVOPS-1525-swift-workflow-for-package-publishing branch from fe12dc4 to 35a251a Compare October 23, 2023 21:25
- Add default environment variables
- Update branch check
- Point Bitwarden actions to main
- Move github-release step to last
- Create release on sdk-swift project
@mimartin12 mimartin12 removed the stale label Apr 16, 2024
@mimartin12 mimartin12 requested a review from Hinton April 16, 2024 15:36
@mimartin12
Copy link
Contributor Author

I made some changes and brought in some implementation similar to https://github.com/bitwarden/sdk/blob/main/.github/workflows/release-go.yml. This makes it so that the release is created here for the sdk-swift repo.

Copy link

codecov bot commented Apr 16, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 58.94%. Comparing base (3c16656) to head (a57b82f).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #268   +/-   ##
=======================================
  Coverage   58.94%   58.94%           
=======================================
  Files         181      181           
  Lines       12341    12341           
=======================================
  Hits         7274     7274           
  Misses       5067     5067           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

.github/workflows/build-swift.yml Outdated Show resolved Hide resolved
.github/workflows/build-swift.yml Outdated Show resolved Hide resolved
.github/workflows/release-swift.yml Outdated Show resolved Hide resolved
.github/workflows/release-swift.yml Outdated Show resolved Hide resolved
.github/workflows/release-swift.yml Outdated Show resolved Hide resolved
.github/workflows/release-swift.yml Outdated Show resolved Hide resolved
.github/workflows/release-swift.yml Outdated Show resolved Hide resolved
.github/workflows/build-swift.yml Show resolved Hide resolved
mimartin12 and others added 2 commits April 24, 2024 08:49
Thank you!

Co-authored-by: Vince Grassia <593223+vgrassia@users.noreply.github.com>
Co-authored-by: Vince Grassia <593223+vgrassia@users.noreply.github.com>
Comment on lines +64 to +69
- name: Upload BitwardenFFI.xcframework artifact
uses: actions/upload-artifact@a8a3f3ad30e3422c9c7b888a15615d19a852ae32 # v3.1.3
with:
name: BitwardenFFI-${{ env._VERSION }}-${{ steps.build.outputs.short-sha }}.xcframework
path: languages/swift/BitwardenFFI.xcframework
if-no-files-found: error
Copy link
Member

Choose a reason for hiding this comment

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

This seems to upload every commit from main in our artifactory, but it's never used?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, I see what you mean. Yes, currently the trigger here https://github.com/bitwarden/sdk/pull/268/files/e336370aa3e6b19b4167b200c2e0df48285b4c2d#diff-055e2da2434f07c0a866c511bfa44f89960b26b18915681bd5a97ed5a8689b9fR9 is going to create an artifact that will not be used in the release workflow. If there is no value in having a GitHub artifact from main, I can remove it.

Copy link
Member

Choose a reason for hiding this comment

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

From my perspective the main value is automatically pushing commits from main to the sdk-swift repository. As this repository will get more activity depending on devops to trigger development releases whenever a new feature gets merged will be tedious

Copy link
Contributor Author

Choose a reason for hiding this comment

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

a15a57a
Does this now, I removed release process items around it, and made it simply push to the repository when a build happens on main. This adheres to the requirement to use GitHub releases to store the artifact.

- Using the requirement of hosting these artifacts with GitHub releases, push each commit in main to the sdk-swift repo.
- Supports this implementation with requirements of GitHub releases as storage, along with pushing commits from main to sdk-swift #268 (comment)
@mimartin12 mimartin12 requested a review from Hinton May 7, 2024 17:08
.github/workflows/build-swift.yml Show resolved Hide resolved
- name: Create release tag on SDK Swift repo
working-directory: sdk-swift
run: |
git tag ${{ env._PKG_VERSION }}-${{ needs.validate.outputs.short_sha }}
Copy link
Member

Choose a reason for hiding this comment

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

I don't think we want to tag "non stable" releases.

git tag ${{ env._PKG_VERSION }}-${{ needs.validate.outputs.short_sha }}
git push origin ${{ env._PKG_VERSION }}-${{ needs.validate.outputs.short_sha }}

github-release:
Copy link
Member

Choose a reason for hiding this comment

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

We should only do github releases for stable.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

How can we do this? How do we define stable releases of the SDK today?

Copy link
Member

Choose a reason for hiding this comment

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

When we desire external parties to use the new version of the sdk, generally whenever secrets manager wants a new release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants