Repository navigation
CI: speed up AppVeyor build, fix ccache misses across PRs #3754
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
dee61b3
941834a
065b834
e41741a
5cab48c
c170100
ab6fef1
39ffa4a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1135,11 +1135,32 @@ do_autogen_get_CONFIGURE_SCRIPT() { | |
| # older system) we have to remove it when we already have the script. | ||
| # This matches the use-case of distro-building from release tarballs that | ||
| # include all needed pre-generated files to rely less on OS facilities. | ||
| if [ "$CI_OS_NAME" = "windows" ] ; then | ||
| $CI_TIME ./autogen.sh || true | ||
| else | ||
| $CI_TIME ./autogen.sh ### 2>/dev/null | ||
| fi || exit | ||
| ( | ||
| # Optionally drop the PR-specific last component of the version | ||
| # (e.g. 2.8.5.1466.13 => 2.8.5.1466) which AC_INIT puts into | ||
| # config.h as PACKAGE_VERSION. The ccache direct mode hashes all | ||
| # included headers, so a version change misses for nearly every | ||
| # file and defeats ccache across pull requests. Only autogen.sh gets | ||
| # this setting, so `make` still generates nut_version.h (and the | ||
| # UPS_VERSION reported by programs) from actual Git metadata. | ||
| if [ x"${CI_AUTOGEN_STABLE_VERSION-}" = xtrue ] && [ -z "${NUT_VERSION_FORCED-}" ] ; then | ||
| _NUT_VERSION_STABLE="`NUT_VERSION_QUERY=VER50 ./tools/gitlog2version.sh 2>/dev/null`" || _NUT_VERSION_STABLE="" | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is an interesting trick, especially if constrained to autotools but not impacting the ultimate build. I can't even say if I intended to do something like that earlier, when making this tool, and forgot. So kudos! :D I wonder if it makes sense to go even further and just use As it stands here and now, the cache would be relevant at least for all PRs' iterations based on top of current master branch.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Another thought, following the comments in PR #3753, with all of these merged - would each PR running "in its own cache scope" start with a blank cache or inherit the master-branch cache as a starting point?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. They inherit from: own PR, base branch, default branch No re-run reuse in PRs. A PR’s second push won’t reuse its own first build’s ccache. It starts from master’s cache again. That’s the trade-off you’re accepting, and it’s usually fine. So the PR already does the restore on PRs cache saves are only explicitly on pushed ie. merges or direct pushes to the default branch |
||
| case "${_NUT_VERSION_STABLE}" in | ||
| *.*.*.*.*) _NUT_VERSION_STABLE="${_NUT_VERSION_STABLE%.*}" ;; | ||
| esac | ||
| if [ -n "${_NUT_VERSION_STABLE}" ] ; then | ||
| echo "INFO: CI_AUTOGEN_STABLE_VERSION: using NUT_VERSION_FORCED='${_NUT_VERSION_STABLE}' for autogen.sh" >&2 | ||
| NUT_VERSION_FORCED="${_NUT_VERSION_STABLE}" | ||
| export NUT_VERSION_FORCED | ||
| fi | ||
| fi | ||
|
|
||
| if [ "$CI_OS_NAME" = "windows" ] ; then | ||
| $CI_TIME ./autogen.sh || true | ||
| else | ||
| $CI_TIME ./autogen.sh ### 2>/dev/null | ||
| fi | ||
| ) || exit | ||
| fi | ||
|
|
||
| # Retain the full path to configure script file | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To clarify in no uncertain words: all this hassle with
PACKAGE_VERSIONonly impacts debug builds, but not ordinary "release" ones? Would those be with explicit-g0?Is this embedding of all macros, whether used or not, into the binaries, a feature/constraint of specific toolkit (gcc/clang/linker...)? Are there clear options against this activity?
Looking forward, if debug data were to be offloaded into separate files (like many packaging systems do) - is this gonna hit a similar snag by having nominally enabled debug build (just the linker outputs fall into many files not one)?
MAYBE then the fix applied in this file to honour the
CI_AUTOGEN_STABLE_VERSIONsetting belongs actually inautogen.shfile itself, so e.g. package building recipes can use it without callingci_build.sh(normal packages are likely to have fixed versions from tarballs anyway, but e.g. OBS PR builds might benefit from this). Also, makes sense to mention this in guides how to build NUT, especially repetitively (packagers' guide, developers' notes).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll be posting the doc snippet about this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, I think the better approach would be to take the PACKAGE_VERSION out of config.h since that hits way too many files, and maybe have the version number a different place?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure that can be done cleanly, part of autotools standard generated code. Like, we can post-process what they make somehow (and probably not in
configure.acpayload body), but it would not be a proper approach.UPDATE: Newly proposed PR #3759 seems to prove this point wrong, thanks!