Add functionality to the update_software_list workflow to normalize the
component files for every push. This will ensure that they are kept in
a manner consistent with how the primary cisagov.yml file stores data.
This value is derived from other information in each software product
entry in the YAML file. Since it is now a derived value we should not
prompt submitters to provide one.
Add the GitHub Actions workflow that will process the YAML files that
contain cisagov controlled software information and generate a final
Markdown file. The required template and Python requirements are
included as well.
We prefer using the long form of switches for command line programs to
improve maintainability and to better convey what is happening even if
someone is unfamiliar with the switches for a given program.
Co-authored-by: dav3r <david.redmin@trio.dhs.gov>
Update the testing branch for the software list update workflow to
include the SHA of the commit that triggers the workflow. This should
help track down problems if there is a failure in testing/rendering.
Update the workflow's requirements to use a specific version at the updated
location of the Python project doing the heavy lifting. Additionally the
requirements file is added to the actions/cache key used.
This value is derived from other information in each software product
entry in the YAML file. Since it is now a derived value we should not
prompt submitters to provide one.
Update the description for the product version input so that it fully
accounts for multiple versions.
Co-authored-by: Shane Frasier <jeremy.frasier@trio.dhs.gov>
Update the description for the product update link input in
both the product submission and product update forms.
Co-authored-by: dav3r <david.redmin@trio.dhs.gov>
Co-authored-by: Shane Frasier <jeremy.frasier@trio.dhs.gov>
Update the product update dropdown's label and options. Mainly focused
on removing usage of Yes/No because these are boolean values in YAML
and thus needed special handling compared to other strings. This mirrors
changes done to the product submission form.
Add a placeholder value for the last updated input in both the product
submission and product update issue forms. This will encourage the
appropriate timestamp format.
Add product vendor and product name inputs to the update form. This
will ensure that even if a submitter does not update the title we
capture this information.
Move the markdown element that explains available statuses down so it
appears close to where a user is selecting the status. Given how form
elements are rendered it has been adjusted to appear after the dropdown
itself. This mirrors changes made in the product submission form.
Add placeholders for some of the required inputs in the form. This will
be most helpful for the product version, but for completeness they have
also been added for the product vendor and name.
Co-authored-by: dav3r <david.redmin@trio.dhs.gov>
Update the product update dropdown's label and options. Mainly focused
on removing usage of Yes/No because these are boolean values in YAML
and thus needed special handling compared to other strings.
Co-authored-by: dav3r <david.redmin@trio.dhs.gov>
Co-authored-by: Shane Frasier <jeremy.frasier@trio.dhs.gov>
Move the markdown element that explains available statuses down so it
appears close to where a user is selecting the status. Given how form
elements are rendered it has been adjusted to appear after the dropdown
itself.
Co-authored-by: dav3r <david.redmin@trio.dhs.gov>
Provide an issue form for product updates to complement the one for
product submissions. This will encourage people to follow the specific
workflows for submissions and updates.
Switch to using a GitHub Issues form for product submission issues. This
will provide a smoother interface for users to submit products to the
database and ensure that certain values are included with a submission.
Add a GitHub Actions workflow and related files to automatically update
SOFTWARE-LIST.md when a push to the develop branch occurs. This
leverages the cisagov/md-table-to-yaml Python library to perform the
conversions.
This changes from using an environment variable to using a step output to store
the Go version that is installed. This mirrors changes made to the other
program versions and how they're stored.
We change the "Install Terraform-docs" step to use two local environment
variables to provide the package's URL and version to install. This allows us
to work around `yamllint` line length limits.
We change the "Install shfmt" step to use two local environment variables to
provide the package's URL and version to install. This allows us to work around
`yamllint` line length limits.
We use a `PACKER_VERSION` environment variable for the "Install Packer" step
that is populated from the `setup-env` outputs to get around `yamllint` lint
length limits.
