This allows us to run the specs separately to generate the
documentation. It's more efficient this way and the separate swagger doc
file is easier to read.
The engine-specific swagger helper also allows us to simplify the spec
files.
Added an exception to our styleguide because it's intended and useful to
have a complete (lengthy) description of the API in one block.
In other API specs, you provide example values in the schema. So the
specs contain examples which can be used for the documentation. But
instead of defining example data separately, we can use the generated
data by the specs. This way we document real output and don't have to
double up on documentation.
Note that we don't have schema definitions for the DFC API yet. And it
wouldn't make sense to replicate the DFC Ontology manually in JSON
Schema for this purpose. The DFC Connector ensures already that we
comply with the ontology. But I hope that we can use a tool at some
point to generate JSON Schema from the DFC Ontology which would add more
detail to the Swagger docs, I think.
Rswag doesn't look for specs in engines by default. We haven't added any
Rswag specs in the dfc_provider engine yet but that will come.
The generated API schema has some superfluous whitespace removed due to
a fix in the rswag gems.
The typical use case is to create a small number of commits for a pull
request to ease the review. And you can still run it for all cops with
`-n 999` or `-n -0`.
And remove duplicate output. `bin/setup` is the Rails default for
updating your environment after code updates and `script/setup` is our
convenience script for the initial setup and starting with sample data.
This script has been replaced by a rake task a long time ago:
bundle exec rake karma:run # to run the specs once
bundle exec rake karma:start # to run the spec after each change
We don't need it any more and it doesn't work on my machine.
This script doesn't work anymore. It was written for old an Australian
production server. We have automatic backups now. And if we wanted to
take a backup manually, we should probably give it a meaningful name,
not using a script.
Apparently, there was a practice to archive branches by tagging them
"archive/branch-name" and then deleting them. We don't practice that
anymore and I would suggest to not start doing it again. Our setup is a
bit different now.
We now use our own forks for feature branches and can have our own,
individual archiving practices in our forks. There is no need to have a
central graveyard of people's "work after progress".
The old feature branches we used to have in the central repository got
archived in another fork:
https://github.com/openfoodfoundation/openfoodnetwork-archive/
Branches associated to pull requests should be deleted after the pull
request has been closed. Github keeps a reference to those branches in
the pull request which is like an archive.
Special branches we still have and delete from time to time:
- transifex: Created for new translations, deleted afterwards.
- dependabot/*: Dependabot always creates pull requests. See above.
- 1-31-1-stable etc: They only live as long as they are supported.
I would also like to delete the old `archive/*` tags. They are in the
openfoodnetwork-archive repository and could confuse developers in the
main repository. Let's keep it clean.
`config/schedule.rb` defines entries for cron jobs. Every five minutes
it insert several delayed jobs via `script/enqueue`. A recent upgrade of
Postgresql (a year or two ago) made that script noisy. Every time we
insert a delayed job with that script it outputs:
INSERT 0 1
Standard output like this is seen as error message by cron an forwarded
to the unix user's local mailbox in `/var/mail/openfoodnetwork`. This
file grows over time and accumulates tens of thousands of error
messages, hiding any important failures.
This patch makes inserting delayed jobs quiet. A failure is still
reported.
