Use relevant metadata file when determining framework dependency versions #932
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Paths in some workflows and tasks are configured via variables. Previously, when a value specified a folder path, a
trailing slash was added. The intent behind this was to make it slightly more clear that the value was referring to a
folder (e.g., `./` vs. `.`). However, this practice can be harmful in the case where the value is used as a base
component in a path, as then it is most appropriate to omit the path separator in the concatenation code, which is at
all clear (e.g., `FOO_PATH: foo/`, `{{.FOO_PATH}}bar` -> `foo/bar`). And if the separator is used in the concatenation
code, it results in a confusing double separator in the resulting path (e.g., `FOO_PATH: foo/`, `{{.FOO_PATH}}/bar` ->
`foo//bar`). The benefit of the trailing slash on the variable definition is miniscule at most, since the variable name,
documentation, and other context should make it obvious that the value is a folder path. So the harm of this approach
outweighs the benefit.
For this reason, it is better to omit the trailing slash in the variable definition (e.g., `FOO_PATH: foo`,
`{{.FOO_PATH}}/bar` -> `foo/bar`). Even though this approach is not relevant in cases where the path is not used as a
base component, it is best to be consistent in this practice.
…ions These workflows support multiple projects in subfolders of the repository. The version of the frameworks (Go and Node.js) to use is determined from the content of the metadata files. Previously the workflow always used the file located in the root of the repository. The versioning data in that file won't necessarily be correct for the projects in subfolders, so the metadata for the individual project should be used instead.
per1234
added
topic: infrastructure
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #932 +/- ##
=======================================
Coverage 83.33% 83.33%
=======================================
Files 1 1
Lines 180 180
=======================================
Hits 150 150
Misses 19 19
Partials 11 11
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These workflows support multiple projects in subfolders of the repository. The version of the frameworks (Go and Node.js) to use is determined from the content of the metadata files. Previously the workflow always used the file located in the root of the repository. The versioning data in that file won't necessarily be correct for the projects in subfolders, so the metadata for the individual project should be used instead.