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.
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.
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.
As of [Go 1.16](https://tip.golang.org/doc/go1.16#go-command) the `GO111MODULE` environment variable defaults to `on` and `go get` has been deprecated for module installation.
Co-authored-by: Nick M. <50747025+mcdonnnj@users.noreply.github.com>
Some variables defined in the go installation are used in the cache
task, so the go installation must happen first.
Co-authored-by: Nick M. <50747025+mcdonnnj@users.noreply.github.com>
Note that this change is dependent on the merging of
cisagov/setup-env-github-action#31.
Co-authored-by: Nick M. <50747025+mcdonnnj@users.noreply.github.com>
The Terraform installation does not destroy the existing system
Terraform installation, and neither should the Packer installation.
Co-authored-by: Nick M. <50747025+mcdonnnj@users.noreply.github.com>
There is no reason to create /usr/bin/terraform. This is a vestige of
an earlier age.
Co-authored-by: Nick M. <50747025+mcdonnnj@users.noreply.github.com>
We should be doing this because the Packer and Terraform pre-commit
hooks leverage the corresponding executables; therefore, it makes
sense to go ahead and install the particular versions of those
executables that we support. Also add support for optionally
debugging via tmate.
See also cisagov/skeleton-generic#74.
Removed name because it was not more informative than the default. Swapped out
a hardcoded job reference for the github.job context value. Switch the base
cache key to a step environment value so we can set it once and reuse. Removed
additional restore-key value that might have undesirable results.
This should resolve the issue seen when the Python version changes before there
is an update to .pre-commit-config.yml which results in pre-commit pointing to
a non-existent Python installation.
These seem to be very large caches. Restoring an old one and updating
it results in a cache larger than the maximum allowed cache size: 200MB.
"Cache size of 254757924 bytes is over the 200MB limit, not saving
cache."
So if the config changes it is best to just take the cache-miss and
start from scratch.
Nicholas McDonnell
dependabot[bot]
David Redmin
Shane Frasier
Felddy