Update the configuration for repository labels to remove the leading
`#` from color values. With a `#` leading the values they are seen as
invalid by the GitHub API.
Additionally as of v3.1.0 of actions/setup-go there is a go-version
output value to retrieve the version of Go installed by the Action.
This allows us to remove the step to manually retrieve this information
from the Go executable.
This adds commented out ignore directives for the following GitHub
Actions:
- action/cache
- action/checkout
- action/setup-python
These should be uncommented downstream to ensure that updates to these
dependencies are pushed from pull requests made in the skeleton.
Update the this workflow to reflect that now individual Markdown files
are generated instead of a single file. This includes renaming the
workflow file, adjusting some step names, and tweaking some other
aspects.
Now that software updates are handled by a bash script that is stored
in the repository these pre-commit hooks should be re-added to the
pre-commit configuration. This also includes re-adding all of the
scaffolding that installs the shfmt tool in the build.yml workflow.
Consolidate all update tasks into a single bash script that is run by
the GitHub Actions workflow. This also switches to generating
individual Markdown files for each data/cisagov_*.yml file.
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.
