I have a Python project that I am looking to publish on GitHub. This project has a couple of variables in one of the files that needs to have their values obfuscated. Ie: API Key, user/password, etc.
My test code has those variables filled with my own data, but I want to boilerplate them when I push changes, for obvious reasons.
Would I be on the right track looking at a GitHub action to accomplish this? If so, any pointers towards what kind of action I should be looking for that is most appropriate for this kind of task?
You should look into dotenv, which allows you to have a .env file or to have OS environment vars set to pull those private information to use in your code without have it set directly. One good tool for this is pydantic BaseSettings, which you should install via:
pip install pydantic[dotenv]
One nice thing I like about pydantic is that you can either have a .env or have environment variables, it will work.
If you have Continuous Integration (CI), you can add GitHub Secrets, which can be pulled in for your test runs with private API keys. You'll need to properly call them with GitHub contexts.
Don't put those values in your code. Read them from an environment variable or from a file instead. Then whoever wants to use your projects only needs to provide said env vars or said file. Check Keep specific git branch offline.
GitHub actions seems overcomplicated imo. Keep in mind that if you already made a commit with those to-be-obfuscated variables, then they will be visible by going to those commits
Related
I know I should put the file containing secret AWS keys in a .gitignore, but then the user on github is forced to reconstruct my constants code containing AWS keys ( a swift struct with static let's). Is there something that would let me substitute a different file when I push? Is there a better way to do this?
Clarification: I am not concerned with sharing AWS keys with other developers. In my situation each developer is independent and can use their own AWS keys.
What I am trying to accomplish is to have a local single development environment where I can develop and test a swift app on Xcode (without changing the keys every time I commit), and yet still be able to push to public GITHUB.
When someone clones the repository, I want them to be able to build after only updating the dummy key values, but I don't ever want my secret keys to be available in any way on GITHUB
You could add your keys to a plist, which is added to your .gitignore file.
That way you don't have to keep resetting those swift variables every time you want to commit, it just pulls from the local plist. Most of my projects also use this plist driven approach to target different schemes. I'll create a 'debug' dictionary for my pre-production api keys, and a 'release' dictionary for my production api keys. This has the added bonus that you can keep production api keys from temp workers if you really wanted to. Works for me, and is very neat.
Yes, you still have to get the other developer that plist file somehow; but there are plenty of ways to do that in an encrypted fashion... it's just a text file.
Most Projects faced with that problem simply substitute dummy values in places of actual keys.
Git makes it especially easy to keep this working – as long as you don't change the dummy line, every git pull / (git fetch + git merge) will preserve the user's line if he's commited the file once.
So I am using github pull requests for my code review needs and my only issue is that I cannot tell whether a person is using tabs or spaces for indentation. We have a standard here on this and you can fail code review for using the wrong one. Is there a way to tell which they are using with github or will I have to manually open up the file in my editor to tell the difference?
Is there a way to tell which they are using with github or will I have to manually open up the file in my editor to tell the difference?
Ideally – neither!
Whenever things can be checked in an automated way, let the computer do the work for you. Checking proper usage of whitespace among many other static rules can be checked with a variety of tools, often called linters. This highly depends on what language your project uses. Of course you can also write your own scrips if you so choose.
What you can do on Github is connect your repository to a CI tool such as Travis. This lets you automatically build all pull requests and check things such as whitespace rules. It also lets you run test suites, code formatting, … – anything you can automate, you can (and should!) run from there to minimize manual work.
I'd like to get the GitHub user / organization name within my .travis.yml file. That is, if my repository containing the .travis.yml is at https://github.com/sschuberth/karn, I'd like to get sschuberth at build time. From looking at the docs it seems there's not such variable yet, or am I missing something?
I know I could extract that information from Git's remote URL, but I wanted to have something cleaner.
In the docs you linked above, there is TRAVIS_REPO_SLUG which will be your github username/repo, e.g. sschuberth/karn, should be quite easy to pick out the username from it.
Whenever I try to import a workflow from Dev/Test environment of a versioned repository into Production environment which is also versioned, I get a option where it asks me if I want to Check in or continue without check in. What happens if I do not check in and continue? Will all the objects used in the workflow will not be checked in or is it just the workflow which will not be checked in? I am asking this because, it will be double work if all the objects used will not be checked in including the Workflow, then, I have to go one by one to check in the objects. If I check the check in option for the workflow, after importing the Workflow, the integration service is left blank and when I run it, it is pointing towards the Integration service not mentioned error. For this I generally check out the workflow once I import just to mention the Integration service name. I do not think this is a good practice. Any advices on this will be greatly appreciated.
Thanks
Dhruuv.
Will all the objects used in the workflow will not be checked in or is it just the workflow which will not be checked in?
The objects that will be left in the checked out state are:
the workflow,
the new objects (i.e. they were not present in the Prod repository before the import from Dev/Test),
the modified objects (i.e. they were present in the Prod repository but were overwritten because you chose the Replace option).
I have to go one by one to check in the objects
You don't have to check in every individual object - in Repository Manager open the Versioning menu and choose the Find Checkouts... option. All the checked out objects will be listed - you can select them and check in all of them at once.
As far as I know, the generally accepted practice of adding third party code like d3 is to add it as a git submodule. This reduces the size of the main repo, but I would imagine having d3 (for example) code in the main repo would help debug the cases when d3 changes breaking some code that uses it.
Are there any reasons why I should not just check out the latest version, develop my code using it, and push it to my own repository?
I really like using git subtree for this purpose. It allows you to keep copies of the remote repository, but still maintains that repository's history, and push/pull back and forth at will.
the only reason is: you don't need it. just use some build tool that automatically manages your dependencies (like grunt). but if for any reason it's not an option for you than use the way that fits your needs. you can make a separate dir for 3rd party libraries and it will work. just make a way so any developer can easily find out which version is currently used (for example use version in file name)