I'm wondering if there is a way to create a single shortcut in IntelliJ that does multiple consecutive actions.
For example, the following actions are needed to deploy a service:
check out the master branch
pull changes
check out the production branch
pull changes
merge the master branch into the production branch
push changes
Each of these actions can be done with a shortcut (and a bit of typing/selection in the case of the checking out), but I would like to do all of these in this order with a single shortcut.
Related
Ocassionally I did hard reset on my current working branch. I restored all the changes lost but here I've another issue:
I have main branch named by dev_security.
I checkout it, I'm on it.
When I create new branch by selecting new branch from branches menu and give it test_branch name
it tells me that I've created branch from HEAD
Ok, I've deleted that branch.
When I am creating new branch by selecting the branch and them making new branch from it
Then it's ok and tells me that branch is created from dev_security
I am pretty sure before my hard reset operation it was the same and ALWAYS told me about creation from dev_security. How can I make it to behave the same?
git reset does not affect checkout action from IntelliJ UI.
In User Guide you can see the description of each action.
Therefore it is expected that you observe different behavior for different actions. There is no option to set the same behavior for different actions.
If you would like to see what commands exactly are executed when you perform different actions, then please open Git toolwindow, switch to "Console" tab and see what command exactly are executed.
Back in the days I've seen on a demo (can't recall now where) where after every push, the Gitlab CI automatically created a pipeline for this commit in an appropriate branch, but without running it automatically.
This allowed user to run pipeline on any branch without having to manually select branch from "new pipeline" button.
Can't find such information in the documentation. Perhaps it was a hack but nonetheless it worked.
How to prevent checking out / changing one binary file in different branches of the same content. Situations like: designers have edited some game level (*.umap binary file) in their branch. Programmes changed same file in their branch (for example - added some blueprint on this game level). So now we have three different versions of this file, one in master branch before all changes, one in designers branch without programmes changes, one in programmes branch without designers changes. And now we must merge designers changes and programmes changes into master branch, but we cant.
So the question is - how to organise right this situations? Maybe we can setup perforce to checkout binary file in multiply branches at the same time, or something like this? Thanks...
There are a couple of different ways to think about this.
If you don't want work to continue/begin in one branch, until changes from another branch have been merged in to it, you can use Helix (Perforce) Protections, to give users read-only access to the branch.
This means they will be able to open files for edit, but won't be able to submit their changes.
More info about protections is here:
https://www.perforce.com/perforce/doc.current/manuals/p4sag/chapter.security.html
The protections would need to be changed, when you are ready for work on the other branches to start.
If you want a file to be automatically checked out on all branches, each time someone checks it out on any branch where it exists, you would currently have to script this.
You could do it using the broker and a workspace for every branch, that has a view that just includes the files you want to be checked out everywhere.
The files would then need to be checked out in these workspaces and locked, so that other users can't submit to these branches until the locks are removed.
This is not trivial and may have a performance impact.
You might also be able to do it using pre-command triggers, if your server version is new enough.
If you want to go in to more detail about any of the above, I recommend you contact Perforce Technical Support.
Hope this helps,
Jen.
So I'm actively trying to circumvent the job limit bamboo has in place because I have many inactive repositories that get fixed occasionally when new platform updates come out or a one-off new feature is added.
What I would like to happen is for my repository polling to pick up that there's been a change on one of my repository branches, run the job, and presto-change-o we're back to square 1 where I'm listening again for another repository polling update from another change.
Example:
Repo 1 has a commit pushed
Bamboo "hears" the change and starts the job
Repo 2 has a commit pushed
Bamboo hears this change as well, but doesn't continue due to 1 agent being available, this change is queued for later
Repo 1's triggered update finishes and publishes an artifact that can be shared
Bamboo resolves and starts Repo 2's job
Is doing something like this even possible? The best solution (meh) that I've found thus far is to just create one job with a sequential build where it's basically checkout/build/checkout/build/checkout/build but that would result in having to run through many unnecessary steps should I poll only one update from one repository. It's not like these things are changing frequently.
You can add multiple repositories to your build plan, and in your repository polling trigger put checkboxes on all repositories added into the plan.
To add multiple repositories,
Open Plan Configuration Editing
Select third tab "Repositories"
Press "Add repository" button.
Configure your repository and save.
Select fourth tab "Triggers".
Open your Repository Polling trigger and select all repositories you've added on steps 3-4.
Save the trigger.
Then repository polling has to check all configured repos, according to documentation:
https://confluence.atlassian.com/display/BAMBOO058/Triggering+builds
You can also add additional repositories into Source code checkout task, and checkout every repository in different subdirectory.
E.g. for repos R1, R2, R3 you will have working copy directories ./W1, ./W2, ./W3.
And Then it's up to you - either you clone your assembler task T to T1, T2, T3 to make builds from each working copy correspondingly, then it will be done for all jobs on every commit, they will all produce artifacts with the same build number, or you can add a shell script task and write a shell script which discovers the latest commit among all working copies (let's assume it is ./W2), creates symbolic link to that working copy subdirectory as ./MySymbolicLink, and your job that assembles the build will do that from ./MySymbolicLink folder.
IntelliJ has the "task" feature where you can track the context for a Jira task, for example.
Now, I changed several files within this task und committed a few times. After a week, I returned to this project and I'd like to see all changed files for this task, from the start of the task until where I left of. I cannot find an option to do this, is this somehow possible?
By default creating a new task offers you to create a separate branch for this task. If you did so, all your commits are in that branch.
If you used another branch, I don;t think there is an easy way to do what you want. You could try checking the saved contexts under Tools - Tasks and Context - Load context