
Security News
AGENTS.md Gains Traction as an Open Format for AI Coding Agents
AGENTS.md is a fast-growing open format giving AI coding agents a shared, predictable way to understand project setup, style, and workflows.
dkist-processing-vbi
Advanced tools
|codecov|
The dkist-processing-vbi library contains the implementation of the vbi pipelines as a collection of the
dkist-processing-core <https://pypi.org/project/dkist-processing-core/>
_ framework and
dkist-processing-common <https://pypi.org/project/dkist-processing-common/>
_ Tasks.
The recommended project structure is to separate tasks and workflows into separate packages. Having the workflows in their own package facilitates using the build_utils to test the integrity of those workflows in the unit test.
Only those specified by dkist-processing-core <https://pypi.org/project/dkist-processing-core/>
_ and dkist-processing-common <https://pypi.org/project/dkist-processing-common/>
_.
.. code-block:: bash
git clone git@bitbucket.org:dkistdc/dkist-processing-vbi.git
cd dkist-processing-vbi
pre-commit install
pip install -e .[test]
pytest -v --cov dkist_processing_vbi
Artifacts are built through Bitbucket Pipelines.
The pipeline can be used in other repos with a modification of the package and artifact locations to use the names relevant to the target repo.
e.g. dkist-processing-test -> dkist-processing-vbi and dkist_processing_test -> dkist_processing_vbi
Deployment is done with turtlebot and follows
the process detailed in dkist-processing-core <https://pypi.org/project/dkist-processing-core/>
_
Additionally, when a new release is ready to be built the following steps need to be taken:
A new "frozen" extra is generated by the dkist-dev-tools <https://bitbucket.org/dkistdc/dkist-dev-tools/src/main/>
_
package. If you don't have dkist-dev-tools
installed please follow the directions from that repo.
To freeze dependencies run
.. code-block:: bash
ddt freeze vX.Y.Z[rcK]
Where "vX.Y.Z[rcK]" is the version about to be released.
When you make any change to this repository it MUST be accompanied by a changelog file.
The changelog for this repository uses the towncrier <https://github.com/twisted/towncrier>
__ package.
Entries in the changelog for the next release are added as individual files (one per change) to the changelog/
directory.
Writing a Changelog Entry ^^^^^^^^^^^^^^^^^^^^^^^^^
A changelog entry accompanying a change should be added to the changelog/
directory.
The name of a file in this directory follows a specific template::
.[.].rst
The fields have the following meanings:
<PULL REQUEST NUMBER>
: This is the number of the pull request, so people can jump from the changelog entry to the diff on BitBucket.<TYPE>
: This is the type of the change and must be one of the values described below.<COUNTER>
: This is an optional field, if you make more than one change of the same type you can append a counter to the subsequent changes, i.e. 100.bugfix.rst
and 100.bugfix.1.rst
for two bugfix changes in the same PR.The list of possible types is defined in the towncrier section of pyproject.toml
, the types are:
feature
: This change is a new code feature.bugfix
: This is a change which fixes a bug.doc
: A documentation change.removal
: A deprecation or removal of public API.misc
: Any small change which doesn't fit anywhere else, such as a change to the package infrastructure.Rendering the Changelog at Release Time ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When you are about to tag a release first you must run towncrier
to render the changelog.
The steps for this are as follows:
towncrier build --version vx.y.z
using the version number you want to tag.NOTE: If you forget to add a Changelog entry to a tagged release (either manually or automatically with towncrier
)
then the Bitbucket pipeline will fail. To be able to use the same tag you must delete it locally and on the remote branch:
.. code-block:: bash
# First, actually update the CHANGELOG and commit the update
git commit
# Delete tags
git tag -d vWHATEVER.THE.VERSION
git push --delete origin vWHATEVER.THE.VERSION
# Re-tag with the same version
git tag vWHATEVER.THE.VERSION
git push --tags origin main
Science Changelog ^^^^^^^^^^^^^^^^^
Whenever a release involves changes to the scientific quality of L1 data, additional changelog fragment(s) should be
created. These fragments are intended to be as verbose as is needed to accurately capture the scope of the change(s),
so feel free to use all the fancy RST you want. Science fragments are placed in the same changelog/
directory
as other fragments, but are always called::
<PR NUMBER | +>.science[.].rst
In the case that a single pull request encapsulates the entirety of the scientific change then the first field should be that PR number (same as the normal CHANGELOG). If, however, there is not a simple mapping from a single PR to a scientific change then use the character "+" instead; this will create a changelog entry with no associated PR. For example:
.. code-block:: bash
$ ls changelog/ 99.bugfix.rst # This is a normal changelog fragment associated with a bugfix in PR 99 99.science.rst # Apparently that bugfix also changed the scientific results, so that PR also gets a science fragment +.science.rst # This fragment is not associated with a PR
When it comes time to build the SCIENCE_CHANGELOG, use the science_towncrier.sh
script in this repo to do so.
This script accepts all the same arguments as the default towncrier
. For example:
.. code-block:: bash
./science_towncrier.sh build --version vx.y.z
This will update the SCIENCE_CHANGELOG and remove any science fragments from the changelog directory.
Once all commits are in place add a git tag that will define the released version, then push the tags up to Bitbucket:
.. code-block:: bash
git tag vX.Y.Z[rcK]
git push --tags origin BRANCH
In the case of an rc, BRANCH will likely be your development branch. For full releases BRANCH should be "main".
.. |codecov| image:: https://codecov.io/bb/dkistdc/dkist-processing-vbi/graph/badge.svg?token=LWWKR72RVV :target: https://codecov.io/bb/dkistdc/dkist-processing-vbi
FAQs
Processing code for the VBI instrument on DKIST
We found that dkist-processing-vbi demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
AGENTS.md is a fast-growing open format giving AI coding agents a shared, predictable way to understand project setup, style, and workflows.
Security News
/Research
Malicious npm package impersonates Nodemailer and drains wallets by hijacking crypto transactions across multiple blockchains.
Security News
This episode explores the hard problem of reachability analysis, from static analysis limits to handling dynamic languages and massive dependency trees.