[CI][Build] Use BUILD_NUMBER for building bundles #1371
Merged
Conversation
This file contains 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
tmarkley
reviewed
Mar 23, 2022
When running a release build for example: ``` yarn build-platform --linux --skip-os-packages --release ``` The build task runs through get_build_number and checks how many commits you have locally and determines the build number. From there, and this is the value that is used to as a cache busting mechanism. However, in the release build repo https://github.com/opensearch-project/opensearch-build When this gets packaged and verified it actually pulls from the specified branch and only retrieves the HEAD commit. Thus making the count of commits locally equal to `1` and get_build_number always return `1` for releases essentially breaking the cache buster. The build repo however, sets an env variable of `BUILD_NUMBER` so if this value is available it will use it instead of commit count. The CI runs the unit tests and only gets the latest commit as well so instead of setting a env build number and basically creating the same unit test only check this locally. Issues resolved: * opensearch-project/opensearch-build#1769 * opensearch-project#1363 Signed-off-by: Kawika Avilla <[email protected]>
kavilla
force-pushed
the
avillk/envBuildNum
branch
from
dffab91 to
d734d13
Compare
boktorbb
approved these changes
Mar 24, 2022
opensearch-trigger-bot bot
pushed a commit
that referenced
this pull request
Mar 24, 2022
When running a release build for example: ``` yarn build-platform --linux --skip-os-packages --release ``` The build task runs through get_build_number and checks how many commits you have locally and determines the build number. From there, and this is the value that is used to as a cache busting mechanism. However, in the release build repo https://github.com/opensearch-project/opensearch-build When this gets packaged and verified it actually pulls from the specified branch and only retrieves the HEAD commit. Thus making the count of commits locally equal to `1` and get_build_number always return `1` for releases essentially breaking the cache buster. The build repo however, sets an env variable of `BUILD_NUMBER` so if this value is available it will use it instead of commit count. The CI runs the unit tests and only gets the latest commit as well so instead of setting a env build number and basically creating the same unit test only check this locally. Issues resolved: * opensearch-project/opensearch-build#1769 * #1363 Signed-off-by: Kawika Avilla <[email protected]> (cherry picked from commit 797d988)
kavilla
added a commit
that referenced
this pull request
Mar 24, 2022
When running a release build for example: ``` yarn build-platform --linux --skip-os-packages --release ``` The build task runs through get_build_number and checks how many commits you have locally and determines the build number. From there, and this is the value that is used to as a cache busting mechanism. However, in the release build repo https://github.com/opensearch-project/opensearch-build When this gets packaged and verified it actually pulls from the specified branch and only retrieves the HEAD commit. Thus making the count of commits locally equal to `1` and get_build_number always return `1` for releases essentially breaking the cache buster. The build repo however, sets an env variable of `BUILD_NUMBER` so if this value is available it will use it instead of commit count. The CI runs the unit tests and only gets the latest commit as well so instead of setting a env build number and basically creating the same unit test only check this locally. Issues resolved: * opensearch-project/opensearch-build#1769 * #1363 Signed-off-by: Kawika Avilla <[email protected]> (cherry picked from commit 797d988) Co-authored-by: Kawika Avilla <[email protected]>
opensearch-trigger-bot bot
pushed a commit
that referenced
this pull request
Mar 30, 2022
When running a release build for example: ``` yarn build-platform --linux --skip-os-packages --release ``` The build task runs through get_build_number and checks how many commits you have locally and determines the build number. From there, and this is the value that is used to as a cache busting mechanism. However, in the release build repo https://github.com/opensearch-project/opensearch-build When this gets packaged and verified it actually pulls from the specified branch and only retrieves the HEAD commit. Thus making the count of commits locally equal to `1` and get_build_number always return `1` for releases essentially breaking the cache buster. The build repo however, sets an env variable of `BUILD_NUMBER` so if this value is available it will use it instead of commit count. The CI runs the unit tests and only gets the latest commit as well so instead of setting a env build number and basically creating the same unit test only check this locally. Issues resolved: * opensearch-project/opensearch-build#1769 * #1363 Signed-off-by: Kawika Avilla <[email protected]> (cherry picked from commit 797d988)
kavilla
added a commit
that referenced
this pull request
Mar 31, 2022
When running a release build for example: ``` yarn build-platform --linux --skip-os-packages --release ``` The build task runs through get_build_number and checks how many commits you have locally and determines the build number. From there, and this is the value that is used to as a cache busting mechanism. However, in the release build repo https://github.com/opensearch-project/opensearch-build When this gets packaged and verified it actually pulls from the specified branch and only retrieves the HEAD commit. Thus making the count of commits locally equal to `1` and get_build_number always return `1` for releases essentially breaking the cache buster. The build repo however, sets an env variable of `BUILD_NUMBER` so if this value is available it will use it instead of commit count. The CI runs the unit tests and only gets the latest commit as well so instead of setting a env build number and basically creating the same unit test only check this locally. Issues resolved: * opensearch-project/opensearch-build#1769 * #1363 Signed-off-by: Kawika Avilla <[email protected]> (cherry picked from commit 797d988) Co-authored-by: Kawika Avilla <[email protected]>
opensearch-trigger-bot bot
pushed a commit
that referenced
this pull request
Apr 14, 2022
When running a release build for example: ``` yarn build-platform --linux --skip-os-packages --release ``` The build task runs through get_build_number and checks how many commits you have locally and determines the build number. From there, and this is the value that is used to as a cache busting mechanism. However, in the release build repo https://github.com/opensearch-project/opensearch-build When this gets packaged and verified it actually pulls from the specified branch and only retrieves the HEAD commit. Thus making the count of commits locally equal to `1` and get_build_number always return `1` for releases essentially breaking the cache buster. The build repo however, sets an env variable of `BUILD_NUMBER` so if this value is available it will use it instead of commit count. The CI runs the unit tests and only gets the latest commit as well so instead of setting a env build number and basically creating the same unit test only check this locally. Issues resolved: * opensearch-project/opensearch-build#1769 * #1363 Signed-off-by: Kawika Avilla <[email protected]> (cherry picked from commit 797d988)
opensearch-trigger-bot bot
pushed a commit
that referenced
this pull request
Apr 14, 2022
When running a release build for example: ``` yarn build-platform --linux --skip-os-packages --release ``` The build task runs through get_build_number and checks how many commits you have locally and determines the build number. From there, and this is the value that is used to as a cache busting mechanism. However, in the release build repo https://github.com/opensearch-project/opensearch-build When this gets packaged and verified it actually pulls from the specified branch and only retrieves the HEAD commit. Thus making the count of commits locally equal to `1` and get_build_number always return `1` for releases essentially breaking the cache buster. The build repo however, sets an env variable of `BUILD_NUMBER` so if this value is available it will use it instead of commit count. The CI runs the unit tests and only gets the latest commit as well so instead of setting a env build number and basically creating the same unit test only check this locally. Issues resolved: * opensearch-project/opensearch-build#1769 * #1363 Signed-off-by: Kawika Avilla <[email protected]> (cherry picked from commit 797d988)
opensearch-trigger-bot bot
pushed a commit
that referenced
this pull request
Apr 14, 2022
When running a release build for example: ``` yarn build-platform --linux --skip-os-packages --release ``` The build task runs through get_build_number and checks how many commits you have locally and determines the build number. From there, and this is the value that is used to as a cache busting mechanism. However, in the release build repo https://github.com/opensearch-project/opensearch-build When this gets packaged and verified it actually pulls from the specified branch and only retrieves the HEAD commit. Thus making the count of commits locally equal to `1` and get_build_number always return `1` for releases essentially breaking the cache buster. The build repo however, sets an env variable of `BUILD_NUMBER` so if this value is available it will use it instead of commit count. The CI runs the unit tests and only gets the latest commit as well so instead of setting a env build number and basically creating the same unit test only check this locally. Issues resolved: * opensearch-project/opensearch-build#1769 * #1363 Signed-off-by: Kawika Avilla <[email protected]> (cherry picked from commit 797d988)
kavilla
added a commit
that referenced
this pull request
Apr 25, 2022
When running a release build for example: ``` yarn build-platform --linux --skip-os-packages --release ``` The build task runs through get_build_number and checks how many commits you have locally and determines the build number. From there, and this is the value that is used to as a cache busting mechanism. However, in the release build repo https://github.com/opensearch-project/opensearch-build When this gets packaged and verified it actually pulls from the specified branch and only retrieves the HEAD commit. Thus making the count of commits locally equal to `1` and get_build_number always return `1` for releases essentially breaking the cache buster. The build repo however, sets an env variable of `BUILD_NUMBER` so if this value is available it will use it instead of commit count. The CI runs the unit tests and only gets the latest commit as well so instead of setting a env build number and basically creating the same unit test only check this locally. Issues resolved: * opensearch-project/opensearch-build#1769 * #1363 Signed-off-by: Kawika Avilla <[email protected]> (cherry picked from commit 797d988) Co-authored-by: Kawika Avilla <[email protected]>
kavilla
added a commit
that referenced
this pull request
Apr 25, 2022
When running a release build for example: ``` yarn build-platform --linux --skip-os-packages --release ``` The build task runs through get_build_number and checks how many commits you have locally and determines the build number. From there, and this is the value that is used to as a cache busting mechanism. However, in the release build repo https://github.com/opensearch-project/opensearch-build When this gets packaged and verified it actually pulls from the specified branch and only retrieves the HEAD commit. Thus making the count of commits locally equal to `1` and get_build_number always return `1` for releases essentially breaking the cache buster. The build repo however, sets an env variable of `BUILD_NUMBER` so if this value is available it will use it instead of commit count. The CI runs the unit tests and only gets the latest commit as well so instead of setting a env build number and basically creating the same unit test only check this locally. Issues resolved: * opensearch-project/opensearch-build#1769 * #1363 Signed-off-by: Kawika Avilla <[email protected]> (cherry picked from commit 797d988) Co-authored-by: Kawika Avilla <[email protected]>
kavilla
added a commit
that referenced
this pull request
Apr 25, 2022
When running a release build for example: ``` yarn build-platform --linux --skip-os-packages --release ``` The build task runs through get_build_number and checks how many commits you have locally and determines the build number. From there, and this is the value that is used to as a cache busting mechanism. However, in the release build repo https://github.com/opensearch-project/opensearch-build When this gets packaged and verified it actually pulls from the specified branch and only retrieves the HEAD commit. Thus making the count of commits locally equal to `1` and get_build_number always return `1` for releases essentially breaking the cache buster. The build repo however, sets an env variable of `BUILD_NUMBER` so if this value is available it will use it instead of commit count. The CI runs the unit tests and only gets the latest commit as well so instead of setting a env build number and basically creating the same unit test only check this locally. Issues resolved: * opensearch-project/opensearch-build#1769 * #1363 Signed-off-by: Kawika Avilla <[email protected]> (cherry picked from commit 797d988) Co-authored-by: Kawika Avilla <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
When running a release build for example:
The build task runs through get_build_number and
checks how many commits you have locally and determines the
build number. From there, and this is the value that
is used to as a cache busting mechanism.
However, in the release build repo
https://github.com/opensearch-project/opensearch-build
When this gets packaged and verified it actually pulls
from the specified branch and only retrieves the HEAD
commit. Thus making the count of commits locally equal
to
1and get_build_number always return1for releasesessentially breaking the cache buster.
The build repo however, sets an env variable of
BUILD_NUMBERso if this value is available it will use it instead of commit
count.
Signed-off-by: Kawika Avilla [email protected]
Issues Resolved
Check List
yarn test:jestyarn test:jest_integrationyarn test:ftr