empty commit to start release 2.63.0 #6197
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 2 Skipped Deployments
|
fides
|
||||||||||||||||||||||||||||
| Project |
fides
|
| Branch Review |
release-2.63.0
|
| Run status |
|
| Run duration | 00m 52s |
| Commit |
|
| Committer | Adam Sachs |
| View all properties for this run ↗︎ | |
| Test results | |
|---|---|
Failures
|
0
|
Flaky
|
0
|
Pending
|
0
|
Skipped
|
0
|
Passing
|
5
|
| View all changes introduced in this branch ↗︎ | |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #6197 +/- ##
==========================================
+ Coverage 87.07% 87.11% +0.03%
==========================================
Files 423 424 +1
Lines 26321 26387 +66
Branches 2870 2878 +8
==========================================
+ Hits 22919 22987 +68
+ Misses 2776 2773 -3
- Partials 626 627 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Releases
Versioning
Fides uses semantic versioning. Due to the rapid development of the project, some minor versions may also contain minor breaking changes. The best practice is to always pin versions, and carefully test before bumping to a new version.
Patch versions will never cause breaking changes, and are only used to hotfix critical bugs.
Release schedule
Fides does not follow a set release schedule, and instead ships versions based on the addition of features and functionality. Each release, with the exception of hotfixes, contains at least one substantial new feature.
Branching
Fides uses continuous delivery with a single
mainbranch. All code changes are merged into this branch.When it comes times to prepare for a new release, a release branch is created for stability and thoroughly tested.
When releasing, a new tag is created on the release branch and the release process proceeds automatically.
In the case of patches, a branch is created from the relevant tag. Commits are then cherry-picked into this branch, and a new patch version tag is created.
Release Steps
We use GitHub’s
releasefeature to tag releases that then get automatically deployed to DockerHub and PyPi via GitHub Actions. We also use aCHANGELOG.mdto mitigate surprises to our users and help them plan updates accordingly. The release steps are as follows:Release Checklist
The release checklist is a manual set of checks done before each release to ensure functionality of the most critical components of the application. Some of these steps are redundant with automated tests, while others are only tested here as part of this check.
This checklist should be copy/pasted into the final pre-release PR, and checked off as you complete each step.
Additionally, there is a robust Release Process page available in Confluence (internal only).
Warning
THIS RELEASE BRANCH PULL REQUEST SHOULD NOT BE MERGED! IT IS FOR TRACEABILITY PURPOSES ONLY!
Pre-Release Steps
General
From the release branch, confirm the following:
nox -s quickstart(verify you can complete the interactive prompts from the command-line)nox -s "fides_env(test)"(verify the admin UI on localhost:8080, privacy center on localhost:3001, CLI and webserver)Next, run the following checks via the test environment:
API
CLI
Run these from within the test environment shell:
git reset --hard- Note: This is required for thepullcommand to workfides user loginfides push src/fides/data/sample_project/sample_resources/fides pull src/fides/data/sample_project/sample_resources/fides evaluate src/fides/data/sample_project/sample_resources/fides generate dataset db --credentials-id app_postgres test.yml- Note: Because the filesystem isn't mounted, the new file will only show up within the containerfides scan dataset db --credentials-id app_postgresPrivacy Center
Admin UI
User Permissions
Documentation
Instead, they should be committed on a branch off of
mainand then PR'd and merged intomain, before being cherry-pickedover to the release branch. This ensures that the CHANGELOG stays consistent between the release branch and
main.Publishing the release
When publishing the release, be sure to include the following sections in the release description:
## Release Pull Requestsection that includes a link back to the release PR (i.e., this one!) for tracking purposes## QA Touch Test Runsection that includes a link to the QATouch test run (QA team should provide this)Post-Release Steps
python3 -m venv 2_12_0_venvsource 2_12_0_venv/bin/activatepip install ethyca-fidesfides deploy up