Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Integration Testing Build Enhancements #1949

Closed
ferventcoder opened this issue Oct 25, 2019 · 1 comment
Closed

Integration Testing Build Enhancements #1949

ferventcoder opened this issue Oct 25, 2019 · 1 comment
Assignees
@ferventcoder @gep13
Labels
5 - Released BuildAutomation Improvement NO RELEASE NOTES Should not be included in the release notes - not enhancing or fixing end product.
Milestone
0.11.0

Comments

@ferventcoder
Copy link
Member

When building Chocolatey for testing, we may not have an official build - we need to better allow for those scenarios for both us and for other organizations to test integrations with other tools.
@ferventcoder ferventcoder added this to the 0.10.16 milestone Oct 25, 2019
@ferventcoder
Copy link
Member Author

@jborean93 this will remove that extra message to parse if you use -r or limit output.

@ferventcoder ferventcoder self-assigned this Oct 25, 2019
ferventcoder added a commit that referenced this issue Oct 25, 2019
@ferventcoder
(GH-1949) Remove unofficial message on limit output
4bae22c 
When attempting to test integrations, folks use -r as part of that
(limit output). When using an unofficial build to attempt that testing,
we previously have shown a message no matter what that tells folks they
are on an unofficial build - that needed to be parsed and ignored where
an official build would not have had that. When using limit output, log
only to the file.
ferventcoder added a commit that referenced this issue Oct 25, 2019
@ferventcoder
(GH-1949)(build) ensure files unpacked w/unofficial
6130e91 
When building the Chocolatey package without the official strong name
key, it would not properly create the nuget package due to running
`choco unpackself -f` without the additional
`--allow-unofficial-build`. Instead it would throw an error about
needing that passed. Having that additional switch is ignored on
official builds.

Add it to the `nugetPrepare.post.step` file as part of the arguments
to ensure that the nuget package has all of same components that the
officially strong named package would have.
ferventcoder added a commit that referenced this issue Oct 25, 2019
@ferventcoder
Merge branch 'stable'
c48fc2f 
* stable:
  (maint) whitespace
  (GH-1949)(build) ensure files unpacked w/unofficial
  (GH-1949) Remove unofficial message on limit output
gep13 added a commit to gep13/choco that referenced this issue Oct 29, 2019
@gep13
(chocolateyGH-1949) New official release build configuration
16d896c 
This will be used when preparing for an official release of Chocolatey,
to ensure that the correct strong name key is being used, and also that
the necessary checks are being done when loading the Chocolatey Licensed
assembly into the Chocolatey process.  The FORCE_CHOCOLATEY_OFFICIAL_KEY
compilation symbol if used in if/def statements to make this logic
happen.

A new build.official.bat file was also created to make the calling of
this specific build easier to do as well.
@gep13 gep13 mentioned this issue Oct 29, 2019
Merged
gep13 added a commit to gep13/choco that referenced this issue Oct 30, 2019
@gep13
(chocolateyGH-1949) New official release build configuration
9c1e736 
This will be used when preparing for an official release of Chocolatey,
to ensure that the correct strong name key is being used, and also that
the necessary checks are being done when loading the Chocolatey Licensed
assembly into the Chocolatey process.  The FORCE_CHOCOLATEY_OFFICIAL_KEY
compilation symbol if used in if/def statements to make this logic
happen.

A new build.official.bat file was also created to make the calling of
this specific build easier to do as well.
gep13 added a commit to gep13/choco that referenced this issue Oct 30, 2019
@gep13
(chocolateyGH-1949) New official release build configuration
5314694 
This will be used when preparing for an official release of Chocolatey,
to ensure that the correct strong name key is being used, and also that
the necessary checks are being done when loading the Chocolatey Licensed
assembly into the Chocolatey process.  The FORCE_CHOCOLATEY_OFFICIAL_KEY
compilation symbol if used in if/def statements to make this logic
happen.

A new build.official.bat file was also created to make the calling of
this specific build easier to do as well.
ferventcoder added a commit that referenced this issue Oct 30, 2019
@ferventcoder
Merge pull request #1951 from gep13/feature/GH-1949
564595f 
(GH-1949) New official release build configuration
ferventcoder added a commit that referenced this issue Oct 31, 2019
@ferventcoder
Merge branch 'stable'
9a432ab 
* stable:
  (maint) Remove whitespace
  (GH-1949) New official release build configuration
ferventcoder added a commit that referenced this issue Nov 18, 2019
@ferventcoder
(GH-1949) switch assembly location on official key
3f5fde0 
Previously, Debug vs Release was the switch to where Chocolatey resolved
its location along with where the licensed dll would be. Now use the
official key setting to determine that switching. This should allow
locating items next to chocolatey if local as well as when installed
at the machine level.

For release official mode, maintain what used to be Release to allow
for that same behavior to continue.
ferventcoder added a commit that referenced this issue Nov 18, 2019
@ferventcoder
(GH-1949) add default variable for msbuild.configuration
d5abb13 
In the .uppercut file, there is a call that is lacking a variable being
created. Ensure that it is set appropriately to a good default value
prior to being used.

Remove the call in the build.bat file as it is now unnecessary.
ferventcoder added a commit that referenced this issue Nov 18, 2019
@ferventcoder
Merge branch 'stable'
0308984 
* stable:
  (GH-1949) add default variable for msbuild.configuration
  (GH-1949) switch assembly location on official key
  (maint) fix misspelling
ferventcoder added a commit that referenced this issue Nov 19, 2019
@ferventcoder
(GH-1949) Use only official/unofficial on resolve
9abc8c0 
Previously, there was an attempt to use an either or key check when
attempting to find the right assemblies to resolve. Unfortunately that
was a bit optimistic as there is a strong tie in for using one type of
key all the way through to other assemblies.

Only check against one type of key for resolution to allow things to
resolve appropriately. This removes a mix and match thought process
that was optimistic.
ferventcoder added a commit that referenced this issue Nov 19, 2019
@ferventcoder
(GH-1949) Add missed compilation symbol official
88eefa1 
Add missed `FORCE_CHOCOLATEY_OFFICIAL_KEY` compilation symbol for
chocolatey and chocolatey.resources (the latter being more of a
safeguard for future development).
ferventcoder added a commit that referenced this issue Nov 19, 2019
@ferventcoder
Merge branch 'stable'
54ddf11 
* stable:
  (GH-1949) Add missed compilation symbol official
  (GH-1949) Use only official/unofficial on resolve
ferventcoder added a commit that referenced this issue Nov 21, 2019
@ferventcoder
(GH-1949) Release mode - use entry assembly to check
ef3c6d7 
When in release mode, a chocolatey.dll could be next to something being
tested. However, most of the time, for testing, it will be located at
the machine level install. When that is the case, the chocolatey
assembly is loaded into memory to keep from locking the files and the
executing assembly path is null, so it uses the current directory.

Instead prefer to look near the entry assembly, then defer to the
environment variable for the machine installation.
ferventcoder added a commit that referenced this issue Nov 21, 2019
@ferventcoder
Merge branch 'stable'
a230cc6 
* stable:
  (GH-1949) Release mode - use entry assembly to check
ferventcoder added a commit that referenced this issue Nov 21, 2019
@ferventcoder
(GH-1949) Release mode - account for null entry assembly
385076d 
Some testing platforms will not provide an entry assembly, so it can
come back null. In this case, look for the entry assembly first, then
look at the executing assembly. This should work in near all test cases.
This is also not part of official release code.
ferventcoder added a commit that referenced this issue Nov 21, 2019
@ferventcoder
Merge branch 'stable'
564a652 
* stable:
  (GH-1949) Release mode - account for null entry assembly
@ferventcoder ferventcoder mentioned this issue May 24, 2020
Closed
@gep13 gep13 added the NO RELEASE NOTES Should not be included in the release notes - not enhancing or fixing end product. label May 18, 2021
@gep13 gep13 removed the 4 - Done label Sep 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ferventcoder ferventcoder

@gep13 gep13

Labels
5 - Released BuildAutomation Improvement NO RELEASE NOTES Should not be included in the release notes - not enhancing or fixing end product.
Projects
None yet
Milestone
0.11.0
Development

No branches or pull requests
2 participants
@ferventcoder @gep13