STRLCPY/syft

switch from trigger-release target to release target (#1560)
```
Signed-off-by: Alex Goodman <[email protected]>
```
Alex Goodman committed with GitHub 1 year ago

88c81d33

1 parent 988041ba

Revision indexing in progress... (symbol navigation in revisions will be accurate after indexed)

■ ■ ■ ■ ■ ■

.github/scripts/ci-check.sh

		skipped 5 lines
6	6
7	7		# assert we are running in CI (or die!)
8	8		if [[ -z "$CI" ]]; then
9		-	echo "${bold}${red}This script should ONLY be run in CI. Exiting...${normal}"
	9	+	echo "${bold}${red}This step should ONLY be run in CI. Exiting...${normal}"
10	10		exit 1
11	11		fi
12	12

■ ■ ■ ■ ■ ■

.github/workflows/release.yaml

		skipped 124 lines
125	125		GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
126	126
127	127		- name: Build & publish release artifacts
128		-	run: make release
	128	+	run: make ci-release
129	129		env:
130	130		# for mac signing and notarization...
131	131		QUILL_SIGN_P12: ${{ secrets.ANCHORE_APPLE_DEVELOPER_ID_CERT_CHAIN }}
		skipped 33 lines

■ ■ ■ ■ ■ ■

Makefile

		skipped 314 lines
315	315		$(CHANGELOG):
316	316		$(CHRONICLE_CMD) -vvv > $(CHANGELOG)
317	317
318		-	.PHONY: trigger-release
319		-	trigger-release:
	318	+	.PHONY: release
	319	+	release:
320	320		@.github/scripts/trigger-release.sh
321	321
322		-	.PHONY: release
323		-	release: clean-dist $(CHANGELOG)
	322	+	.PHONY: ci-release
	323	+	ci-release: ci-check clean-dist $(CHANGELOG)
324	324		$(call title,Publishing release artifacts)
325		-	@.github/scripts/ci-check.sh
326	325
327	326		# create a config with the dist dir overridden
328	327		echo "dist: $(DIST_DIR)" > $(TEMP_DIR)/goreleaser.yaml
		skipped 7 lines
336	335
337	336		# upload the version file that supports the application version update check (excluding pre-releases)
338	337		.github/scripts/update-version-file.sh "$(DIST_DIR)" "$(VERSION)"
	338	+
	339	+	.PHONY: ci-check
	340	+	ci-check:
	341	+	@.github/scripts/ci-check.sh
339	342
340	343		## Cleanup targets #################################
341	344
		skipped 34 lines

■ ■ ■ ■ ■ ■

RELEASE.md

1		-	# Release Process
	1	+	# Release
	2	+
	3	+	## Creating a release
	4	+
	5	+	This release process itself should be as automated as possible, and has only a few steps:
	6	+
	7	+	1. Trigger a new release with `make release`. At this point you'll see a preview
	8	+	changelog in the terminal. If you're happy with the changelog, press `y` to continue, otherwise
	9	+	you can abort and adjust the labels on the PRs and issues to be included in the release and
	10	+	re-run the release trigger command.
	11	+
	12	+	1. A release admin must approve the release on the GitHub Actions release pipeline run page.
	13	+	Once approved, the release pipeline will generate all assets and publish a GitHub Release.
	14	+
	15	+	1. If there is a release Milestone, close it.
	16	+
	17	+	Ideally releasing should be done often with small increments when possible. Unless a
	18	+	breaking change is blocking the release, or no fixes/features have been merged, a good
	19	+	target release cadence is between every 1 or 2 weeks.
	20	+
	21	+
	22	+	## Retracting a release
	23	+
	24	+	If a release is found to be problematic, it can be retracted with the following steps:
	25	+
	26	+	- Deleting the GitHub Release
	27	+	- Untag the docker images in the `ghcr.io` and `docker.io` registries
	28	+	- Revert the brew formula in [`anchore/homebrew-syft`](https://github.com/anchore/homebrew-syft) to point to the previous release
	29	+	- Add a new `retract` entry in the go.mod for the versioned release
	30	+
	31	+	Note: do not delete release tags from the git repository since there may already be references to the release
	32	+	in the go proxy, which will cause confusion when trying to reuse the tag later (the H1 hash will not match and there
	33	+	will be a warning when users try to pull the new release).
	34	+
	35	+
	36	+	## Background
2	37
3	38		A good release process has the following qualities:
4	39
		skipped 2 lines
7	42		1. Allow for different kinds of releases (major breaking vs backwards compatible enhancements vs patch updates)
8	43		1. Specify a repeatable way to build and publish software artifacts
9	44
10		-	## Planning a release
	45	+
	46	+	### Planning a release
11	47
12	48		To indicate a set of features to be released together add each issue to an in-repository
13	49		Milestone named with major-minor version to be released (e.g. `v0.1`). It is OK for other
		skipped 11 lines
25	61		Unless necessary, feature releases should be small and frequent, which may obviate the
26	62		need for regular release planning under a Milestone.
27	63
28		-	## What is in a release
	64	+
	65	+	### What is in a release
29	66
30	67		Milestones are specifically for planning a release, not necessarily tracking all changes
31	68		that a release may bring (and more importantly, not all releases are necessarily planned
		skipped 27 lines
59	96		**With this approach as we cultivate good organization of PRs and issues we automatically
60	97		get an equally good Changelog.**
61	98
62		-	## Major, minor, and patch releases
	99	+
	100	+	### Major, minor, and patch releases
63	101
64	102		The latest version of the tool is the only supported version, which implies that multiple
65	103		parallel release branches will not be a regular process (if ever). Multiple releases can
		skipped 7 lines
73	111		The exception to this is `< 1.0`, where the major version is not bumped for breaking changes,
74	112		instead the minor version indicates both new features and breaking changes.
75	113
76		-	## Cutting a release
77		-
78		-	Ideally releasing should be done often with small increments when possible. Unless a
79		-	breaking change is blocking the release, or no fixes/features have been merged, a good
80		-	target release cadence is between every 1 or 2 weeks.
81		-
82		-	This release process itself should be as automated as possible, and has only a few steps:
83		-
84		-	1. Trigger a new release with `make trigger-release`. At this point you'll see a preview
85		-	changelog in the terminal. If you're happy with the changelog, press `y` to continue, otherwise
86		-	you can abort and adjust the labels on the PRs and issues to be included in the release and
87		-	re-run the release trigger command.
88		-
89		-	1. A release admin must approve the release on the GitHub Actions release pipeline run page.
90		-	Once approved, the release pipeline will generate all assets and publish a GitHub Release.
91		-
92		-	1. If there is a release Milestone, close it.
93		-
94		-	## Retracting a release
95		-
96		-	If a release is found to be problematic, it can be retracted with the following steps:
97		-
98		-	- Deleting the GitHub Release
99		-	- Untag the docker images in the `ghcr.io` and `docker.io` registries
100		-	- Revert the brew formula in [`anchore/homebrew-syft`](https://github.com/anchore/homebrew-syft) to point to the previous release
101		-
102		-	Note: do not delete release tags from the git repository since there may already be references to the release
103		-	in the go proxy, which will cause confusion when trying to reuse the tag later (the H1 hash will not match and there
104		-	will be a warning when users try to pull the new release).
105		-

switch from trigger-release target to release target (#1560)