-
Notifications
You must be signed in to change notification settings - Fork 50
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
[DEVOPS-1525] swift workflow for package publishing #268
Conversation
New Issues
|
.github/workflows/build-swift.yml
Outdated
- "rc" | ||
- "hotfix-rc-swift" |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
7da0f4d
to
b23e9aa
Compare
fe12dc4
to
35a251a
Compare
- Add default environment variables - Update branch check - Point Bitwarden actions to main - Move github-release step to last - Create release on sdk-swift project
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 |
Codecov ReportAll modified and coverable lines are covered by tests ✅
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. |
Thank you! Co-authored-by: Vince Grassia <593223+vgrassia@users.noreply.github.com>
Co-authored-by: Vince Grassia <593223+vgrassia@users.noreply.github.com>
- 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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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)
- name: Create release tag on SDK Swift repo | ||
working-directory: sdk-swift | ||
run: | | ||
git tag ${{ env._PKG_VERSION }}-${{ needs.validate.outputs.short_sha }} |
There was a problem hiding this comment.
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: |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
Type of change
Objective
Build and deploy workflows for the
BitwardenFFI. xcframework
package.Code changes
rc
andhotfix-rc-swift
branches, creating the versionedBitwardenFFI.xcframework
package.rc
orhotfix-rc-swift
branches. Creating a GitHub tag and release forBitwardenFFI.xcframework
. Included is a job to push changes to thesdk-swift
repository and create a release tag.Screenshots
Before you submit