I have the .pyx file that has key string in its code.
Key string must be changed for their own version like real, alpha, beta and so on.
So, I want to change the "Key string" belongs to version when building process.
How can I do this within below process? (Using Jenkins for building the code.)
Make .so file with cython build
Make binary file with pyinstaller
I guess, use the "Active Choices parameter" in Jenkins is required to do this, if it is right then guide me how.
Thanks.
I solve this like below.
Create key storage directory.
Store the various key strings to it.
Use build scenario, and copy the specific key file.
Use --add-file option with pyinstaller, and modify a code that use the file.
Related
the app where I am working on was audited and the security team has a concern that consists in: so, for some reason if I extract the .ipa's payload I am able to identify which CI/CD tool was used to generate it. For example:
Terminal:
cd MyApp.app <- payload
strings * > ~/Desktop/file.txt
Inside the file I can find that we are using jenkins
/Volumes/jenkins-workspace/MyApp-Generic/MyApp/MyApp/SomeViewModel.swift
Has anyone faced this problem (if we can call it a problem)? Is there a way to obfuscate or completely remove this kind of references from the IPA?
Thanks
Does that file have a fatalError() call in it? If so, the file and line number will be reported when it runs. Here's a way to fix that if you really need the fatalError call.
If any of your source files have #file compiler directives in them, they will record the path to the file in the executable.
Swift 5.3 introduces a #fileID identifier which produces a shorter
string than #file. The #fileID string contains the filename and module
name, but leaves out the rest of the path to the file; this saves
space, improves performance, and avoids accidentally embedding private
information like the developer’s home directory name in binaries.
Compiler-generated error messages (like force-unwraps) and standard
library assertions like precondition and fatalError now use #fileID
strings, and we recommend you use them instead of #file in production
code. (SE-0285, 65514304)
This pretty much sums my problem. I am using the #file identifier in some methods (mostly for logs) and every file that calls that methods will appear embedded in the app binary.
Ref: https://developer.apple.com/documentation/xcode-release-notes/xcode-12-release-notes
Is there a way to specify optional dependencies in Bazel?
I'd like to make a rule to somewhat mirror Kitware's ExternalData, but I would like to see if I can enable workflows where the developer edits the file in-tree, ideally without needing to modify the BUILD file.
Ideal Workflow
Define a rule, external_data, which can fetch a file from a given server given its SHA-512.
If the file already exists, check it's SHA-512.
If that is what is requested, symlink / copy this file (ensuring that no tests can modify the original file).
If it is different, print a warning, but proceed as normal, to allow for developers to quickly modify the large files as they need.
I would like to do this such that Bazel can switch between the file being present and not, and be robust to false-positives on caching. An example scenario that I would like to avoid, if I were to not include it as an optional dependency:
In a prior run, the file was in the workspace, Bazel built the target, everything's fine and dandy.
Developer removes the file from the workspace after uploading, satisfied with their changes and wanting to test the download process.
When running the downstream target, Bazel doesn't care about the change in the workspace since it's not an explicit dependency, and the symlink is invalidated, and the test crashes and burns.
To me, it seems like I'd run into this if I tried to implement a repository_rule rule which manually checks for the file existence, and conditionally executes (I'm not sure if analysis would retrigger this rule being "evaluated" if Step 2 happens.).
Workaround
My current thought for an alternative workflow is to have an explicit option for external_data, use_workspace: if False, it will download the file; if True, it will just mirror exports_files([]). The developer can then set this when modifying files.
(Ideally, I'd like to optionally include a file which indicates the SHA (${file}.sha512), but this seems to go back to the original ask.)
One workaround is to use Bazel's glob(...) method to effectively check for file existence.
If you have a file, say basic.bin.sha512, and you want a rule to switch modes based on that file's existence, you can use glob(["basic.bin.sha512"]), which will either match the package file exactly or return an empty list.
I had tinkered around with using this on larger sets of files, and it appears to work. However, for the time being, I've erred to having a sort-of explicit "development" mode for the target definition to keep the Bazel build relatively consistent, regardless of what files may be checked out.
Here's an example usage:
https://github.com/EricCousineau-TRI/external_data_bazel/blob/4bf1dff/WORKFLOWS.md#edit-files-in-a-sha512-group
I have this dead simple .travis.yml for a java project. When i run 'travis-lint' against the file is complains
[17:24:23#emeraldjava]$ travis-lint
/Users/pauloconnell/projects/emeraldjava/.travis.yml has issues:
Found an issue with the `language:` key:
Language must be valid
Any ideas?
My build actually works once deployed out.
Until the problem is resolved with the command line tool, and as #joshua-anderson proposed, use the web linter http://lint.travis-ci.org/.
Simply copy/paste your .travis.yml file's content their (or use your github repository directly like emeraldjava/emeraldjava) and hit validate.
I'm using git with an iPad xcode project.
I have an application settings plist file (AppSettings.plist) that is included in the projects repo.
I'd like my devs to have this starting AppSettings.plist when they do a fresh clone but I wouldn't like this file to be committed each time it's updated, so each dev can keep their own version.
I though about .gitignoring it and supply an AppSettings.plist.dist but how could we remember the builder guy to update this file each time we want to have him to ?
So you do not just want a static template of the file, but you also want to modify the file and get these modifications merged into the working copy?
Note: Let’s call AppSettings.plist “working copy” and AppSettings.plist.dist “Template”
My proposal would be to add a version number to the file. When you do changes in the repo, you increase the version number. Then when building you check these numbers in the working copy and the template and emit an error if they don’t match.
If you don’t care about newer/older, you can also use git’s ident feature. That will add the blob id of the template to on checkout. If that id is not the same in the working copy, it is obviously not based on that template.
I'm looking for a way to dynamically add in information about the application during the build process of an iOS application.
During testing, it would be great to know when the application I have installed on my device was built and possibly who built it would be a good to know as well.
I'm envisioning a section in settings.app that would give basic build information for debugging purposes. I don't want to have to manually update a build information file before each build - the data should be generated dynamically.
You can also use standard macro __DATE__ which will result string like "Jun 25 1980" of course with proper current date of build.
You can write a shell script build phase in Xcode that runs at the end of your build process. In this phase you can use the defaults command to write data to an arbitrary file. I've used this technique to write to the Info.plist file, but you can write to any file you want[1].
Here's a sample script to write the current git version to Info.plist:
infoplist="$BUILT_PRODUCTS_DIR/$INFOPLIST_PATH"
gitversion="$(cd "$SRCROOT" && git describe --always --dirty 2>/dev/null)"
if [[ -n "$gitversion" ]]; then
defaults write "${infoplist%.plist}" GitVersion "$gitversion"
fi
You should be able to adapt this to point to the file you want (e.g. your Settings bundle) and write the info you want.
[1] Be careful if you write to Info.plist, Xcode has bugs that can prevent it from realizing Info.plist changed during the build, which can break the provisioning when doing a device build.