I am using Maven and have a problem - if my colleague update jar file - Maven doesn't update it. So I have go to .m2/repository and manually delete it. After this Maven update dependance jar correct.
But may be exists another way to adjust, without each time delete manually?
Thanks.
First, you should make sure that your colleague's artifact is released with a SNAPSHOT version number as long as it it is not yet stable (see http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-syntax.html#pom-relationships-sect-snapshot-versions). This will cause Maven to check for updates regularily.
To specify how often the check occurs, you can modify the updatePolicy of the repository to which your colleague deploys (see http://maven.apache.org/settings.html#Repositories). You can set it to always to make Maven pull snapshot updates as soon as your colleague deploys them.
You can also add -U to the mvn command to force maven to check the repository for updates (mvn clean install -U) but like dosendoc said first make sure you're working off SNAPSHOT versions.
Related
I created a Gitlab Ci-CD to remove react and react-dom from devDependencies in package.json when i push my code to master.
but as you can see it says that pipline is passed and job is succeeded but when i look at my master branch react and react-dom are not removed from devDependencies and they are still there.
what should i do with that?
A GitLab CI job doesn't change any of your repository files. It pulls a copy of the repository so that it can run a script, test, etc. against it. If the specified job runs successfully without throwing any errors (exit code), then the job succeeds/passes. You can find a more detailed explanation in the GitLab CI/CD documentation.
If you want to make changes to the repository, you need to have the script run to make the changes, then commit the changes, and push those changes to the repository using the standard git commands.
Just remember that you'll have to authenticate using HTTPS or using SSH.
You'll also likely find this StackOverflow answer on pushing to a GitLab repository through a CI job helpful as well.
I recently added google tag manager on a react-app I'm working on and pushed it in a branch called gtm.
AWS Amplify builds the app successfully and it's up and running. I then merged these changes in the master branch with no merge conflicts. However, in the master branch, (where it's hosted on a custom domain) the app fails to build due to this error:
Error: [BABEL] /codebuild/output/src957941865/src/webapp/src/index.js:
Cannot find module '#babel/helper-regex'
Below is the build error displayed in AWS Amplify
(1) First thing to do was obviously perform this:
yarn add #babel/helper-regex
However, deploying with the new changes only creates another
Error: [BABEL] /codebuild/output/src957941865/src/webapp/src/index.js:
but with a different babel module instead, so this creates a long chain of adding packages that don't necessarily fix the underlying issue.
(2) Second fix I did was revert to a version of the app that was successfully deployed. I initially suspected that the google tag manager was the one causing the problem. However, it wasn't the case. The same error was displayed.
(3) Third thing I did was I referred to fix suggested in this issue (https://github.com/facebook/create-react-app/issues/8062). Summarizing the thread, it says that all I needed to do was to perform the following.
Delete node_modules
Delete yarn.lock
Perform yarn install
Unfortunately, this didn't solve the issue and the build error still persists.
(4) Fourth fix I did was I checked the differences between the two branches master and gtm using git diff master..gtm and here was the result.
Seeing that there were differences, out of desperation, I downloaded the **gtm** branch and then copy pasted its contents into the master branch in windows explorer then committed the changes.
Unfortunately, this still didn't fix the issue.
The only thing I haven't tried yet is reconnecting the master branch in AWS amplify but I don't want to risk the website not working since there are active users and if I ever go through with it and it still didn't fix the issue it'll cause more inconvenience. I hope someone already experienced this before and can point me to the right direction.
I had a similar issue recently while tackling a dependency problem for babel-loader with storybook and create-react-app.
After I noticed other preview builds were working correctly, while having the same code as the master branch, I suspected the node_modules cache was the culprit.
I don't know if there's an easier way of cleaning the node_modules cache that amplify uses internally (searched a bit and found nothing), so I just added an extra command in the preBuild phase (rm -rf node_modules)
eg.
version: 1
frontend:
phases:
preBuild:
commands:
- rm -rf node_modules
- yarn install
Once the build was passing, and the cache is regenerated (this is the last step of the build process) you can simply remove the added command and everything works as expected for future builds.
I suggest you also try combining fixes (2) & (3). That is, revert to a version w/out google tag manager followed by a yarn clean-install (i.e. delete node_modules & yarn.lock -> yarn install). The reason for this is your local workspace may still have broken yarn dependencies from the gtm branch even after you revert to a known-good version.
I have been trying out Codeship and Heroku for continuous deployment of an AngularJS application I writing at the moment. The app was created using Yeoman and uses bower and grunt. Initially I thought this seemed like a really good setup as Codeship was free to use and I was quickly able to configure this to build my AngularJS project and it offered the ability to add a deployment step after the build. There were even many PaaS providers to choose from (Heroku, S3, Google App Engine etc). However I seem to have become a bit stuck with getting the app to run on Heroku.
The problem started from the fact that all the documentation suggested that I remove the /dist path from my .gitignore so that this directory is published to Heroku post build. This was mainly from documentation that talked about publishing to Heroku from a local machine, but I figure this is all Codeship is doing under the hood anyway. I didn't want to do this as I don't believe I should be checking build output into source control. The /dist folder was added to .gitignore for a good reason. Furthermore, this kind of defeats the point of having a CI server somewhat, as I might as well just push the latest build from my machine.
After some more digging around I found out that I could add a postinstall step to my packages.json file such as bower install && grunt build which would re-run the build on Heroku and hence repopulate all the bower dependencies (something else they wanted me to check in to source control!) and the dist directory.
After giving this a try it became apparent that I would need to add bower and grunt as dependencies in packages.json, which meant moving them from devDependencies which is where they should belong!
So I now seem to be stuck. All I want to do is publish my build artefacts (/dist) the dependencies (/bower_components) and the server.js file that will run the site. Does anyone know how to achieve this with Heroku and Codeship? Alternatively has anyone had any success with this using different tools. I am looking for something that is free and I am willing to accept that it will not be production stable (won't scale to multiple servers etc), but this is fine for now as all I want to do is continuously deploy the app for internal testing and to be able to share the output with non-technical members of my team so we can discuss features we'd like to prioritise etc.
Any advice would be greatly appreciated.
Thanks
Ahoy, Marko from the Codeship crew here. Did you already send us an in app message about this? I'm sure we can get your application building on Codeship and deploying to Heroku successfully.
As a very short answer, the easiest way to get this running would be to add both bower and grunt to your dependencies in the package.json. Another possibility would be to look for a custom buildpack with both tools already installed.
And finally you could also run the tools on Codeship, add the newly installed files to the repository, commit the changes and push this new commit to Heroku. If you want to use this, you'd very probably need to force push the changes though.
Feel free to reach out to me via the in app messenger (lower right corner of the site) and I'd be happy to help you get this working!
I found two ways to get this to work.
Heroku Node Custom Buildpack
Use the mbuchetics Heroku build pack. This works by basically re-building the app once it has been pushed to Heroku.
There were a few tricks I had to employ still to make this work. In Gruntfile.jstwo new tasks needed to be configured called heroku:production and heroku:development. This is what the buildpack executes to build the app. I initially just aliased the main build task, but found that the either the buildpack or Heroku had a problem with running jshint so in the end I copied the build task and took out the parts that I didn't need.
Also in packages.json I had to add this:
"scripts": {
"postinstall": "bower cache clean && bower install"
}
This made sure the bower_components were available in Heroku.
Pros
This allowed me to keep the .gitignore file in tact so that the 'binaries' in the dist directory and the dependencies in the bower_components directory were not committed into source control.
Cons
This is basically re-building the app once it is on Heroku and I generally prefer to use the same 'binaries' throughout the entire build and deployment pipeline. That way I know that the same code that was built, is the same code that was tested and is the same code that was deployed.
It also slows down the deployment as you have to wait for the app to build twice.
CodeShip Custom Script Deployment
Not being satisfied with the fact I was building my app twice, I tried using a Custom Script pipeline in CodeShip instead of the pre-existing Heroku one. The script basically modified the .gitignore file to allow the dist folder to be committed and then pushed to the Heroku remote (which leaves the code on the origin remote unaffected by the change).
I ended up with the following bash script:
#!/bin/bash
gitRemoteName="heroku_$APP_NAME"
gitRemoteUrl="git#heroku.com:$APP_NAME.git"
# Configure git remote
git config --global user.email "you-email#example.com"
git config --global user.name "Build"
git remote add $gitRemoteName $gitRemoteUrl
# Allow dist to be pushed to heroku remote repo
echo '!dist' >> .gitignore
# Also make sure any other exclusions dont apply to that directory
echo '!dist/*' >> .gitignore
# Commit build output
git add -A .
herokuCommitMessage="Build $CI_BUILD_NUMBER for branch $CI_BRANCH. Commited by $CI_COMMITTER_NAME. Commit hash $CI_COMMIT_ID"
echo $herokuCommitMessage
git commit -m "$herokuCommitMessage"
# Must merge the last build in Heroku remote, but always chose new files in merge
git fetch $gitRemoteName
git merge "$gitRemoteName/master" -X ours -m "Merge last build and overwrite with new build"
# Branch is in detached mode so must reference the commit hash to push
git push $gitRemoteName $(git rev-parse HEAD):refs/heads/master
Pros
This only require a single build of the app and deploys the same binaries that were tested during the test phase.
Cons
I've used this script quite a few times now and it seems relatively stable. However one issue I know of is that when a new pipeline is created there will be no code on the master branch so this script fails when it tries to do the merge from the heroku remote. At the moment I get around this by doing an initial push of the master branch to Heroku before kicking off a build, but I imagine there is probably a better Git command I could run along the lines of; 'only merge this branch if it already exists'.
I installed SQLite into my WPF project via Nuget. Then added the entire project to a remote repo. Then I cloned the project on another machine, and had a broken build.
x64\SQLite.Interop.dll was missing.
I'm puzzled why Git didn't include one file from my project. I checked the repo on BitBucket and confirmed it is not there. Git status reports nothing to commit, working directory clean
It added the x86 version, but not the x64 version, I can't imagine why.
(project)\x64\SQLite.Interop.dll Git ignored this file!
(project)\x86\SQLite.Interop.dll
You might want to check the .gitignore file at the root of the repo. If it contains for example x64, it would ignore this file.
There would be two main possibilities then:
edit this file to fit your need
or force this file to be added; ie: git add -f x64/SQLite.Interop.dll
However, committing binary files is often frowned upon. It's true in particular if you want to keep up to date with the latest package, hence if you plan to commit new versions of the dlls on a regular basis.
You might rather want to consider Nuget package restore feature. Basically the idea is that you commit a config file, and the client will automatically download the corresponding packages.
I'm using angular-ui-calendar which is at 0.8.0 in bower. I see a problem, and I see it has been fixed on the master branch, but there is no new release. In fact there are quite a few changes between 0.8.0 and the HEAD of the master branch.
I can copy their latest master into my bower_components folder, BUT that won't help anyone else (including jenkins) because when bower_install is done on any other machine, it won't get my changes.
Is there some viable method to deal with this kind of problem that already works?
Do I setup my own bower repos and publish my own version of 0.8.1 for my company?
Do I setup a script that will apply my fixes to the bower_components folder?
Do I add bower_components to git and then check them out the same way I get the rest of my project?
I'm seriously leaning toward the last method because that removes the need for bower to install in other places (bower is struggling to get those 5 9s of reliability)
What problems could ensue if I commit bower_components to my own repo?
(I have a similar problem with ng-grid, so it isn't just the calendar that is giving me heartburn)
I finally decided to commit my bower_components to the git repo so that if I need to make changes to something between releases, I can do that. So far, so good. It also helps me remember when I need to add things to the bower.json file (with --save or manually) since those things are now tracked by git, they show up as untracked files.
Also allows me to diff the changes to components, if I update my bower packages, I can see what changed in those packages and how that might affect my project.