THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
This project uses Scala Steward to automatically create pull requests to update the project when new dependencies are released.
Required Checks
Before provding a +1 and merging pull requests created by Scala Steward, the following checks should be performed
- Do all automated continuous integration checks pass?
- Is the update a patch, minor, or major update?
- Major updates need more stringent review criteria than the other updates, at least a manual reading of the library's release notes / changelog to check for API changes.
- Is the license still compatible with ASF License Policy?
- Have any changes been made to LICENSE/NOTICE files that need to be incorporated?
- Note that something as simple as a date change in a LICENSE/NOTICE file requires an update.
- Have any transitive dependencies been added or changed?
- If so, we must perform all the same checks above for those dependenies as well.
Making Updates
If changes are needed, such as updates to allow the integration tests to pass or to update a LICENSE/NOTICE file, the following steps can be performed:
Add the Scala Steward daffodil fork as a new remote:
git remote add scala-steward git@github.com:scala-steward/daffodil.git
Fetch the branch associated with the new dependency:
git fetch scala-steward
Checkout the branch:
git checkout update/jackson-core-2.11.4
- Commit any necessary changes to this branch.
Push changes back to the scala-steward remote:
git push scala-steward update/jackson-core-2.11.4
- Follow the Code Contributor Workflow just as usual, eventually squashing changes, and using
push --force
to push those changes back to the scala-steward remote to update pull request before being merged.
3 Comments
mbeckerle Beckerle
I'm not exactly sure how to codify these things into the checklist, but to me these are essential also:
Another thing to check:
These things may be beyond state of the art, but I wanted to comment on them anyway:
Steve Lawrence
We might want to look into https://github.com/josephearl/sbt-verify for validating dependencies. Unfortnately, this requires a bit of work and I think manual update of dependencies, but an automated method like that is likely the best way to handle verification of maven binaries. I'll also point of that it's not even possible for all Apache binaries. Technically, ASF only requires that you sign release sources. It's very likely many Apache release don't sign helper binaries or thouse published to maven central.
Does sbt even allow you to specify a non exact version? Something to confirm. This may be a non-issue.
I suspect sbt-verify can also handle this. Though, that raise a good point, we need to verify that transitive dependencies have not changed, and if they have, then we must perform all the same checks for those as well.
The list of servers that are used come from sbt. Though, I would argue we don't really care where things come from, especially since new mirors might be spun up all the time. What we really care about is that what we get matches some known hashes, which I think sbt-verify can handle.
mbeckerle Beckerle
Hmmm. If projects have unsigned helper binaries, ultimately we need to be building them from source then.
As an Owl engineer (with that hat on), I'd say this is ok, as we have lots of requirements to only bring source code (signed) across from untrusted environments onto trusted development networks, so this should be something we are willing to make routine and automated.