The repository's own .github, now that it is public
SPEC 2.2a says INBUXA writes its own when the repository is first published, and it is. Until now the public repository carried Stalwart's: a security policy telling people to report vulnerabilities to Stalwart Labs, and a contributing guide whose policy is that pull requests from anyone not on upstream's vouched list are closed automatically. Neither is this project's, and both were being offered to anyone who looked. So: a security policy that says where to send a report, and what happens if it turns out to be upstream's bug rather than ours; a contributing guide that says what a fork of someone else's code needs from a contributor, including the clean-room question, since the record has to stay true; the Contributor Covenant; and a sponsor link. Upstream's two security documents move to .github-upstream/ beside its workflows -- kept, not used, not presented as ours. CI builds the server and compiles every test target, and deliberately runs no suite. The unit tests only build with the integration crate in the graph, and the integration suites want a STORE, fixed ports and a container apiece, so running them here would mean a tick that skipped everything or a cross that means "the runner has no Redis". The workflow says as much, so nobody has to rediscover it. Also ignores /artifact: two hand-built binaries, ~190 MB, one `git add -A` away from a public repository.
This commit is contained in:
@@ -0,0 +1,43 @@
|
||||
<!--
|
||||
Thanks for contributing to INBUXA. CONTRIBUTING.md has the full guide; this
|
||||
is the short version. Delete any section that does not apply.
|
||||
-->
|
||||
|
||||
## Summary
|
||||
|
||||
<!-- What changes, and why. The why is the part that is hard to recover later. -->
|
||||
|
||||
## Related issues
|
||||
|
||||
<!-- e.g. Closes #123. Leave blank if there are none. -->
|
||||
|
||||
## Upstream files
|
||||
|
||||
<!--
|
||||
Does this touch files that came from Stalwart? If so: is the change as small
|
||||
as it can be, and is it marked with an `inbuxa:` comment saying which
|
||||
requirement it serves? Every edit to an upstream file is a conflict waiting
|
||||
at the next import, so it should be worth one.
|
||||
-->
|
||||
|
||||
## Clean room
|
||||
|
||||
<!--
|
||||
Only for changes to the rebuilt features in `crates/features`, or to the
|
||||
hooks that serve them.
|
||||
|
||||
Confirm one:
|
||||
- [ ] I have not read Stalwart's Enterprise-licensed source, and worked from
|
||||
the specification in `docs/spec/features/`.
|
||||
- [ ] I have read it. (Say so -- the change will be reviewed with that in
|
||||
mind, or declined for the parts it touches. The project's claim of
|
||||
independent creation is a record, and the record has to be true.)
|
||||
-->
|
||||
|
||||
## Testing
|
||||
|
||||
<!--
|
||||
What you ran. `cargo test -p tests` covers what needs nothing but a store;
|
||||
say so if you ran any of the `#[ignore]`d suites from
|
||||
docs/spec/container-tests.md, and which.
|
||||
-->
|
||||
Reference in New Issue
Block a user