For my local test environment that I use there's a few files that need to be slightly modified from version control in order for the web application to work.
Really it's just a few lines of code a handful of pages that need to be commented it out.
So each time after I do a pull request or checkout a branch from BitBucket I would like for the few lines I edited across multiple files to remain they were and also not have those lines of code replace what's currently on VC. Was this possible?
Related
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
The current project that I am working on uses Jest snapshots and as it is in the early days still, the snapshots are constantly changing. These new snapshots are filling up my PRs and when diffing files I need to either scroll past them (they tend to be long files) or go through the page at the start and minimize them all manually.
Is there a feature in GitHub or a Chrome extension that would allow me to automatically filter these files out? Even just minimize them?
I've tried Pretty Pull Requests but I can't seem to get it working to recognize the .snap files.
Thanks!
A simple expand / collapse function in the Files Changed view of GitHub will not work? They explained the issue here --> Collapse / Expand files in the Files Changed view of a Pull Request
Otherwise the refined-github extension will maybe help.
Edit with #robdonn comment: Though the collapse/expand function in the refined-github is removed. Previously part of refined-github
My development team is in the process of implementing branching and merging in TFS. Our software is contained in one solution, which many projects embedded within. One of those projects contains all the SQL scripts to keep our databases versioned.
We are having trouble figuring out how to handle the Database project during merging. For example, whenever a developer needs to make any changes to the database (add/remove a stored proc, create table, add indexes, etc) we create a script file. Each file gets named with a version number. For instance, if the last script file that was checked in is named 4.1.0.1, I would name my new script 4.1.0.2. We use these file names to match a software version with the corresponding database version it needs to run.
Say I create a branch off our main code branch to do a new feature. I do all the coding, and I put all my SQL changes in one script file and add it to the DB project. Obviously I could just merge from the main code branch into my new branch to make sure I have the latest list of SQL scripts so I could name it correctly. The problem is new script files are added several times throughout the day and we think we're going to have a ton of merge conflicts with the script naming.
I'd like to somehow automate this, so a developer can just add a script with some random name and during the merge there is a hook or event that will figure out which files are new to the main code base and also how to correctly name those files so the developers don't have to worry about it. For example, I can just create a new file called "new_script.sql", and when I merge that back to the main code branch it will get renamed to 4.1.0.2
Previously I've used tools such as RoundHouse to take care of all the SQL versioning, however at my current job we use Sybase SQL Anywhere 10, and I haven't been able to track down something similar to RoundHouse that will work with Sybase.
Can anyone point me in the right direction on how to automate a task during a TFS merge? I'm assuming this can be done using PowerShell, but my concern is that most of the development team is unfamiliar with PowerShell and I was hoping to be able to automate this task without the developer needing to leave the team explorer window.
Any help is greatly appreciated!
Thanks!
I think you are absolute right that you will get naming conflicts if you continue to use this strategy and introduce branches.
I think you have two options:
When adding these files on a branch, add them prefixed with the branch name. Eg. branch_0.1.sql and branch_0.2.sql. Then when you merge your branch back into the trunk, you would have to rename these to the correct name. You could write a program to do this for you, and would be fairly simple.
To make this simpler, you could only create one SQL file per branch too and just keep adding to that one SQL file. Then even you merge it's a very simply process.
Ditch the self versioned files. Tfs is version control. There isn't much need to version the files yourself. We use Visual Studio database projects for our database versioning and this works absolute fine. I guess you would need to change something in your deployment strategy if you changed this.
I hope this helps.
My team recently switched to all three technologies in the past several months and have worked hard to get it up and running. Next step is automating our changelogs. We have JIRA set up look for the tags (ex. TAG-123) in github commit messages. Jenkins monitors the GitHub commits on a 5 minute timer, pulls, builds, etc.
What I would like to see is a changelog generated automatically when a build is marked as "Promoted to Production." I would like to see it do something akin to the following:
Query Jenkins for the previous build marked as a production release and get the corresponding git commit SHA1.
Run a diff in between the current Git commit and the previous commit
Find all JIRA tickets that are referenced
Compile a list of JIRA titles
Have list export to a text file and placed in build drop (bonus if it can be accessed directly through Jenkins as well)
Whether this flow is followed as written or not is irrelevant--I'm after the end result and am not looking to re-invent the wheel.. Surely somebody done something like this before?
As far as reinvention goes, I was able to find https://wiki.jenkins-ci.org/display/JENKINS/Promoted+Builds+Plugin which allows somebody to piggy-back on the Promote to Production action and run a separate script. It would then be a matter of gathering functionality to accomplish the above. (I also noticed Jenkins can tag the current GitHub commit, which my team would likely do in addition.)
Anything closer to accomplishing this would be greatly appreciated.
Thank you!
Since nobody on our team had excess time to devote to this, we ended up throwing together a quick solution.
The Process
Install and setup the All Changes plugin for Jenkins.
When we release, we use "build promotion" system which puts stars next to the previous build, so we can easily see the build# looking at the history.
Copy and paste the relevant output from All Changes into something like notepad++ (human-diff'ing ftw!)
Run a regex find/replace. Search on the regex string, replace with an empty string. (below -- there's the big-bang option or its broken up for understandability.)
Manually organize and release in whatever form is the current agreed up standard.
Everything at once
(\s*\(commit:\s[a-z0-9]{40}.\s..detail)|([\r][\n]#.*\B[\r][\n][\r][\n])|(^[ \t]*)
Remove commit hash\s*\(commit:\s[a-z0-9]{40}.\s..detail
Remove time and surrounding line breaks[\r][\n]#.*\B[\r][\n][\r][\n]
Removing leading whitespace: ^[ \t]*
The Analysis
Pros:
Effective overall
Relatively quick to implement
Cons:
Not fully automated.
Need to revert to commit id if you release from multiple Jenkins jobs.
All Changes history only appears to go back as far as the Jenkins job (I could be mistaken about the specifics of this--I just remember minor grievances with something like this at one point.)
As a whole, the cons are somewhat "the nature of the beast." I'd love to read some other solutions. (For when we have that elusive thing called Time, of course!)
Alternative to dependancy on issue trackers could be to purely use the pull requests themselves. For us they had enough context to generate release notes and we used labels for categorisation. I created PullRequestReleaseNotes and you can try it. It supports GitHub, GitLab, BitBucket and TFS and it can generate release notes in markdown from merged pull requests and its labels and optionally post it to an Atlassian Confluence page and post it to a Slack channel as a post. It can be run as part of continuous integration. Here is a sample:
1.2.1 (MASTER) - XX XXX 2016
Enhancements
Category A
Awesome new feature #1854
Fixes
Category Z
Fixed problem with widget #1792
Category Y
Fixed problem with widget #1792
Fixed exception with view layout #1848
I have a dev folder with all my projects. Some of these are on github and some are not. I also use Dropbox (with symlinks) to keep my data synchronised across several computers.
For example if I add something to my Documents folder on one PC I can then see it in the corresponding folder on another PC.
My question is: If I do the same with my dev folder (so the dev folder is synced by Dropbox on both PCs) will it cause problems with my pushing to github?
You don't ever want to mix code versioning strategies. Either all of your code lives in git (which is a good idea), or it all lives in Dropbox (which doesn't give you any history, hence a very bad idea).
When you add a source file to git, you should be forced to push it to Github so it can be pulled at a later date.
I get the feeling that you will run into issues when pushing the code - you'll be adding new files in through one source, but pulling through another - it'd turn into a headache more than a benefit.
I'm not sure exactly how you could "prove" that is ok. But, I have used exactly this development model with no issues. I personally, don't use symlinks in my dropbox but that shouldn't affect anything. All of my git repos are on my Dropbox. I've been working this way for over a year across OXS, Windows, and Ubuntu. All of my commits and pushes have worked just fine.
Also, this may be a repeat of this question: Using Git and Dropbox together effectively?
[edit:]
Actually one thing was recently brought to my attention is that you might run into an issue with line endings across systems. This post from GitHub (with a link back to an SO question) explains how to deal with line endings.
I had the same question and now my answer is "simply move your repository out of Dropbox".
As you can see, Using Git and Dropbox together effectively? is not the same question, but if you just search the key word "GitHub", you will see the debate about your confusing. And maybe you will make your own desition.