GitHub set a message for me, say: Bump acorn from 6.4.0 to 6.4.1 #1, and I merge, my project is ok?
my project is react-ssr demo, why send me this message?
Dependabot helps you keep your dependencies up to date. It works with most popular languages.
Every day, Dependabot checks your dependency files for outdated requirements and opens individual pull requests for any it finds. You review the PRs, merge them, and get to work on the latest, most secure releases.
Dependabot is owned and maintained by GitHub.
Related
I'm trying to use dependabot to auto-update a private Go repository. My current dependabot.yml looks like this:
version: 2
updates:
- package-ecosystem: 'gomod'
directory: '/'
schedule:
interval: 'daily'
allow:
- dependency-name: "<private-dependency>"
The "private-dependency" does not track versions so I want to update against a specific branch.
I understand I can do this manually by running go get private-dependency#branch but I can't find any documentation on whether I can do so via Dependabot.
I can create a Github Action for running the command and opening a PR but would want to avoid doing so if possible.
Does Dependabot even support updating Go dependencies that track branches? How can I do this using Dependabot?
I opened a customer support ticket with Github and their official response is:
After speaking with Engineering, it was found that according to Golang's documentation the commit-based versions are considered "pseudo-versions" and intended for development. Dependabot seeks for stable versions to suggest as a possible update rather than development versions.
According to this, Dependabot doesn't support this feature yet but they are open to taking a feature request. For our purposes, we started tagging our releases with SemVer and that solved the issue.
Just leaving an answer for posterity and those that might be interested in following this up.
I'm trying to update Sonarqube usage to the latest LTS Community version, which at present is version 6.7.5. Prior to the upgrade I have been using sonarqube 5.4 and the Github plugin, and with these when we make Github pull requests the Sonarqube analysis runs in "preview" scan mode and makes comments on the pull request for any issues the scan finds. This setup is largely following this pattern.
However, with the upgrade to 6.7.5 this same flow is no longer working. The Github plugin
"is deprecated, and its functionality more than replaced by the
Developer Edition."
I understand that the Developer version of Sonarqube has pull request commenting built-in, but I have a strong preference to continue using the Community version due to the cost differences. Essentially, something that was once free and part of the open source version seems to have been removed or broken in the latest free and open source version because a similar paid option now exists. So I am trying to find a way to preserve the previous Community version usage with the latest Community Sonarqube version. 6.7.5 Community version runs the Github plugin (even though it the plugin is deprecated), but so far I have been unable to get things to make comments on the Github pull requests.
Is there a combination of parameters/plugins that will allow my 6.7.5 Community version of Sonarqube to analyze and make comments on a Github pull request?
These may be relevant:
https://community.sonarsource.com/t/after-upgrade-to-sq-6-7-5-target-sonar-issues-report-issues-report-light-html-is-not-produced/1921
https://jira.sonarsource.com/browse/SONAR-9770
https://community.sonarsource.com/t/preview-mode-ignored/1234
I believe in my case the issue was that after upgrading the rule sets changed, so the rules I initially thought were being used with 6.7.5 were not in fact being applied. This gave the impression that Sonarqube was not commenting on the pull request and led to my question. But after enabling the rules appropriately I was able to see it comment on GitHub pull requests as expected. So this appears to be a case of user error!
I'm in need of code that only exists in the master at the moment, and the docs specifically mention a version called 2.0.0.BUILD-SNAPSHOT, but I'll be damned if I can figure out which repository is hosting such a build. Anyone have any clues?
Also, is there any information published about release schedules? I'm loath to develop against the 1.x API because I want the retry and recovery functionality (which doesn't work in either of the 2.0.0 milestone builds, hence my need for a snapshot), but I don't want to commit to an unreleased library without some sense of when a release might happen.
The BUILD-SNAPSHOT you can find in the https://repo.spring.io/snapshot. So, you should configure that for your project.
The next Spring Kafka 2.0.0.RC1 is scheduled for this June 28.
You can find that info on the project page as well: https://github.com/spring-projects/spring-kafka/milestone/20
I have been publishing on biicode, using only the DEV and STABLE tags so far. Unless I have misunderstood, for a given block, it seems that I can publish a DEV version as many times as I like, and my previously published code will get overwritten by the new version each time. On the contrary, it seems that I can only publish a STABLE version once and I cannot overwrite the code published under that tag.
I was wondering how the other tags behave. Can ALPHA and BETA versions be overwritten or can I only publish under those tags just once as well?
Thanks!
Dimitri
All versions, but DEV one, are inmmutable, they are freezed after publication. The aim is to achieve full reproducibility. Changing their contents, or their tags would change what consumers of that code are effectively using. For the same reason, DEV versions, that can be overwritten, cannot be tagged.
So yes, ALPHA and BETA behave exactly the same as STABLE. Their name is just an indication for the target public The idea when you publish an ALPHA version is that you want your teams and collaborators to test it. I would tag them for example as #1.2test1, #1.2test2 and so on. BETA versions are for community testing, probable tags could be release candidates #1.2rc3, and STABLE versions are for production, you could tag them as #1.2 (and probably generate minors with #1.2.1
Note: The # is not necessary in the command, I think the actual command is
$ bii publish user/block --tag=BETA --versiontag=1.2rc3
While you can explicit it in your config file as:
user/block #1.2rc3
That should lookup it, and add also the publication index, something like:
user/block: 3 #1.2rc3
We're using composer, satis and SVN to manage our in-house PHP libraries.
We commit changes to SVN trunk during development, then tag versions (following semantic versioning) when they're ready for testing.
Once a library version is tagged, we can use composer as part of our deployment to the testing environment. Following successful testing, we'd then deploy that same version to production.
The issue here, is that once we've tagged a version for testing, we have to be very careful as the newly tagged version will be picked up by composer when preparing the next prod release.
What I'm imagining, is that we'd tag a version as a beta or RC, (eg v1.1RC1) and somehow configure our deployment process such that it will refuse to deploy an RC or beta to production. If a version is tested successfully, we'd re-tag that version as a released version (v1.1RC1 -> v1.1) and release that.
Can this be achieved?
From what you are saying, I understand that you are actually afraid of tagging a new version of a library because that code could actually be used and break that other application, right?
One approach would be to do good testing. I don't see it should be a problem to tag a version of a library. If the tests are all green, there should be no reason not to tag it. This would work even if the tests are basically only "let's see if it works, manually".
Now the second step is to integrate that new version into the application: Run composer update and see if the application is still running, i.e. start all the tests and wait for green.
I guess it might be a good idea to have a separate area where you check out the application, intentionally run composer update to fetch all the newest libraries, run all the tests and report that a) there are updates and b) they work. A developer should then confirm the update, i.e. do it again manually and commit the resulting composer.lock file, or grab the resulting lock file from that update test.
I don't think there is benefit in using non-production release versions. You have to deal with the next version anyways - constantly toggling the minimum stability setting or adding #RC or #beta flags to the version requirements of the library don't really help.